In article <37C1BAF0.7C4069A0@tribble.com>, David R Tribble
<david@tribble.com> writes
>Very few of which were created intentionally by either committee.
>There just wasn't enough communication between the two groups while
>they were in the midst of thrashing out all the changes to their
>respective language.

In some cases the differences were conscious but not malicious.  For
example C wanted complex numbers but the C++ route was not available.

We should also remember that at times C++ seems to have taken less than
maximal compatibility.  For example why is wchar_t a builtin type in
C++?  If C++ needed a new type (which I think it did) why did it not
include a new type such as _widechar and then use that in a typedef of
wchar_t.  We are going to have a wonderful time explaining to future
students why wchar_t is not a typedefed typename.

It is hard enough getting sufficient agreement (and understanding) in
one committee without trying to do it for two.  Once upon a time most
C++ experts were pretty good at C, but the reverse was never the case.
Now, how many C++ experts have extensive understanding of C9X?

Over all they have done pretty well, and the development of meetings in
the same time frame and locality will help improve mutual understanding
(well there are a few diehards on both committees that think that the
other language belongs to the devil)



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

david@tribble.com (David R Tribble) wrote:
> > > There are still many things that can be (and have to be) done using
> > > macros that C++ simply can't do any other way.

[various examples and workarounds]

> What if I only need one line that differs from OS to OS?  I should
> go through all this trouble simply to avoid a few #ifs?

Sure. C++ has a lot of infrastructure to help minimise any redundancy,
like virtual functions and templates. Or use one of the other idioms.


> And what about the #error?  (I should use #pragma perhaps?)

It wouldn't be needed in this case. Instead of:
   #define OS_WIN32

you would have some way of specifying the subclass, like:
    OsHandler *NewOsHandler() { return new OsWin32; }

(or a link-time equivalent) and there would be no class you could specify.

More generally, there are template idioms that produce compile-time errors
when certain conditions are met. They can handle your Foo_VERS example.


> Uh huh.  So you don't use '#if 0 ... #endif'?

I use it, because it's there. I can live without it by using comments
instead. In practice in Java I use "//" for "real" comments and "/* */"
for commenting out large blocks, so there isn't much conflict. And when
there is it's easy to sort out. Maybe we wouldn't need nested comments
even if conditional compilation /was/ removed.


> > (Some people think it's deplorable style anyway.)
>
> What, checking for errors?

No, having a release version which differs significantly from the debug
version. Changing data members being "significant".


>> [__LINE__, __FILE__]

Yes, those are useful, but they weren't among your original examples!

(In Java they are supported indirectly through the exception library's
stack-trace feature, which is clumsy but just about acceptable given that
they are mainly used for low-level error reporting and debugging. C++
doesn't have such a mechanism so something new (and hopefully better)
would need to be added.)


> Sorry, but I still haven't seen a demonstration that convinces me
> that we are ready to remove conditional compilation from the language.

You originally wrote, "simply can't do any other way". For all your
original examples, there was another way.

I was being pedantic. I wouldn't necessarily use the other way each time.
On the other hand, even where it is more work it is often better. For
example, centralising OS-dependencies in a few specific classes is better
than scattering conditional compilation through-out the code. #ifdef is
*too* convenient, sometimes. And it's generally better not to pollute the
name space.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
>
> Salters wrote in message <37C16204.D97ABEE1@lucent.com>...
> >Gabriel Dos_Reis wrote:
> >> clog,  an "existing" pratice in traditional C++ and part of
> >> Standard C++, used to name an object of type ostream.
> >> C9x committee deliberatly defines a function in <math.h> whose
> >> name is clog.
> >
> > Now, I could be mistaken (that has happened), but didn't you mean
> > std::clog?
>
> If a future version of C++ were to follow C's lead and put clog in
> <math.h> you'd expect that it would want to put std::clog in <cmath>
> (except for the obvious collision with the clog from <iostream>).

They chose 'cin' (~ 'stdin') and 'cout' (~ 'stdout'), so one wonders
why they didn't choose 'cerr' (~ 'stderr') instead of 'clog'.

-- David R. Tribble, david@tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Salters wrote in message <37C16204.D97ABEE1@lucent.com>...
>Gabriel Dos_Reis wrote:
>> clog,  an "existing" pratice in traditional C++ and part of Standard
>> C++, used to name an object of type ostream. C9x committee deliberatly
>> defines a function in <math.h> whose name is clog.
>
>Now, I could be mistaken (that has happened), but didn't you mean
std::clog?

If a future version of C++ were to follow C's lead and put clog in <math.h>
you'd expect that it would want to put std::clog in <cmath> (except for the
obvious collision with the clog from <iostream>).
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:
>
> Francis Glassborow <francis@robinton.demon.co.uk> writes:
>
> | In article <xaj3dxfzies.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
> | <gdosreis@korrigan.inria.fr> writes
> | > I guess it is a question of personal appreciation.  Those who are
> | > not concerned with type uses say I'm exagerating.  Those who are
> | > concerned with type issues are worried.
> |
> | There is a difference between being worried and writing something
> | that seems to impute that the C Committees deliberately sought ways
> | to be different from C++.
>
> clog,  an "existing" pratice in traditional C++ and part of Standard
> C++, used to name an object of type ostream. C9x committee deliberatly
> defines a function in <math.h> whose name is clog.

