Paul D. DeRocco wrote <3650FB93.638B4E47@ix.netcom.com> ...
>
>I'm generally in favor of simple changes like this, as long as they
>simplify code writing in some way, and don't break any existing legal
>programs. I had hoped to convince the standard committee to throw in
>binary numbers (e.g., 0y11011111), or to allow underscores in numbers to
>improve readability of long numbers (e.g., 1_000_000_000), since those
>changes would take only about a half a man-day of programming time in a
>typical compiler, but I guess it didn't seem hip enough for anyone to
>get excited about. This proposal may suffer the same fate. ;-)


  I think that long numbers syntax like 1_000_000_000 can be achieved using
the macros without extending the Standard:
Consider:
       cat4(1,000,000,000)
where cat4 is macro that will clue the all it's args togather. The name of
the macro can be made more obvious, like num32(x,y,z,u) - since all decimial
representations of the 32 digit numbers
fit in 10 digits - ie the macro will have 4 args. For 64 bit-machines there
can exist other macros that take another number of arguments.
To specifiy number less 10^10 the 1st argument can be left blank in macro:
       cat4(,999,999,999)

PS: I have mailed this message 20.10.98, but i don't see it in this thread
(25.11.98) so i decided to resend it. May be something with my newsreader
  I'm sorry if it's a duplicate.

- Vlad




[ 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              ]

> Jim Cobban <Jim.Cobban.jcobban@nt.com> wrote:
> > This is more appropriately a topic for the C discussion group.
> > Macros exist in C++ primarily for backwards compatibility, since
> > almost all of their functionality has been replaced by inline
> > functions and static constant class members and unnamed namespace
> > file level constants.  There is...

> Ruslan@Shevchenko.Kiev.UA wrote:
> > No. exists few things that you can not do without macroses.
> > for example
> >     #include FILE_WHICH_CHOOSED_DURING_COMPILATION_H

In article <3659C87E.2F49@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:
> Another example is conditional compilation:
>     #if DEBUG > 0
>         ...debugging code...
>     #endif

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

>     #ifdef This_code_is_not_yet_finished_
>         ...incomplete code
>     #endif

> But to be fair to Jim and the anti-preprocessor zealots, we could
> probably get rid of most of the preprocessor facilities of C++,
> except for what is minimally required for conditional compilation,
> and still have a usable language.  We still need #include, too,
> since C++ still forces the use of header files.  And #pragma for
> implementation-specific features.  Oh, and #error for reporting
> ill-defined porting macros.  Oh, and #line for compiling generated
> C++ code.

> So, let's see, that narrows it down to only these preprocessor items:
>     #define
>     #undef
>     #if, #ifdef, #ifndef
>     #else, #elif
>     #endif
>     #include
>     #error
>     #pragma
>     #line

> Gee, that looks a lot like the whole list.  Quite a lot of the
> preprocessor appears to be required just to support "backwards
> compatibility with C".

> I don't like abuses of the preprocessor any more than the next guy,
> but the truth is, the preprocessor is still a useful and powerful
> programming facility of both C and C++, and while many of its uses
> in C++ were replaced by cleaner language facilities, there are
> still whole areas of capabilities that C++ didn't replace.  Which
> means that we're not getting rid of the C++ preprocessor for a
> while yet.

> But I'm sure we are all open to suggestions for replacing its
> uses by added more features to the C++ language.  I for one, for
> example, would like to see a reasonable replacement for #include
> and header files in general (like Java and Eiffel have).  Perhaps
> something like the 'import' or 'package' facilites of Java?

> But I really, really don't see #if...#endif ever going away; it's
> just too useful.

I'm not an anti-preprocessor zealot, but I do agree with the
general trend to move away from the need for it. However, it
has many powerful features; in fact, the only one that I don't
like is the very one that Mr. Tribble completely forgot to
mention: token replacement.
    #define MacroStuff(a,b,c) if(a){(b)=(c)};else;
should be replaced with
    template<class X> inline
    void TemplateStuff(bool a, X&b, const X&c) { if (a) b=c; }
for reasons I'm sure you're familiar with. By the same token,
    #ifdef DEBUG
      #define DEBUGSAY(x) if(0);else std::cout<<(x)<<std::endl;
    #else
      #define DEBUGSAY(x)
    #endif
should be replaced with
    template<class X>inline void DEBUGSAY(const X&x){
    #ifdef DEBUG
        std::cout << x << std::endl;
    #endif
    }
In fact, I would say that MOST uses of macro substitution should
be replaced, although I'm not ready to say that ALL of them
should be. I don't think the language has evolved far enough away
from C to make that reasonable.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

Jim Cobban <Jim.Cobban.jcobban@nt.com> wrote:
> This is more appropriately a topic for the C discussion group.
> Macros exist in C++ primarily for backwards compatibility, since
> almost all of their functionality has been replaced by inline
> functions and static constant class members and unnamed namespace
> file level constants.  There is...

Ruslan@Shevchenko.Kiev.UA wrote:
> No. exists few things that you can not do without macroses.
> for example
>     #include FILE_WHICH_CHOOSED_DURING_COMPILATION_H

