On Sat, 19 Oct 2002 02:36:00 +0000 (UTC), andys@evo6.com.NoSpam (Andy
Sawyer) wrote:

>However, not all classes expose all of the
>details of thier internal data structures via non-mutating public
>member functions.

Yes, and i agree this is a good thing.

> Are you suggesting
>that it is advantageous to add public accessors for /all/ internal
>data?

No, i was never suggesting the use of accessors, i was suggesting a
single ad-hoc public member function to print out all internal datas.

This has some (pretty obvious) advantages over simple accessors;
to list only a few: the users of a class do not need to know the
internals to generate an useful log to submit to the classs writer, if
the data members of the class are changed the user's debug code do not
need to be modified, making this function virtual we can generate
fully informative logs for polimorphyc cases, etc...

> Additionally, your proposed technique does not deal usefully with
>private nested types

This objection was referred to accessors, it do not apply to log
functions (it is very simple to call private member's log function
from the main log function).

> Naturally, I'm not requiring you to use the techniques I've
>mentioned, and if you want to limit yourself by ignoring the fact that
>it may be useful, that again is your legitimate choice.

I do not choose to ignore, my opinion (based on my experiences) is
that there is always a better alternative, so i see "keyword
redefinition" as an unneeded (and potentially dangerous) tool.
(but i'm open minded, so you can try to convince me that do exist some
situation where keyword redefinition is the best, or the only,
approach possible...)

For this reason i do not have objections to remove it from the
language/preprocessor; but i do not have strong reasons to require the
removal; so if you do find this useful, well use it and live happy :-)

>But if we're going to remove things that people don't like,
>how about starting with the comma operator?

If this is a serious proposal you do have my full support, comma
operator is on my list of most unwanted C++ features. ;-)

Regards,
Natale Fietta

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 16 Oct 2002 17:32:41 +0000 (UTC), andys@evo6.com.NoSpam (Andy
Sawyer) wrote:

>> >No, let's NOT do that. The reson being that it's something that you
>> >might want to do for debugging purposes - the classic example being:
>> >
>> >#ifdef DEBUGGING
>> >#define private   public
>> >#define protected public
>> >#endif
>>
>> I do see not see any usefulness in this.
>
>The fact that you don't _see_ the utility in this doesn't mean there
>isn't any. (You don't see the coffee in my cup, but I do assure you
>that it's there :-) )

Yes, i said "i do not see" instead of "there is not" because i do know
my limits ;-)

>> can you please show me a legitimate reason to do this ?
>
>I already did - for debugging.

"Debugging pourposes" is a bit too vague a description for me...