And 'bool' is different, and so is 'complex', and so on and so forth.
Yes, there are a dozen or so incompatibilities between C9X and C++.
(I posted a nearly complete list recently.)

Very few of which were created intentionally by either committee.
There just wasn't enough communication between the two groups while
they were in the midst of thrashing out all the changes to their
respective language.

-- David R. Tribble, david@tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dave Harris wrote:
>
> david@tribble.com (David R Tribble) wrote:
> > There are still many things that can be (and have to be) done using
> > macros that C++ simply can't do any other way.
> >
> >     void Foo::bar(int i)
> >     {
> >     #if DEBUG
> >         cdbg << "Foo::bar(" << i << ")\n";
> >     #endif
>
> Try:
>     const bool debug = false;
>     void Foo::bar(int i)
>     {
>         if (debug)
>             cdbg << "Foo::bar(" << i << ")\n";
>
> A good compiler will optimise away both test and body of the "if".

How about:

    int main(int argc, char **argv)
    {
    #if DEBUG
        dbg_open("program.dbg");
    #endif
        ...
    }

And with the upcoming C9X (C0X), I can do this:

    #define ENTER()  dbg_enter(__func__, __FILE__, __LINE__)
    #define LEAVE()  dbg_leave(__func__, __FILE__, __LINE__)

    int myfunc(int a)
    {
        ENTER();
        ...
        LEAVE();
        return (0);
    }

> >     #if OS_WIN32
> >         ...code specific to Win32
> >     #elif OS_UNIX
> >         ...
> >     #else
> >         #error Unsupported O/S
> >     #endif
>
> Put the Win32 code into a subclass and use virtual functions. (Or
> choose the subclass at link-time and use non-virtual functions, or
> use the previous idiom).

What if I only need one line that differs from OS to OS?  I should
go through all this trouble simply to avoid a few #ifs?

And what about the #error?  (I should use #pragma perhaps?)

> >     #if is_incomplete_
> >         func_that_is_not_written_yet(i);
> >         ...syntactically incomplete [pseudo-]code...
> >     #endif
>
> Use comments. OK, maybe we need nested comments.

Uh huh.  So you don't use '#if 0 ... #endif'?

> Java doesn't have a pre-processor. I only miss them for things which
> the "if(0)" idiom doesn't cover, like:
>
>      class Collection {
>          Item *m_pItems;
>      #ifdef _DEBUG
>          int m_count;
>      #endif
>          //...
>      };
>
> where the debug version has extra data for performing sanity checks.
> And I can live without that. (Some people think it's deplorable
> style anyway.)

What, checking for errors?

And how about this:

    // foo.hpp

    #define Foo_VERS  1

    class Foo { ... };


    // foo.cpp

    #include "foo.hpp"

    int Foo::bar()
    {
    #if Foo_VERS != 1
     #error class Foo has changed
     // This function may need rewriting
    #endif
        ...
    }

I avoid macros as much as possible, but sometimes it simply isn't
possible.  Sorry, but I still haven't seen a demonstration that
convinces me that we are ready to remove conditional compilation
from the language.

-- David R. Tribble, david@tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> writes:

| In article <xaj3dxfzies.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
| <gdosreis@korrigan.inria.fr> writes
| >I guess it is a question of personal appreciation.  Those who are not
| >concerned with type uses say I'm exagerating.  Those who are concerned
| >with type issues are worried.
|
| There is a difference between being worried and writing something that
| seems to impute that the C Committees deliberately sought ways to be
| different from C++.

clog,  an "existing" pratice in traditional C++ and part of Standard
C++, used to name an object of type ostream. C9x committee deliberatly
defines a function in <math.h> whose name is clog.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Gabriel Dos_Reis wrote:

> Francis Glassborow <francis@robinton.demon.co.uk> writes:


> | There is a difference between being worried and writing something that
> | seems to impute that the C Committees deliberately sought ways to be
> | different from C++.

> clog,  an "existing" pratice in traditional C++ and part of Standard
> C++, used to name an object of type ostream. C9x committee deliberatly
> defines a function in <math.h> whose name is clog.

Now, I could be mistaken (that has happened), but didn't you mean std::clog?
Those namespaces may one day become essential - if C doesn't claim the std
keyword. Maybe they should reserve it, too, to prevent porting problems.
The again, maybe they should reserve new, delete, class, operator ,throw,
try, and catch, too. (What more of C++ is not in std:: ?)

Michiel Salters


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Salters <salters@lucent.com> writes:

| Gabriel Dos_Reis wrote:
|
| > Francis Glassborow <francis@robinton.demon.co.uk> writes:
|
|
| > | There is a difference between being worried and writing something that
| > | seems to impute that the C Committees deliberately sought ways to be
| > | different from C++.
|
| > clog,  an "existing" pratice in traditional C++ and part of Standard
| > C++, used to name an object of type ostream. C9x committee deliberatly
| > defines a function in <math.h> whose name is clog.
|
| Now, I could be mistaken (that has happened), but didn't you mean std::clog?

Actually, no.  <math.h> makes symboles available in global namespace
*and* namespace std.

| Those namespaces may one day become essential - if C doesn't claim the std
| keyword. Maybe they should reserve it, too, to prevent porting problems.
| The again, maybe they should reserve new, delete, class, operator ,throw,
| try, and catch, too. (What more of C++ is not in std:: ?)

Why not to rename it C++? ;-)

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com writes:

| In article <xajbtck7qcb.fsf@korrigan.inria.fr>,
|   Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:
|
|     [...]
| > | #3
| > | One of the key reasons why C++ has become such a popular programming
| > | language is precisely that it coexists so well with C:  mixed C/C++
| > | systems work well, and the two languages can mix right down to the
| > | function level.  Notably, C++ code benefits greatly from being able
| > | to #include C header files.  Now think about trying to use C++ for a
| > | subsystem of an otherwise-C9X project, where the project header
| files
| > | use varargs macros.
|
| > But C9x made the best it could to diverge from Standard C++.
|
| That's probably an exageration, although they certainly could have done
                     ^^^^^^^^^^^
| better.

I guess it is a question of personal appreciation.  Those who are not
concerned with type uses say I'm exagerating.  Those who are concerned
with type issues are worried.

| WRT the preprocessor, however, they actually adopted one C++ism: //
| comments.  At present, I think the absence of vararg macros is the only
| difference in the preprocessor.  As such, I would imagine most
| implementers would prefer to see it in C++ as well, if only because it
| would mean not having to use a (slightly) different preprocessor.

I never understand why people insist with Cpp instead of looking for
less dumb text processor.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <xaj3dxfzies.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
<gdosreis@korrigan.inria.fr> writes
>I guess it is a question of personal appreciation.  Those who are not
>concerned with type uses say I'm exagerating.  Those who are concerned
>with type issues are worried.

There is a difference between being worried and writing something that
seems to impute that the C Committees deliberately sought ways to be
different from C++.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <memo.19990817222025.8533G@btinternet.com>, brangdon@cix.co.uk wrote:

[snip]
> Java doesn't have a pre-processor. I only miss them for things which the
> "if(0)" idiom doesn't cover, like:
>
>      class Collection {
>          Item *m_pItems;
>      #ifdef _DEBUG
>          int m_count;
>      #endif
>          //...
>      };
>
> where the debug version has extra data for performing sanity checks. And I
> can live without that. (Some people think it's deplorable style anyway.)

You don't need the preprocessor here either. First, a helpful template
type selector:

    template<bool which,typename T_true,typename T_false>
    struct select_type {
        typedef T_true type;
    };

    template<bool which,typename T_true,typename T_false>
    struct select_type<false,T_true,T_false> {
        typedef T_false type;
    };

    // select_type<false,int,double>::type -> double
    // select_type<true ,int,double>::type -> int

    struct empty_struct { }; // you'll see... :-)

A debug vars base class:

    class Collection_debug_ {
        friend class Collection;
        int m_count;
    };

And the collection:

    class Collection :
            select_type<debug, Collection_debug_, empty_struct>::type {
        // ...
    };

Now collection has m_count only during debugging. Of course, trying to use
m_count in Collection's member functions wouldn't work unless it was
sectioned off with the preprocessor. A solution to this is to put inline
member functions in Collection_debug_ that act on count. They'd also need
to be added to a non-debug class too.

I admit this is not practical in all cases, but perhaps it shows the power
of templates for similar things.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <xajbtck7qcb.fsf@korrigan.inria.fr>,
  Gabriel Dos_Reis <gdosreis@korrigan.inria.fr> wrote:

    [...]
> | #3
> | One of the key reasons why C++ has become such a popular programming
> | language is precisely that it coexists so well with C:  mixed C/C++
> | systems work well, and the two languages can mix right down to the
> | function level.  Notably, C++ code benefits greatly from being able
> | to #include C header files.  Now think about trying to use C++ for a
> | subsystem of an otherwise-C9X project, where the project header
files
> | use varargs macros.

> But C9x made the best it could to diverge from Standard C++.

That's probably an exageration, although they certainly could have done
better.

WRT the preprocessor, however, they actually adopted one C++ism: //
comments.  At present, I think the absence of vararg macros is the only
difference in the preprocessor.  As such, I would imagine most
implementers would prefer to see it in C++ as well, if only because it
would mean not having to use a (slightly) different preprocessor.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

david@tribble.com (David R Tribble) wrote:
> There are still many things that can be (and have to be) done using
> macros that C++ simply can't do any other way.
>
>     void Foo::bar(int i)
>     {
>     #if DEBUG
>         cdbg << "Foo::bar(" << i << ")\n";
>     #endif

Try:

    const bool debug = false;
    void Foo::bar(int i)
    {
        if (debug)
            cdbg << "Foo::bar(" << i << ")\n";

A good compiler will optimise away both test and body of the "if".


>     #if OS_WIN32
>         ...code specific to Win32
>     #elif OS_UNIX
>         ...
>     #else
>         #error Unsupported O/S
>     #endif

Put the Win32 code into a subclass and use virtual functions. (Or choose
the subclass at link-time and use non-virtual functions, or use the
previous idiom).


>     #if is_incomplete_
>         func_that_is_not_written_yet(i);
>         ...syntactically incomplete [pseudo-]code...
>     #endif

Use comments. OK, maybe we need nested comments.

Java doesn't have a pre-processor. I only miss them for things which the
"if(0)" idiom doesn't cover, like:

     class Collection {
         Item *m_pItems;
     #ifdef _DEBUG
         int m_count;
     #endif
         //...
     };

where the debug version has extra data for performing sanity checks. And I
can live without that. (Some people think it's deplorable style anyway.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[discussing '__VA_ARGS__' of C9X for C++]

Steve Clamage wrote:
> I think that in general we should adopt all C9X features that are
> not incompatible with C++. (The remainder require analysis.) This
> feature is a pure extension that as far as I can see doesn't cause
> any problems for C++.
>
> The counter argument, I suppose, is that C++ should not introduce
> any feature that encourages use of macros. But I think that
> compiler vendors who provide both C and C++ will introduce C9X
> features to the extent possible in their C++ compilers in
> any event.

When C++ (the language) becomes sufficiently powerful enough to
supplant the functionality of the preprocessor, then we can consider
removing the preprocessor from C++.  But not a day sooner than that.

There are still many things that can be (and have to be) done using
macros that C++ simply can't do any other way.

    void Foo::bar(int i)
    {
    #if DEBUG
        cdbg << "Foo::bar(" << i << ")\n";
    #endif

        ...

    #if OS_WIN32
        ...code specific to Win32
    #elif OS_UNIX
        ...
    #else
        #error Unsupported O/S
    #endif

        ...

    #if is_incomplete_
        func_that_is_not_written_yet(i);
        ...syntactically incomplete [pseudo-]code...
    #endif

        ...
    }

I haven't seen a better way to do this without using the preprocessor.
Especially the '#error'.

And someone please tell me how to turn off Microsoft's
'__declspec(dllimport)' in my porable code that runs on both Win32
and Unix systems.  I currently use macro magic today.

-- David R. Tribble, david@tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello!

I have a problem:
I want to create a macro with variable argument list, like:

#define T(x) Test(x)

void Test(char *s, ...)
{


}

T("%u",2);  doesn't work, an error 'number of arguments not ok in call of
macro T()'. Is there a possibility to define a macro with variable parameter
input?

Thanks...
UwE

uloehnert@init-ka.de
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7o92cv$drs$1@black.news.nacamar.net>, Uwe Loehnert
<uloehnert@init-ka.de> writes
>T("%u",2);  doesn't work, an error 'number of arguments not ok in call of
>macro T()'. Is there a possibility to define a macro with variable parameter
>input?

Not until C++ elects to adopt the C9X proposals.  Actually I cannot
think of any reason why we should.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> writes:

>In article <7o92cv$drs$1@black.news.nacamar.net>, Uwe Loehnert
><uloehnert@init-ka.de> writes
>>T("%u",2);  doesn't work, an error 'number of arguments not ok in call of
>>macro T()'. Is there a possibility to define a macro with variable parameter
>>input?

>Not until C++ elects to adopt the C9X proposals.  Actually I cannot
>think of any reason why we should.

I think that in general we should adopt all C9X features that are
not incompatible with C++. (The remainder require analysis.) This
feature is a pure extension that as far as I can see doesn't cause
any problems for C++.

The counter argument, I suppose, is that C++ should not introduce
any feature that encourages use of macros. But I think that
compiler vendors who provide both C and C++ will introduce C9X
features to the extent possible in their C++ compilers in
any event.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In an article to which I have alas lost the reference,
Francis Glassborow <francis@robinton.demon.co.uk> wrote:
(about adopting C9X varargs macros in C++)
[...] I cannot think of any reason why we should.

In article <7ochu9$1gr$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@eng.sun.com> replied:
> I think that in general we should adopt all C9X features that are
> not incompatible with C++. (The remainder require analysis.) This
> feature is a pure extension that as far as I can see doesn't cause
> any problems for C++.

3 points in support of Steve Clamage's argument:

#1 [Admittedly an argument from authority]
A famous remark by Stroustrup runs roughly (my copy of D&EC++ is at
home so I can't check the exact wording) that C++ should be "as close
as possible, but no closer" to being a superset of C.

#2
(again quoting Steve Clamage)
> The counter argument, I suppose, is that C++ should not introduce
> any feature that encourages use of macros.
This way lies Pascal!  The basic philosophy of C++ is to try and
provide mechanisms for doing things in "nice" ways, but not forbid
"ugly" ways.  That is, C++ assumes that the programmer knows what s/he's
doing.  So, IMHO "C++ should not introduce any feature that encourages
use of macros" isn't appropriate here -- in C++ we trust the programmer
to use the appropriate tools for her/his job, and if those turn out to
include macros, we shouldn't try to throw up roadblocks.

#3
One of the key reasons why C++ has become such a popular programming
language is precisely that it coexists so well with C:  mixed C/C++
systems work well, and the two languages can mix right down to the
function level.  Notably, C++ code benefits greatly from being able
to #include C header files.  Now think about trying to use C++ for a
subsystem of an otherwise-C9X project, where the project header files
use varargs macros.

--
-- Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
     Amount of all stock owned by the least wealthy 90% of America: 18%
     Amount of all stock owned by the most wealthy 1% of America: 41%
      -- Economic Policy Institute



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Uwe Loehnert wrote:
>
> Hello!
>
> I have a problem:
> I want to create a macro with variable argument list, like:
>
> #define T(x) Test(x)
>
> void Test(char *s, ...)
> {
>
> }
>
> T("%u",2);  doesn't work, an error 'number of arguments not ok in call of
> macro T()'. Is there a possibility to define a macro with variable parameter
> input?

You can have a workaround for this:

#define T(x) (Test x)

Then T(("%u",2)) would work


Regards, Igor Boukanov
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jthorn@davinci.thp.univie.ac.at (Jonathan Thornburg) writes:

| In an article to which I have alas lost the reference,
| Francis Glassborow <francis@robinton.demon.co.uk> wrote:
| (about adopting C9X varargs macros in C++)
| [...] I cannot think of any reason why we should.
|
| In article <7ochu9$1gr$1@engnews1.eng.sun.com>,
| Steve Clamage <clamage@eng.sun.com> replied:
| > I think that in general we should adopt all C9X features that are
| > not incompatible with C++. (The remainder require analysis.) This
| > feature is a pure extension that as far as I can see doesn't cause
| > any problems for C++.
|
| 3 points in support of Steve Clamage's argument:
|
| #1 [Admittedly an argument from authority]
| A famous remark by Stroustrup runs roughly (my copy of D&EC++ is at
| home so I can't check the exact wording) that C++ should be "as close
| as possible, but no closer" to being a superset of C.

Well, from my reading of D&E, it strikes me that Bjarne doesn't like
Cpp:

 %
 %  ... I didn't like Cpp at all, and I still don't like it.
 %

 %
 % Cpp isn't even a very good macroprocessor.  Consequently, I set out
 % to make Cpp redundant.
 %

 %
 % ... I could live without #pragma because I have never seen a pragma
 % that I liked.  Too often, #pragma seems to be used to sneak
 % variations of language semantics into a compiler and to provide
 % extensions with very specialized semantics and awkward syntax.
 %

And he concluded the chapter on Cpp:

 % I'd like to see Cpp abolished.  However, the only realistic and
 % responsible way of doing that is first to make it redundant, then
 % encourage people to use better alternatives, and /then/ -- years
 % later -- banish Cpp into the program development environment with
 % the other extra-linguistic tools where it belongs.

I don't think that a responsible way to abolish Cpp later, would
consists in adopting massively all macros that C9x finds useful -- to
circumvent its own limitations.

[...]

| #3
| One of the key reasons why C++ has become such a popular programming
| language is precisely that it coexists so well with C:  mixed C/C++
| systems work well, and the two languages can mix right down to the
| function level.  Notably, C++ code benefits greatly from being able
| to #include C header files.  Now think about trying to use C++ for a
| subsystem of an otherwise-C9X project, where the project header files
| use varargs macros.

But C9x made the best it could to diverge from Standard C++.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7oee15$c7o$1@davinci.thp.univie.ac.at>, Jonathan Thornburg
<jthorn@davinci.thp.univie.ac.at> writes
>#1 [Admittedly an argument from authority]
>A famous remark by Stroustrup runs roughly (my copy of D&EC++ is at
>home so I can't check the exact wording) that C++ should be "as close
>as possible, but no closer" to being a superset of C.

Yes, but I am not convinced that we should take on board every future
(as from 1989) change to C.  Each should be examined for utility.  I
think we should look carefully at extensions to the pre-processor.  Note
that I have never said how we should decide, only suggested that the
answer should be thought about.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jthorn@davinci.thp.univie.ac.at (Jonathan Thornburg) writes:

>In an article to which I have alas lost the reference,
>Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>(about adopting C9X varargs macros in C++)
>[...] I cannot think of any reason why we should.

>In article <7ochu9$1gr$1@engnews1.eng.sun.com>,
>Steve Clamage <clamage@eng.sun.com> replied:
>> I think that in general we should adopt all C9X features that are
>> not incompatible with C++. (The remainder require analysis.) This
>> feature is a pure extension that as far as I can see doesn't cause
>> any problems for C++.

>3 points in support of Steve Clamage's argument:

>#1 [Admittedly an argument from authority]
>A famous remark by Stroustrup runs roughly (my copy of D&EC++ is at
>home so I can't check the exact wording) that C++ should be "as close
>as possible, but no closer" to being a superset of C.

But Stroustrup is on record as wanting to remove the preprocessor
entirely from C++. In other words, "close as possible" needn't
include macros, and less-so extensions to the macro facility.

>#2
>(again quoting Steve Clamage)
>> The counter argument, I suppose, is that C++ should not introduce
>> any feature that encourages use of macros.
>This way lies Pascal!

Huh? There is little need for macros in C++, and they often cause
more problems than they solve. How is this situation like or
unlike the philosophy behind Pascal?

>The basic philosophy of C++ is to try and
>provide mechanisms for doing things in "nice" ways, but not forbid
>"ugly" ways.  That is, C++ assumes that the programmer knows what s/he's
>doing.

If that were so, C++ would not be as strongly typed as it is,
and would not make impossible as many things as it does.
(Try to work around the constructor/destructor or virtual
function mechanisms, for example. C++ most defintely does not
trust the programmer anywhere near those areas.)

You are correct that C++ does not try to prevent ugly programming
(a losing game in any event), and indeed supports a variety of
programming styles. That is not the same thing as "trusting
the programmer."

>#3
>One of the key reasons why C++ has become such a popular programming
>language is precisely that it coexists so well with C:  mixed C/C++
>systems work well, and the two languages can mix right down to the
>function level.  Notably, C++ code benefits greatly from being able
>to #include C header files.  Now think about trying to use C++ for a
>subsystem of an otherwise-C9X project, where the project header files
>use varargs macros.

Right. Which is the only reason why I think adding varargs macros
to C++ is not necessarily a bad idea.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]