Another example is conditional compilation:
    #if DEBUG > 0
        ...debugging code...
    #endif

    #if OS_UNIX
        ...code for Unix...
    #elif OS_WIN32
        ...code for Win32...
    #else
        #error Unsupported O/S
    #endif

    #ifdef This_code_is_not_yet_finished_
        ...incomplete code
    #endif

But to be fair to Jim and the anti-preprocessor zealots, we could
probably get rid of most of the preprocessor facilities of C++,
except for what is minimally required for conditional compilation,
and still have a usable language.  We still need #include, too,
since C++ still forces the use of header files.  And #pragma for
implementation-specific features.  Oh, and #error for reporting
ill-defined porting macros.  Oh, and #line for compiling generated
C++ code.

So, let's see, that narrows it down to only these preprocessor items:
    #define
    #undef
    #if, #ifdef, #ifndef
    #else, #elif
    #endif
    #include
    #error
    #pragma
    #line

Gee, that looks a lot like the whole list.  Quite a lot of the
preprocessor appears to be required just to support "backwards
compatibility with C".

I don't like abuses of the preprocessor any more than the next guy,
but the truth is, the preprocessor is still a useful and powerful
programming facility of both C and C++, and while many of its uses
in C++ were replaced by cleaner language facilities, there are
still whole areas of capabilities that C++ didn't replace.  Which
means that we're not getting rid of the C++ preprocessor for a
while yet.

But I'm sure we are all open to suggestions for replacing its
uses by added more features to the C++ language.  I for one, for
example, would like to see a reasonable replacement for #include
and header files in general (like Java and Eiffel have).  Perhaps
something like the 'import' or 'package' facilites of Java?

But I really, really don't see #if...#endif ever going away; it's
just too useful.

-- David R. Tribble, dtribble@technologist.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 article <3659C87E.2F49@noSPAM.central.beasys.com>, David R Tribble
<david.tribble@noSPAM.central.beasys.com> writes
>I don't like abuses of the preprocessor any more than the next guy,
>but the truth is, the preprocessor is still a useful and powerful
>programming facility of both C and C++, and while many of its uses
>in C++ were replaced by cleaner language facilities, there are
>still whole areas of capabilities that C++ didn't replace.  Which
>means that we're not getting rid of the C++ preprocessor for a
>while yet.

Fire is also a useful tool, but we try not to use it on buildings, only
in them:)  In other words we need dangerous tools but we also need to
respect them and not abuse them.  IMHO too many abuse the preprocessor
perhaps because they have never been taught its uses.  You know, wise
parents do not tell children 'not to play with matches' and just leave
it at that:)


Francis Glassborow      Chair of 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              ]

Paul D. DeRocco writes in <3650FB93.638B4E47@ix.netcom.com> ...
>
>I'm generally in favor of simple changes like this, as long as they
>simplify code writing in some way, and don't break any existing legal
>programs. I had hoped to convince the standard committee to throw in
>binary numbers (e.g., 0y11011111), or to allow underscores in numbers to
>improve readability of long numbers (e.g., 1_000_000_000), since those
>changes would take only about a half a man-day of programming time in a
>typical compiler, but I guess it didn't seem hip enough for anyone to
>get excited about. This proposal may suffer the same fate. ;-)
>
>--
>
>Ciao,
>Paul
>

  I think that long numbers syntax like 1_000_000_000 can be achieved using
the macros without extending the Standard:
Consider:
       cat4(1,000,000,000)
where cat4 is macro that will clue the all it's args togather. The name of
the macro can be made more obvious, like
num32(x,y,z,u) - since all decimial representations of the 32 digit numbers
fit in 10 digits - ie the macro will have 4 args. For 64 bit-machines there
can exist other macros that take another number of arguments.

To specifiy number less 10^9 the 1st argument can be left blank in macro:
       cat4(,999,999,999)
---
[ 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              ]

Siemel Naran wrote:
>
> An old assembler for the Apple I had used '%' for binary numbers.
> Is this the standard symbol for binary?

I've seen that before, too. To be consistent with C/C++, I suggest a
prefix of either 0b or 0y for binary. The b stands for binary, but could
be mistaken by a human reader for a hex digit. The y is the last letter
of binary (just as x is the last letter of hex), but it looks enough
like an x that it might occasionally be mistaken for an x. I gravitate
toward 0y, but am not a zealot about it.

--

Ciao,
Paul


[ 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 <72q9th$a6r$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes

>It doesn't break any existing code. It's easy to use, and it's
>meaning is intuitive.

>The only serious objection can be that it makes it easier to
>use the preprocessor, while most of the language is trying to
>move away from the preprocessor. But that's not a very good
>reason. The proposal doesn't make any of the alternatives
>harder, so it doesn't really encourage use of the preprocessor.
>It's along the lines of, "if you have to do it anyway, this
>should make it a little bit easier."

>I like the idea.

I'd rather like an #undef ALL facility:)


Francis Glassborow      Chair of 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              ]

?
? This is more appropriately a topic for the C discussion group.  Macros exist
? in C++ primarily for backwards compatibility, since almost all of their
? functionality has been replaced by inline functions and static constant
? class members and unnamed namespace file level constants.  There is

 No. exists few things that you can not do without macroses.

