No stretching of the rules required.
Printable View
No stretching of the rules required.
Modify const? No stretching? Const isn't supposed to be modified...
Have you an example, Thantos? Assignment to a const seems illegal by definition.
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.Quote:
const doesn't have to be universal to all that can see it.
I'll accept that one, though! You can protect certain files from writing to a global variable, yet being able to read it.
But this wouldn't be possible with a macro.
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".
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.
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.
Instinctively, I'd say this is undefined behaviour.Quote:
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."