Mail Archives: cygwin/2007/04/18/13:09:21
On 16 April 2007 11:42, Chelton Evans wrote:
> Thanks for the language correction. However the compiler is braking.
> Here is some of the code and the error messages reported in compilation.
>
> I have tested this on two different computers and the same error messages
> were reported. When I changed the _N to N or something else the
> compilation continued
> on to the next error. Hence it is an underscore problem.
No, hence "_N" is a macro that has been defined by an earlier header to mean
something else. Take a look at the pre-processed source to see what your code
actually looks like to the compiler. What you have done is effectively
something like
#define _N Hello world, this is a macro
class gobjMyCircle : public gobj
{
public:
gobjMyCircle
(
doublec theta0,
doublec theta1,
doublec xaxislength,
doublec yaxislength,
uintc _N=360
);
}
> Thanks for your response, I will think twice before using an
> underscore, even though
> I do no agree with it being reserved. It is very important to have
> programs that
> compile across other platforms.
That is /why/ it is reserved. The compiler, toolchain, C library and OS
need to define symbols and labels in order to communicate with each other. In
order to prevent there from being many many clashes with variable names and
definitions in the user's code, a simple way to divide up the namespace has
been chosen and mandated by the standard: everything that begins with an
underscore belongs to the system level and is none of the user's business to
interfere with, anything that does not begin with an underscore belongs to the
user and is none of the system's business to interfere with.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -