Unfortunately I can't send an update for my previous message via
google.
See the message with the same subject or see http://tinyurl.com/4zed8

Looks like integration of preprocessor with the C++ namespaces is
difficult.

But maybe orthogonal preprocessor namespaces can help.

Something like this:
1) Macro definition in the header
#namespace abc
# define ASSERT(a) ....
#end

2) The client code
#using namespace abc
....
void foo()
{
  #ASSERT(i == 0);
}
....

3) Alternative client code

void foo()
{
  #abc#ASSERT(i == 0);
}

Note that the 'ASSERT' is marked with the '#' sign. I think it can
help to distinguish between code and macro. I think that merging of
code and macro, as it exists in the present C++,  is a bad thing.

The preprocessor namespaces can be setted in the project configuration
(like as present day preproecessor definitions). The user can decide
that all directives from abc macro-namespaces sould be applicable in
the project.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Mark wrote:
> If it is optional, otherwise existing code can't be compiled of
> course.

Yes, it is.

The transition technique can be implemented. Just like with type
transformations, where despite on the new xyz_cast syntax the old bad
C-style type casting still works.

Something like this:
- the new #superdef preprocessor keyword is introduced
- the super-defines cannot be referred without #
- the old style defines cannot be defined inside of namespaces
- the old style defines can be referred without #

Moreover, it is easy to transform an old-define-style source coude into
the new-define-style mechanically.

--
Danil


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Danil Shopyrin wrote:
> Note that the 'ASSERT' is marked with the '#' sign. I think it can
> help to distinguish between code and macro. I think that merging of
> code and macro, as it exists in the present C++,  is a bad thing.

I absolutely love the idea that macro names can start with #. But
I'm worried that it would conflict with the "stringizer operator".
Stringizer can only be used in macro expansions, so maybe that's
not an issue -- you just have to be aware that macro names that start
with # can't be used from within other macros.

Here's a slight alternative. Like digits, make # a legal character
in preprocessor identifiers after the first character. Unlike digits,
you can't use two #'s in a row. Also, this would be legal ONLY for
preprocessor identifiers -- not for ordinary C++ identifiers such
as variables or namespace names.

Macro names starting with std# would be reserved for the
implementation.

If we could get the C language to make the same change, then both
languages could deprecate (or whatever C calls it when they make
an old feature available but unadvisable) using #define with an
identifier that doesn't have # in it.

We would change the name of standard macros. ASSERT becomes std#assert.
__FILE__ becomes std#file, and so on. We keep the old names around,
but deprecated.

#if defined(_WIN32)
#define PLATFORM#WINDOWS
#elif defined(__GNUC__)
#define PLATFORM#GNU
#elif...

I'm sure that there are already debates about whether to make
#define deprecated or not. (Surely we can't expunge it from the
language completely, at least not yet -- not just C compatibility,
but legacy code.) But if it was valid to use # in preprocessor
tokens, then we could deprecate #define when used with identifiers
that don't use a # somewhere. Using #define with symbols that
aren't legal to non-preprocessor C++ would eliminate the problems
that we have with macros, while still keeping the basic concept
of macros intact.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Thank you for noticed problems. I don't examine stringizer and similar
operations.

Allan W wrote:
> But I'm worried that it would conflict with the "stringizer
operator".
> Stringizer can only be used in macro expansions, so maybe that's
> not an issue -- you just have to be aware that macro names that start
> with # can't be used from within other macros.

The # sign must apper only outside of #definition and is used only to
refer a macro. Inside of #definition there is no any additional #
signs.

What is beautiful it this approach - it can run without any
deprecation.  Often there is no capability to change third-party code.
And I think that deprecation isn't very useful. Moreover, looks like
the Standard committee don't like code deprecation :-)

Back to the 'my approach' (maybe it isn't mine, but I can't find links
:-).
The usage of 'std' prefix looks good for me. The question is how the
compiler can distinguish the standard macros from each others. Maybe,
the standard library can #define them in some particular way.

It isn't very good, because there are widely used third-party std
library implementations. On the other hand, looks like maintainers of
these libraries march in step with the core language.

--
Danil


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]