>> maybe to deal with some seriously broken debugger that do not let you
>> to inspect private data members ?
>
>There are platforms which don't have source-level debuggers, so have
>to write debugging code to inspect data. Or perhaps you have a failure
>mode which only exhibits itself rarely - in which case you may want to
>log internal data structures for later inspection. Perhaps your
>program behaves differently when being debugged that when running
>"stand alone". 20-odd years of experience has taught me never to
>underestimate the power of printf (and it's equivalents) as a
>debugging tool.

Yes, i also have a bit of experience of these situations, only i do
use a different approach, maybe i am a bit simple-minded but to me
seem preferable to use public member functions to log out internal
datas instead of subvert the keywords meaning.

Regards,
Natale Fietta

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3dafb783.140684@news.iperbole.bologna.it>,
 on Fri, 18 Oct 2002 18:05:07 CST,
 ros0230@iperbole.bologna.it (Natale Fietta) wrote:

> On Wed, 16 Oct 2002 17:32:41 +0000 (UTC), andys@evo6.com.NoSpam (Andy
> Sawyer) wrote:
>
> >> can you please show me a legitimate reason to do this ?
> >
> >I already did - for debugging.
>
> "Debugging pourposes" is a bit too vague a description for me...

Unfortunatly, since you failed to specify the required level of
detail, I failed to meet your expectations.

> Yes, i also have a bit of experience of these situations, only i do
> use a different approach,

 An approach that I also use. But whilst you choose to limit yourself
to a single approach; I choose to use whichever technique is most
appropriate to the situation at hand.

> maybe i am a bit simple-minded but to me seem preferable to use
> public member functions to log out internal datas instead of subvert
> the keywords meaning.

In the case where public member functions allow sufficient access,
then that method may be sufficient. If the public functions of a class
allows sufficient access to its internal data, then your proposed
technique is suitable. However, not all classes expose all of the
details of thier internal data structures via non-mutating public
member functions. (If you need an example, pick almost any class in
the average compiler vendor's standard library). Are you suggesting
that it is advantageous to add public accessors for /all/ internal
data?

 Additionally, your proposed technique does not deal usefully with
private nested types (perhaps you choose not to have any private
nested types - a legitimate, if somewhat limiting, strategy).

 Naturally, I'm not requiring you to use the techniques I've
mentioned, and if you want to limit yourself by ignoring the fact that
it may be useful, that again is your legitimate choice. The fact
remains that there are people who would like, on occasion, to continue
to be able to arbitrarily redefine a textual token via the C++
pre-processor. I submit that the fact that you don't want to do so is
not, in and of itself, a reason to remove that facility from the C++
Standard. But if we're going to remove things that people don't like,
how about starting with the comma operator?


Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 16 Oct 2002 16:08:22 +0000 (UTC),
 ros0230@iperbole.bologna.it (Natale Fietta) wrote:

> On Mon, 14 Oct 2002 12:53:28 +0000 (UTC), andys@evo6.com.NoSpam.NoSpam
> (Andy Sawyer) wrote:
>
> >On Sun, 13 Oct 2002 16:16:34 +0000 (UTC), allan_w@my-dejanews.com
> >(Allan W) wrote:
>
> >> Anyway, let's make it illegal to #define a keyword, but require a
> >> diagnostic.
> >
> >No, let's NOT do that. The reson being that it's something that you
> >might want to do for debugging purposes - the classic example being:
> >
> >#ifdef DEBUGGING
> >#define private   public
> >#define protected public
> >#endif
>
> I do see not see any usefulness in this.

The fact that you don't _see_ the utility in this doesn't mean there
isn't any. (You don't see the coffee in my cup, but I do assure you
that it's there :-) )

> can you please show me a legitimate reason to do this ?

I already did - for debugging.

> maybe to deal with some seriously broken debugger that do not let you
> to inspect private data members ?

There are platforms which don't have source-level debuggers, so have
to write debugging code to inspect data. Or perhaps you have a failure
mode which only exhibits itself rarely - in which case you may want to
log internal data structures for later inspection. Perhaps your
program behaves differently when being debugged that when running
"stand alone". 20-odd years of experience has taught me never to
underestimate the power of printf (and it's equivalents) as a
debugging tool.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 14 Oct 2002 16:49:04 +0000 (UTC),
news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) wrote:

> On Mon, 14 Oct 2002 15:05:13 +0000 (UTC), Gabriel Dos Reis
> <gdr@soliton.integrable-solutions.net> wrote:
> >  allan_w@my-dejanews.com (Allan W) writes:
> >  [...]
> > | Here's another possibility, although it's fleshed out even less than
> > | my previous one. Currently, IIRC, it is illegal to #define a keyword,
> > | but no diagnostic is required. (I couldn't find this rule anywhere in
> > | 16.3, so maybe I'm remembering it wrong?)
> >
> >  I would say you're remembering wrong.  A keyword is just an identifier
> >  at translation phases 1 through 4.
>
> It's illegal to #define a keyword when a standard library header is
> included (see 17.4.3.1.1p2).

Sure - but that isn't what the original post said. The "when a
standard library header is included" makes a world of difference.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) writes:

> allan_w@my-dejanews.com (Allan W) writes:
>
> [...]
>
>
> | Here's another possibility, although it's fleshed out even less than
> | my previous one. Currently, IIRC, it is illegal to #define a keyword,
> | but no diagnostic is required. (I couldn't find this rule anywhere in
> | 16.3, so maybe I'm remembering it wrong?)
>
> I would say you're remembering wrong.  A keyword is just an identifier
> at translation phases 1 through 4.

I think he was remembering 17.4.3.1.1/2 which is a constraint on the
use of standard headers.

Yours,

--
Jean-Marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dave@boost-consulting.com (David Abrahams) wrote
> allan_w@my-dejanews.com (Allan W) writes:
> > Here's another possibility, although it's fleshed out even less than
> > my previous one. Currently, IIRC, it is illegal to #define a keyword,
> > but no diagnostic is required. (I couldn't find this rule anywhere in
> > 16.3, so maybe I'm remembering it wrong?) Anyway, let's make it illegal
> > to #define a keyword, but require a diagnostic. Also, let's make it
> > illegal to #define a symbol that has been previously used in any scope.
>
> Leaving aside for the moment the fact that in real implementations the
> preproccessor gets to touch all symbols before any part of the
> compiler which could be said to handle or recognize definitions sees
> them...

I already agreed with this; you snipped this quote.
> > All I was trying to suggest, is that the preprocessor would be more
> > safe (and therefore more useful) if the names couldn't accidentally
> > collide with other code. I'm open to suggestions for other ways to
> > accomplish the same goal. Using all-uppercase macro names helps, but
> > this is a convention rather than a rule.

> That would make current common, and completely safe, preproccessor
> constructs prone to breakage by unwary users:
>
>     // library.hpp:
>     template <class T> struct foo { enum { value = false }; };
>     #define some_macro(T) \
>     template <> struct foo<T> { enum { value = true }; };
>     some_macro(int)
>     some_macro(long)
>     some_macro(char const*)
>     ...
>     #undef some_macro

> If a user decides to define a variable called some_macro, then
> includes library.hpp, the code is broken. That would be bad.

This is at least unusual; generally libraries are included before
any source code. But I wouldn't go so far as to call it rare.
You could make a stronger case by pointing out that library2.hpp
might define a variable named some_macro. In that case, no matter
which library header came first, my proposal would break it.

I've created a goal (macro names cannot conflict with other names)
and shown two different ways to accomplish it. Both of my two different
ways have major flaws that apparently make them bad ideas for the next
standard.

I'm hoping I've proposed enough ideas that someone else can take it
up, and suggest some third way to accomplish the same goal. Is it
really impossible to create a "safe and sane" version of the preprocessor?

I note that some assembly languages have preprocessors that are even
more powerful than the one C++ inherited from C, and yet these
assembly-language preprocessors are NOT considered a major source of
errors. What's the fundamental difference? Can we exploit that same
difference in C++, to make the preprocessor a powerful but safe tool?
(Which today it clearly is not.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

leavings@attbi.com ("Paul Mensonides") wrote in message
>
> ... It is not that the preprocessor is bad,
> but rather that is an inappropriate tool to use if there is a better way.  I
> agree that the preprocessor is under-featured.  It needs improvement, but
> not unilateral replacement or retraction.
>
I tried to use Boost.Preprocessor library in test code (BC++B 6.0) and
discovered there's implementation limit on expanded macro length,
pretty low, undocumented and unpredictable. This made it real
showstopper - even if it works today, it may not tomorrow with no
possible workaround.

Raising or rather removing these limits would be great first step.

/Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

> dave@boost-consulting.com (David Abrahams) wrote
> > That would make current common, and completely safe, preproccessor
> > constructs prone to breakage by unwary users:
> >
> >     // library.hpp:
> >     template <class T> struct foo { enum { value = false }; };
> >     #define some_macro(T) \
> >     template <> struct foo<T> { enum { value = true }; };
> >     some_macro(int)
> >     some_macro(long)
> >     some_macro(char const*)
> >     ...
> >     #undef some_macro
>
> > If a user decides to define a variable called some_macro, then
> > includes library.hpp, the code is broken. That would be bad.
>
> This is at least unusual; generally libraries are included before
> any source code.

Use your imagination. One library can break another library.

> But I wouldn't go so far as to call it rare.
> You could make a stronger case by pointing out that library2.hpp
> might define a variable named some_macro. In that case, no matter
> which library header came first, my proposal would break it.

I didn't think I had to counter every possible red herring argument.

> I've created a goal (macro names cannot conflict with other names)
> and shown two different ways to accomplish it. Both of my two different
> ways have major flaws that apparently make them bad ideas for the next
> standard.
>
> I'm hoping I've proposed enough ideas that someone else can take it
> up, and suggest some third way to accomplish the same goal. Is it
> really impossible to create a "safe and sane" version of the preprocessor?

I don't know. Consider this, though:

What's the difference, really, between the names

    boost::python::handle_exception

and

    BOOST_PYTHON_HANDLE_EXCEPTION,

really?

Maybe if we were to allow colons in macro names, that would be enough
<.02 wink>.

at-least-there-will-be-no-macro-koenig-lookup-ly y'rs,
Dave
--
           David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jm@bourguet.org (Jean-Marc Bourguet) writes:

| gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) writes:
|
| > allan_w@my-dejanews.com (Allan W) writes:
| >
| > [...]
| >
| >
| > | Here's another possibility, although it's fleshed out even less than
| > | my previous one. Currently, IIRC, it is illegal to #define a keyword,
| > | but no diagnostic is required. (I couldn't find this rule anywhere in
| > | 16.3, so maybe I'm remembering it wrong?)
| >
| > I would say you're remembering wrong.  A keyword is just an identifier
| > at translation phases 1 through 4.
|
| I think he was remembering 17.4.3.1.1/2 which is a constraint on the
| use of standard headers.

Ah, that indeed is a different story.
It wasn't clear he was talking just about the "core language" or "the
code language + library requirements".

Thanks,
--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:ubs5wg0o8.fsf@boost-
>
> at-least-there-will-be-no-macro-koenig-lookup-ly y'rs,

Is that supposed to be a good thing?  Gears are working...

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Vozenilek" <pavel_vozenilek@yahoo.co.uk> wrote in message
news:731020ca.0210141244.ac1aef9@posting.google.com...
> leavings@attbi.com ("Paul Mensonides") wrote in message
> >
> > ... It is not that the preprocessor is bad,
> > but rather that is an inappropriate tool to use if there is a better
way.  I
> > agree that the preprocessor is under-featured.  It needs improvement,
but
> > not unilateral replacement or retraction.
> >
> I tried to use Boost.Preprocessor library in test code (BC++B 6.0) and
> discovered there's implementation limit on expanded macro length,
> pretty low, undocumented and unpredictable. This made it real
> showstopper - even if it works today, it may not tomorrow with no
> possible workaround.
>
> Raising or rather removing these limits would be great first step.

What were you trying to do?  There are several facilities in the current
Boost.Preprocessor library to help in this regard--such as file-iteration.
I myself have had very little trouble with Borland's preprocessor.

In other words, there is a "right way" and a "wrong way" to do preprocessor
metaprogramming.  Maybe I can help, but reply to me directly.

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 14 Oct 2002 12:53:28 +0000 (UTC), andys@evo6.com.NoSpam.NoSpam
(Andy Sawyer) wrote:

>On Sun, 13 Oct 2002 16:16:34 +0000 (UTC), allan_w@my-dejanews.com
>(Allan W) wrote:

>> Anyway, let's make it illegal to #define a keyword, but require a
>> diagnostic.
>
>No, let's NOT do that. The reson being that it's something that you
>might want to do for debugging purposes - the classic example being:
>
>#ifdef DEBUGGING
>#define private   public
>#define protected public
>#endif

I do see not see any usefulness in this.
can you please show me a legitimate reason to do this ?
maybe to deal with some seriously broken debugger that do not let you
to inspect private data members ?

Regards,
Natale Fietta

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Vozenilek" <pavel_vozenilek@yahoo.co.uk> wrote in message
news:731020ca.0210111523.37cd4ef3@posting.google.com...
> allan_w@my-dejanews.com (Allan W) wrote in message
> > What about retracting the preprocessor? ...
> > .. and for everything else that macros are good for, while avoiding
> > everything that macros are bad for.
> >
> It is easy to dismiss preprocessor as only tool to define constants
> and snippets of code but there is definitely need for something to
> support testing, debug versions and so on. I would welcome more
> powerful preprocessor, not crippled one.
>
> Example of nify use of preprocessor is ON_BLOCK_EXIT macro of
> Alexandrescu's ScopeGuard library
> (http://www.cuj.com/experts/1812/alexandr.htm?topic=experts).

There is also something to be said for pure token-oriented (rather than
syntax-oriented) text manipulation.  It is not that the preprocessor is bad,
but rather that is an inappropriate tool to use if there is a better way.  I
agree that the preprocessor is under-featured.  It needs improvement, but
not unilateral replacement or retraction.

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > allan_w@my-dejanews.com (Allan W) wrote
> > > What about retracting the preprocessor? ...
> > > .. and for everything else that macros are good for, while avoiding
> > > everything that macros are bad for.

> "Pavel Vozenilek" <pavel_vozenilek@yahoo.co.uk> wrote
> > It is easy to dismiss preprocessor as only tool to define constants
> > and snippets of code but there is definitely need for something to
> > support testing, debug versions and so on. I would welcome more
> > powerful preprocessor, not crippled one.
> >
> > Example of nify use of preprocessor is ON_BLOCK_EXIT macro of
> > Alexandrescu's ScopeGuard library
> > (http://www.cuj.com/experts/1812/alexandr.htm?topic=experts).

Suppose that same macro was named $ON_BLOCK_EXIT. Would that make
it less "nifty"?

leavings@attbi.com ("Paul Mensonides") wrote in message
> There is also something to be said for pure token-oriented (rather than
> syntax-oriented) text manipulation.  It is not that the preprocessor is bad,
> but rather that is an inappropriate tool to use if there is a better way.  I
> agree that the preprocessor is under-featured.  It needs improvement, but
> not unilateral replacement or retraction.

I did say:
> What about retracting the preprocessor? If we didn't already have a
> preprocessor to be compatible with, I might think it was a good idea --
> but only if the symbol names used couldn't conflict with other symbols.

I'll admit that my idea is impractical from the point of view of
legacy code -- which is extremely important. I certainly agree
that "unilateral replacement or retraction" is not a good idea in
the land of reality.

All I was trying to suggest, is that the preprocessor would be more
safe (and therefore more useful) if the names couldn't accidentally
collide with other code. I'm open to suggestions for other ways to
accomplish the same goal. Using all-uppercase macro names helps, but
this is a convention rather than a rule.

Here's another possibility, although it's fleshed out even less than
my previous one. Currently, IIRC, it is illegal to #define a keyword,
but no diagnostic is required. (I couldn't find this rule anywhere in
16.3, so maybe I'm remembering it wrong?) Anyway, let's make it illegal
to #define a keyword, but require a diagnostic. Also, let's make it
illegal to #define a symbol that has been previously used in any scope.

    #define if for // Illegal; if is a keyword
    int foo() { int x=3; return x*x; }
    #define x      // Illegal; x has already been used as a symbol

Handling C-legacy "functions" such as fputs, which can be either a
macro or a function, is a problem I haven't quite worked out yet.
Also, this doesn't address namespace collisions where the macro name
comes first, which I assume is the more common case.

    #define sum(a,b) ((a)+(b))
    struct myclass {
        int sum; // Whoops!
    };

If we could make this illegal, but breaking legacy C or C++ code was
extremely rare, I'd be in favor of it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

> Here's another possibility, although it's fleshed out even less than
> my previous one. Currently, IIRC, it is illegal to #define a keyword,
> but no diagnostic is required. (I couldn't find this rule anywhere in
> 16.3, so maybe I'm remembering it wrong?) Anyway, let's make it illegal
> to #define a keyword, but require a diagnostic. Also, let's make it
> illegal to #define a symbol that has been previously used in any scope.

Leaving aside for the moment the fact that in real implementations the
preproccessor gets to touch all symbols before any part of the
compiler which could be said to handle or recognize definitions sees
them...

That would make current common, and completely safe, preproccessor
constructs prone to breakage by unwary users:


    // library.hpp:
    template <class T> struct foo { enum { value = false }; };
    #define some_macro(T) \
    template <> struct foo<T> { enum { value = true }; };
    some_macro(int)
    some_macro(long)
    some_macro(char const*)
    ...
    #undef some_macro


If a user decides to define a variable called some_macro, then
includes library.hpp, the code is broken. That would be bad.

> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

--
           David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 13 Oct 2002 16:16:34 +0000 (UTC), allan_w@my-dejanews.com
(Allan W) wrote:

> Currently, IIRC, it is illegal to #define a keyword, but no
> diagnostic is required.

I'm afraid you appear not to RC.

> Anyway, let's make it illegal to #define a keyword, but require a
> diagnostic.

No, let's NOT do that. The reson being that it's something that you
might want to do for debugging purposes - the classic example being:

#ifdef DEBUGGING
#define private   public
#define protected public
#endif

Historically, this is (part of) the reason that it is _access_ that is
controlled by public/protected/private rather than _visibility_. On a
more pragmatic (if less comp.std.c++ related :-) note, banning the
#definition of keywords it makes the preprocessor less useful for some
tasks outside the context of C & C++.

> Also, let's make it illegal to #define a symbol that has
> been previously used in any scope.
>=20
>     #define if for // Illegal; if is a keyword
>     int foo() { int x=3D3; return x*x; }
>     #define x      // Illegal; x has already been used as a symbol

What about:

#define foo bar

int x() { int foo; }

#define bar

? (No, I don't much care what the answer is)

> Handling C-legacy "functions" such as fputs, which can be either a
> macro or a function, is a problem I haven't quite worked out yet.

It's also a problem that doesn't arise in C++:

,----[ 17.4.1.2/p5 ]
| Names which are defined as macros in C shall be defined as macros in
| the C++ Standard Library, even if C grants license for implementation
| as functions.
`----
and
,----[ 17.4.1.2/p6 ]
| Names that are defined as functions in C shall be defined as
| functions in the C++ Standard Library.
`----

No, I think we leave the preprocessor well enough alone. If we ignore
it for long enough maybe it'll get bored, and drift away=B9.

Regards,
 Andy S.
=B9  With apologies to Zaphod Beeblebrox.
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) writes:

[...]


| Here's another possibility, although it's fleshed out even less than
| my previous one. Currently, IIRC, it is illegal to #define a keyword,
| but no diagnostic is required. (I couldn't find this rule anywhere in
| 16.3, so maybe I'm remembering it wrong?)

I would say you're remembering wrong.  A keyword is just an identifier
at translation phases 1 through 4.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
>
> All I was trying to suggest, is that the preprocessor would be more
> safe (and therefore more useful) if the names couldn't accidentally
> collide with other code. I'm open to suggestions for other ways to
> accomplish the same goal. Using all-uppercase macro names helps, but
> this is a convention rather than a rule.
>
> Here's another possibility, although it's fleshed out even less than
> my previous one. Currently, IIRC, it is illegal to #define a keyword,
> but no diagnostic is required. (I couldn't find this rule anywhere in
> 16.3, so maybe I'm remembering it wrong?) Anyway, let's make it illegal
> to #define a keyword, but require a diagnostic. Also, let's make it
> illegal to #define a symbol that has been previously used in any scope.
>
>     #define if for // Illegal; if is a keyword
>     int foo() { int x=3; return x*x; }
>     #define x      // Illegal; x has already been used as a symbol

Makes some sense if x is visible at the point of #define,
but not in the above case, I guess. x is local to foo(), so
why should it prevent from being defined a macro which just
happens to have the same name?

--
Sungbom Kim <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 14 Oct 2002 15:05:13 +0000 (UTC), Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
>  allan_w@my-dejanews.com (Allan W) writes:
>  [...]
> | Here's another possibility, although it's fleshed out even less than
> | my previous one. Currently, IIRC, it is illegal to #define a keyword,
> | but no diagnostic is required. (I couldn't find this rule anywhere in
> | 16.3, so maybe I'm remembering it wrong?)
>
>  I would say you're remembering wrong.  A keyword is just an identifier
>  at translation phases 1 through 4.

It's illegal to #define a keyword when a standard library header is
included (see 17.4.3.1.1p2).

-- Niklas Matthies
--
Save Farscape - get informed and involved: http://farscape.wdsection.com/
Together, we can get Farscape back on air. Crackers *do* matter.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message
> What about retracting the preprocessor? ...
> .. and for everything else that macros are good for, while avoiding
> everything that macros are bad for.
>
It is easy to dismiss preprocessor as only tool to define constants
and snippets of code but there is definitely need for something to
support testing, debug versions and so on. I would welcome more
powerful preprocessor, not crippled one.

Example of nify use of preprocessor is ON_BLOCK_EXIT macro of
Alexandrescu's ScopeGuard library
(http://www.cuj.com/experts/1812/alexandr.htm?topic=experts).

/Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

andys@evo6.com (Andy Sawyer) wrote
> There are people who would rather have their teeth pulled than extend
> the preprocessor. I'm not one of them, but I certainly sympathise with
> that viewpoint.

Would all C++ programmers have to experience this, or could one or two
volunteers handle it for everyone? Would that be all of my teeth, or
just a few? I'm not saying I'll do it, you understand... I'm just
saying I'll consider it  :-)

What about retracting the preprocessor? If we didn't already have a
preprocessor to be compatible with, I might think it was a good idea --
but only if the symbol names used couldn't conflict with other symbols.
Perhaps allowing preprocessor symbols to start with a dollar sign
would be a good idea, and I highly doubt that this would conflict with
any existing code.

Then we could use preprocessor for conditional compilation
    #ifdef $debug
        std::cout << "a is " << a << std::endl;
    #endif

and for symbol substitution
    #define $assert(x) if(x);else assertfailed($__FILE__,$__LINE__)
    // ...
    assert(index<$INDEXLIMIT);

and for everything else that macros are good for, while avoiding
everything that macros are bad for.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brianatrimble@att.net wrote:
>      After working on a recent project I thought of how much I would like to
> have the power and explicit linking of macros to be combined with the
> type-checking from functions in ways that "inline" cannot guarantee.  Thus I
> submit the three following preprocessor directives.  #typedmacro and/or
> #mixmacro would extend the nature of #define macros into strongly typed,
> compiler checked meta-functions which could act as distinct code segments.
> #endmacro would then work like #endif to allow normal coding and even effects
> like namespaces.
>

If I understand correctly your request, it would be solved by extending
the template mechanism to a syntactically more approachable
meta-programming language. It is already a Turing complete compile time
interpreted langauge (if we assume infinite template instantiation
depth), but alas lacks certain constructs that would render it a
complete solution to virtually all code generation problems. As to the
inlining problem, I presume that the new compiler versions which would
support your extended preprocessor macros would also be able to handle
inlining in a sensible manner (inline functions with while statements
and other loop constructs or whatever is causing your problems with the
Borland compiler).

I would much more prefer this solution to extending the preprocessor.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechan kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

aatu.koskensilta@xortec.fi (Aatu Koskensilta) writes:

> I would much more prefer this solution to extending the
> preprocessor.

There are people who would rather have their teeth pulled than extend
the preprocessor. I'm not one of them, but I certainly sympathise with
that viewpoint.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

     After working on a recent project I thought of how much I would like to
have the power and explicit linking of macros to be combined with the
type-checking from functions in ways that "inline" cannot guarantee.  Thus I
submit the three following preprocessor directives.  #typedmacro and/or
#mixmacro would extend the nature of #define macros into strongly typed,
compiler checked meta-functions which could act as distinct code segments.
#endmacro would then work like #endif to allow normal coding and even effects
like namespaces.

     #typedmacro would have a set of concrete named arguments which would then
be expanded and inserted inline, regardless of having any loop structures or
other commands.
i.e. #typedmacro aplus(int length, int *array, int value);
        for(int idx=length-1; idx>=0; idx--)
        { (*array)+=value; array++; }
     #endmacro

     #mixmacro would mix concrete and abstract arguments to provide the
compiler time evaluation of the concrete arguments and the traditional power of
#define macros.
i.e. #mixmacro debug_aplus(int length, int *src, int value, [DebugText] );
       for(int idx=length-1; idx>=0; idx--)
       {  (*src)+=value;  DebugText  src++;  }
     #endmacro

called with debug_aplus(10,array,5,[printf("%d\n",*array);]) would expand
inline to:

      for(int idx=(10-1); idx>=0; idx--)
      {  (*array)+=value;   printf("%d\n",*array);  array++;  }

where the [ ] wrapper acts as the signifier to the compiler and could be nested
for calls to multiple mixmacros.

     The implementation for the typedmacro would be the simplest since it is a
#define macro with an extra compile-time check of it's arguments and hence I
believe would be easy to add to the standard.  The mixmacro though would be a
new pain to implement since it introduces the possibilty of nesting and
requires a parsing of its arguments.  Of these two I strongly wish I had
typedmacros so that I could build some reusable code which could be exposed
globally and be type checked but still insure it was expanded inline using the
variables therein.  The mixmacro is just here to complete the ideological world
of meta-programming, but it would remove the need for typedmacro if someone
else found a decent way to implement it in the standard.

Brian Trimble ( brianatrimble@att.net )

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brianatrimble@att.net writes:

>      After working on a recent project I thought of how much I would
> like to have the power and explicit linking of macros to be combined
> with the type-checking from functions in ways that "inline" cannot
> guarantee.

I fail to see why inline functions are not appropriate.

>      #typedmacro would have a set of concrete named arguments which
> would then be expanded and inserted inline, regardless of having any
> loop structures or other commands.

> i.e. #typedmacro aplus(int length, int *array, int value);
>         for(int idx=length-1; idx>=0; idx--)
>         { (*array)+=value; array++; }
>      #endmacro

This can be written as

inline void
aplus(int length, int *array, int value)
{
        for(int idx=length-1; idx>=0; idx--)
        { (*array)+=value; array++; }
}

> i.e. #mixmacro debug_aplus(int length, int *src, int value, [DebugText] );
>        for(int idx=length-1; idx>=0; idx--)
>        {  (*src)+=value;  DebugText  src++;  }
>      #endmacro

This would be more difficult to do in your proposed generality. To see
its use, you'ld need to present a few applications. For the example
given, I think

#ifdef DEBUG
inline void
aplus(int length, int *array, int value)
{
        for(int idx=length-1; idx>=0; idx--)
        { (*array)+=value; printf("%d\n",*array); array++; }
}
#else
inline void
aplus(int length, int *array, int value)
{
        for(int idx=length-1; idx>=0; idx--)
        { (*array)+=value; array++; }
}

#endif

seems to be sufficient: it is unclear why the caller of the macro
should need to know what debugging instruction to insert - you need to
know the internal structure of the macro to formulate the debugging
instruction, after all.

Regards,
Martin

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]