No stretching of the rules required.
Have you an example, Thantos? Assignment to a const seems illegal by definition.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
const doesn't have to be universal to all that can see it.
Off the top of my head
foo.h
foo.cCode:#ifndef FOO_H_ #define FOO_H_ #ifndef FOO_C_ extern const int x; #endif void changevalue(int v); #endif
bar.cCode:#define FOO_C_ #include "foo.h" int x = 5; void changevalue(int v) { x = v; }
Code:#include <iostream> #include "foo.h" int main() { std::cout<<"Before: "<<x<<std::endl; changevalue(4); std::cout<<"After: "<<x<<std::endl; }
Granted that isn't the same as having:
const int foo = 5;
Oh, but then in the given context it implies that the variable is not const.const doesn't have to be universal to all that can see it.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Yes and no. To everyone but the one file the variable is const. const just ensures that you can't change it. Lets say you had:
Where x was tied to some hardware input. x is still const but it isn't a constant value and the compiler shouldn't assume it is.Code:volatile const int x;
Macros are easier to abuse, but they still have valid uses. A chainsaw is easier to abuse than a carving knife, which is why I don't keep one at the dinner table on Thanksgiving. If someone cuts off their hand with a chainsaw carving up a bird, it isn't the chainsaw's fault.
I think the problem is that the word "evil" is not well defined in this context, so the debate is rather pointless. Someone should write an essay entitled "Evil Considered Harmful".
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Macro's aren't evil; they have their uses. And I'm not just talking about include guards.
But in C++, const variables are preferable to Macros, because they are type safe, and because they do not pollute the global namespace.
When there are two ways to solve a problem, and using a macro is one of them, chances are the other option is better.
But macros can be useful when you have a lot of repetitive code that cannot condensed within the syntax of the language. For example, if you have a lot of similar template specializations, that are nevertheless different from the default template.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I'm basically using this definition of evil: http://www.parashift.com/c++-faq-lit....html#faq-6.15
>> Macros are easier to abuse, but they still have valid uses.
Did somebody claim otherwise?
A tool that is easily abused can be called a bad tool. Whether you use the term evil or not isn't all that relevant. The point is that one should be wary of such a tool because it is easily abused. That does not imply that there are no valid uses.
I agree with your opinion on the proper use of macros.
I disagree that there is anything wrong with macros; If I were to asked to redesign the language I would keep macros the way they are.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Instinctively, I'd say this is undefined behaviour.Off the top of my head
Less instinctively, gcc refuses to compile it if you pass the implementation file and at least one using file at the same time and use -combine. (-combine only works for C currently.)
Edit: Finally found it! 3.5/10 in N2588 (most recent C++0x draft) says:
"[...] the types specified by all declarations referring to a given object or function shall be identical [...]. A violation of this rule on type identity does not require a diagnostic."
Last edited by CornedBee; 05-16-2008 at 03:47 PM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law