Re: Variables in for loop (style issue)
Walter Bright wrote:
James Dennett wrote:
Walter Bright wrote:
James Dennett wrote:
I've shown above that you cannot "just omit it".
#include <iostream>
#include <ostream>
void print(int r) { std::cout << r << '\n'; }
template <int i> class foo {};
int main()
{
print(3);
#define array_size 4
int array[array_size];
foo<array_size> object;
}
Compiles and works fine.
Yes, because you didn't just "omit the const", you used a
style that's largely obsolete in C++ because of its
drawbacks.
While I see now that you could infer I meant do a global search replace
of const with nothing by "omit the const":
/const//
I actually was meaning not use the const in the first place.
True, you can write code which doesn't use const. You can't
just omit it. We have agreement (on this one point, at least).
And of course you missed the point of the
print() example, so I must have simplified that too much.
Consider a case where passing by const reference is a
significant optimization over pass by value; passing a
non-const reference just doesn't do the same job (can't
bind to temporaries, for one).
As I said in another post, your example is passing an integer literal,
for which passing by reference is not an optimization.
But as I've said (e.g., quoted above) the point of the
example was about passing rvalues, and using a literal
was just a convenient way of doing that. I didn't expect
anyone would misinterpret it to avoid addressing the very
issue under discussion.
There aren't
literals for UTDs which can benefit from pass by reference. Using a
literal which has special characteristics to justify an optimization
where a literal cannot be used anyway, regardless of const, doesn't
illustrate your point.
Apparently true, it didn't illustrate my point clearly
enough. However, I pointed out elsewhere that the point
was about not being allowed to bind a non-const reference
to an rvalue. Use of const is required there.
If you object to using a macro, I can suggest:
enum { array_size = 4 };
Again, hardly a case of just omitting const.
It's even fewer characters (2 less) than const int array_size = 4;
Argument based on character count generally indicate that
a good argument is lacking ;)
(My point above was that the enum solution is an alternative
to use of const, not just a case of omitting const.)
Or I can argue that we're talking about const as a type qualifier, not
const as a storage class.
I'll defer to Daveed's opinion that const as specified by
the C++ standard is always a type qualifier; I don't find
your terminology helpful in this context.
As I pointed out in that thread, top level const does directly influence
the storage class as documented in the Standard. The Standard calls it a
type qualifier, but describes its behavior as a storage class. There's a
very clear documented major difference in behavior of const as top
level, and when it isn't top level.
Right, but not relevant. We agree on behavior; I don't
agree with your use of terminology, preferring to use
the terminology of the C++ standard when discussing the
C++ language.
My point was that you
CANNOT just drop the const and expect code to work, or even
to compile.
I do apologize for implying that one can do /const// on source code and
expect it to work, see above for what I meant.
There are workarounds ("hacks"?)
If you wish to dismiss 30 years of common C and C++ practice as a hack,
ok.
Naturally I am doing no such thing. However, some of
those practices are (elegant or inelegant) hacks; use
of #define for constants is such an example, and use
of enum for integral constants is another, used most
widely in order to support compilers that don't support
static const integral data members correctly.
The enum thing is common practice in C++. I can quote some of
Daveed's published code using it <g>.
It is common, often as a workaround for weak compiler
support.
You can find enum "hacks" and #defines for numerical constants in Boost
used regularly.
Boost is wonderful, but is also very much real-world code
designed for portability to weak compilers (though it
doesn't cope so well with weak standard libraries).
So I doubt I'm so far off base with it.
Nonetheless,
if you choose
to try to program in C++ without const, but significant
parts of the language are off-limits.
This isn't supported by the cases presented.
That aside, static type checking is just as strong
in C as in C++, so I don't see how static type checking is "more key to
C++". (*)
You know that there's a lot of code which your C compiler will
accept which will not type-check as C++ code, I'm pretty sure.
Some sample ways in which type checking is stronger and
more key to C++:
NOTE: there are two points here. (1) Type checking is stronger
in C++ than in C, and (2) type checking is more key to C++ than
it is in C.
Disallowing implicit conversions from void* to other data
pointer types is one of the more obvious differences.
I know about the void* difference, and frankly find it trivial. I've
migrated quite a lot of code from C to C++, and converting:
T *p = malloc(size);
to:
T *p = (T *)malloc(size);
here and there is not any big deal, and it never occurred to me that it
was regarded as a big advance in strong typechecking or key to anything,
because it isn't. It's a detail.
Although you dismiss it as "a detail" (it's much more than
that, IMO, from an impact perspective), it's still an example
of stronger type checking in C++.
Lots of C code relies on this conversion in places which are
not just immediately casting the result of malloc (but maybe
I'm taking your point too literally?).
There are other places where C++'s type checking is not the
same as C's, and I find it odd that I'd have to point them
out to a compiler implementor. Example number two will be
the absence of implicit conversions from integral types to
enumerated types. Example three will be the fact that
string literals have const-qualified types in C++, whereas
their constness in C is enforced only at runtime, if at all.
C++ also adds many new type-checking rules for non-PODs,
such as restrictions on what may be placed in a union.
Types matter much more in C++ also as we can actually write code
which detects them and acts differently (e.g., via overloading,
or template type deduction). C++ also encourages more use of
UDTs, which as a style issue tends to lead to more mistakes
being caught by type checking (though good C programmers use
UDTs extensively also).
True, but none of that means that type checking is *stronger* in C++, it
just means that more use is made of it.
Both are true; the one example of void* checking *is* an
example of stronger type checking, and the paragraph above
talks of how type checking is "more key" to C++.
-- James
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]