In article <3836FF17.E90264D5@wizard.net>,
James Kuyper Jr. <kuyper@wizard.net> wrote:
>There's no reason you couldn't implement it at both levels. The way the
>language is designed, #warning would have to be a preprocessor
>directive, or nothing at all; it doesn't prevent the implementation of a
>similar feature evaluated at compile time. Specifying how the compile
>time version would work is much more of a problem.

How about something like this?
  __warning(constant_expr,literal_string);
    Produces an implementation-defined diagnostic if constant_expr is
    nonzero.

It keeps things simple, while providing enough power (via templates -
I was thinking of numeric_limits for use in the constant_expr, but I'm
sure Clever People could come up with more "interesting" things to put
there) to have the compiler produce useful information.
--
   Rob Macomber
    (rmacombe@u.arizona.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              ]

rado42 wrote:
> I've a proposal for extending the preprocessor:
> the directive #return
>
> It would cause leaving the current compilation unit at
> the point when it is used.
>
> It would make possible things like:
>
> E.g.
>   #ifndef _MT
>   #  return
>   #endif
>   ....
>
> instead of
>   #ifndef _MT
>   ....
>   #endif // somewhere at the end of the file - so
>          // difficlult to match the #ifdef
>
> The advantage could be more compact way to control the code.
> What do you think?

'#return' seems to imply a return value.

Why not:

    #break

or even simply:

    #end

Of course, I'm still waiting for:

    #warning pp-token...

-- David R. Tribble, david@tribble.com, http://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              ]

David R Tribble <david@tribble.com> wrote in message
news:383325BA.CC4DAFCD@tribble.com...
> Of course, I'm still waiting for:
>
>     #warning pp-token...

I don't think it's good you wish this. The problem is, preprocessor
finishes its stuff way before the compiler even takes a glance at the
code. The best usage of user-generated warnings and errors is in
template code. By implementing such a feature in the preprocessor, you
lose the chance of using it effectively.


Andrei




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

Andrei Alexandrescu wrote:
>
> David R Tribble <david@tribble.com> wrote in message
> news:383325BA.CC4DAFCD@tribble.com...
> > Of course, I'm still waiting for:
> >
> >     #warning pp-token...
>
> I don't think it's good you wish this. The problem is, preprocessor
> finishes its stuff way before the compiler even takes a glance at the
> code. The best usage of user-generated warnings and errors is in
> template code. By implementing such a feature in the preprocessor, you
> lose the chance of using it effectively.

There's no reason you couldn't implement it at both levels. The way the
language is designed, #warning would have to be a preprocessor
directive, or nothing at all; it doesn't prevent the implementation of a
similar feature evaluated at compile time. Specifying how the compile
time version would work is much more of a problem.


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

rado wrote:
>
> #ifndef _MT
> #  return
> #endif
>

Talk about early returns!  Now we're returning from a source file
instead of from a function.  I don't even know what that means.  8-)

--Bill Seymour


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

Hi all,
I've a proposal for extending the preprocessor:
the directive #return

It would cause leaving the current compilation unit at
the point when it is used.

It would make possible things like:

E.g.

#ifndef _MT
#  return
#endif
....

instead of
#ifndef _MT
....

#endif // somewhere at the end of the file - so
       // difficlult to match the #ifdef


The advantage could be more compact way to control the code.

What do you think?


--
rado
http://members.tripod.com/~radosoft


Sent via Deja.com http://www.deja.com/
Before you buy.


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