Re: Are numeric constants in a namespace visible globally?

From: Sharad Kala (no.spam_sharadk_ind_at_yahoo.com)
Date: 02/02/04 

Date: Mon, 2 Feb 2004 17:59:12 +0530

"William Payne" <mikas493_no_s_p_a_m_@student.liu.se> wrote in message
news:bvlela$m59$1@news.island.liu.se...
> Hello, I am starting to steer away from the practice of using "using
> namespace std;" in my code. Instead I am qualifying each name in the source
> when I use them, for example: std::cout << "Hello";
>
> Now to my question. Depending upon the status of my program, I return either
> EXIT_SUCCESS or EXIT_FAILURE from main(). Thinking that these constants live
> in the std namespace, I tried:
> return std::EXIT_FAILURE; but my compiler said:
> server.cpp:116: error: parse error before numeric constant
> So does that mean that all numeric constants in a namespace are visible
> globally? Or are EXIT_FAILURE and EXIT_SUCCESS preprocessor macros
> (#defines?) and therefore don't care about namespaces? I am including
> <cstdlib>. Anything else I should think of when I want to be careful and
> qualify each name where it's used? Any caveats?

I think they are preprocessor macros, something like
#define EXIT_SUCCESS 0
#define EXIT_FAILURE 1

-Sharad

Relevant Pages

  • namespaces and directory structure
    ... is it good practice to have the directory structure like that also: ... places depending on the namespace i create. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Elegant way to do this?
    ... pretty well makes the namespace facility's presence redundant. ... and am not against the practice. ... 'std', something which greatly increases the likelihood of a name clash. ... those downloading that code know no better, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Namespaces too looooooong
    ... On 31 Aug 2010, at 12:54, Robert Klemme wrote: ... Like I said, when I was looking for best practice on the topic and couldn't find it, I did find lots of people moaning about libraries breaking each other due to not bothering to wrap themselves in a namespace. ... Much as putting a namespace in a constant is much better than what I had before, I like the idea of `as`, or of `alias` extending to namespaces. ...
    (comp.lang.ruby)
  • Re: Namespaces too looooooong
    ... Like I said, when I was looking for best practice on the topic and couldn't find it, I did find lots of people moaning about libraries breaking each other due to not bothering to wrap themselves in a namespace. ... I even found a gem someone had written a gem that fixes other gems' namespacing. ... Much as putting a namespace in a constant is much better than what I had before, I like the idea of `as`, or of `alias` extending to namespaces. ...
    (comp.lang.ruby)
  • Re: namespaces and best practices
    ... Depending on the size of your company, ... insert or [LineOfBusiness] in between company name and ... It is also a good idea to name your assemblies using the full namespace ... > practices are. ...
    (microsoft.public.dotnet.general)