for example
#include FILE_WHICH_CHOOSED_DURING_COMPILATION_H




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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 <72t7mr$sfd$1@nnrp1.dejanews.com> Ruslan@Shevchenko.Kiev.UA writes:
>? This is more appropriately a topic for the C discussion group.  Macros exist
>? in C++ primarily for backwards compatibility, since almost all of their
>? functionality has been replaced by inline functions and static constant
>? class members and unnamed namespace file level constants.  There is
>
> No. exists few things that you can not do without macroses.
>
>for example
>#include FILE_WHICH_CHOOSED_DURING_COMPILATION_H

This is a rare coding style and often more appropriate for machine
generated code than anything.  The original poster did NOT say that the
preprocessor no longer has ANY uses, but that in the grand scheme of
things, macros exist in C++ PRIMARILY for backwards compatibility.
This is not debatable.  It was a continued and conscious language
design decision.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]

On 17 Nov 1998 17:32:47 GMT, Paul D. DeRocco <pderocco@ix.netcom.com> wrote:

>I'm generally in favor of simple changes like this, as long as they
>simplify code writing in some way, and don't break any existing legal
>programs. I had hoped to convince the standard committee to throw in
>binary numbers (e.g., 0y11011111), or to allow underscores in numbers to
>improve readability of long numbers (e.g., 1_000_000_000), since those
>changes would take only about a half a man-day of programming time in a
>typical compiler, but I guess it didn't seem hip enough for anyone to
>get excited about. This proposal may suffer the same fate. ;-)

Both of these are excellent additions!  It always takes conscious
thought for me to write binary numbers in hex, especially when two
or more bits are on.  And for big integers, I have on occassion
missed a zero or two, which in turn caused an hour or so tracking
down the problem.

An old assembler for the Apple I had used '%' for binary numbers.
Is this the standard symbol for binary?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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              ]

Consider example:
#undef A
#undef B
#undef C

Why don't extend the syntax to
#undef A B C

IMO such extension won't break any other semantical rules for preprocessor,
but will reduce the size of the code that extensively uses macros. And (IMO
more important) will reduce the number of lines in the source file - this
helps editing and viewing the code
 since more lines of code fits on one screen.
---
[ 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 <3650ac18.0@monster.ssau.ru>,
Vlad Harchev <vladhar@imimail.ssau.ru> wrote:
>Consider example:
>#undef A
>#undef B
>#undef C
>
>Why don't extend the syntax to
>#undef A B C
>
>IMO such extension won't break any other semantical rules for preprocessor,
>but will reduce the size of the code that extensively uses macros. And (IMO
>more important) will reduce the number of lines in the source file - this
>helps editing and viewing the code
> since more lines of code fits on one screen.

This is more appropriately a topic for the C discussion group.  Macros exist
in C++ primarily for backwards compatibility, since almost all of their
functionality has been replaced by inline functions and static constant
class members and unnamed namespace file level constants.  There is
therefore little motivation for enhancing their capabilities within C++.
If C adopted any extensions they would probably be incorporated into C++ in
a subsequent level.

--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel Networks (MED)                               |  FAX:   (613) 763-5199
---
[ 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 <3650ac18.0@monster.ssau.ru>,
  "Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
> Consider example:
> #undef A
> #undef B
> #undef C
>
> Why don't extend the syntax to
> #undef A B C
>
> IMO such extension won't break any other semantical rules for preprocessor,
> but will reduce the size of the code that extensively uses macros. And (IMO
> more important) will reduce the number of lines in the source file - this
> helps editing and viewing the code
>  since more lines of code fits on one screen.

It doesn't break any existing code. It's easy to use, and it's
meaning is intuitive.

The only serious objection can be that it makes it easier to
use the preprocessor, while most of the language is trying to
move away from the preprocessor. But that's not a very good
reason. The proposal doesn't make any of the alternatives
harder, so it doesn't really encourage use of the preprocessor.
It's along the lines of, "if you have to do it anyway, this
should make it a little bit easier."

I like the idea.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

Vlad Harchev wrote:
>
> Consider example:
> #undef A
> #undef B
> #undef C
>
> Why don't extend the syntax to
> #undef A B C
>
> IMO such extension won't break any other semantical rules for
> preprocessor, but will reduce the size of the code that extensively
> uses macros. And (IMO more important) will reduce the number of lines
> in the source file - this helps editing and viewing the code
> since more lines of code fits on one screen.

Fine by me, although I think it'd look prettier with commas between
them.

I'm generally in favor of simple changes like this, as long as they
simplify code writing in some way, and don't break any existing legal
programs. I had hoped to convince the standard committee to throw in
binary numbers (e.g., 0y11011111), or to allow underscores in numbers to
improve readability of long numbers (e.g., 1_000_000_000), since those
changes would take only about a half a man-day of programming time in a
typical compiler, but I guess it didn't seem hip enough for anyone to
get excited about. This proposal may suffer the same fate. ;-)

--

Ciao,
Paul


[ 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              ]