#return

#return

Post by rado4 » Tue, 16 Nov 1999 04:00:00



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 ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

#return

Post by Bill Seymou » Tue, 16 Nov 1999 04:00:00



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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

#return

Post by David R Tribbl » Sat, 20 Nov 1999 04:00:00



> 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...


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

#return

Post by Andrei Alexandresc » Sun, 21 Nov 1999 04:00:00




Quote:> 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 ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

#return

Post by James Kuyper Jr » Mon, 22 Nov 1999 04:00:00





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

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

#return

Post by Robert J Macomb » Mon, 22 Nov 1999 04:00:00




Quote:>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

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]

[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 
 
 

1. PostThreadMessage Returns Error (0) but GetLastMessage returns 0

Anyone,

I have an application that works fine under the debugger
("debug" configuration) but fails when run stand-alone
("release" configuration.)

In the case of the "release" configuration,
PostThreadMessage returns 0 indicating an error, but the
subsequent call to GetLastError() also returns 0.  The
thread doesn't get the message.)

In the debug version, the call to PostThreadMessage works
(a non-zero value is returned) and the thread gets the
message.

Anyone heard of anything similar or have anything I could
try?  I have been pulling my hair out over this.

Thanks,
Phil

2. Unable to uninstall NIS

3. VB EXEs returning a return code

4. Mindmaking (Was: Programming) with Sets

5. SystemParametersInfo returns 0 but GetLastError() returns 0 as well

6. Compiled Driver Listing

7. Relation between Rect return by GetClipBox() and Rgn return by GetClipRgn() ?

8. IIS 5 Newsgroup

9. Thread constantly returning -1! accept never returns!

10. function to return count doesn't return correct count

11. Return a return? And a constructor

12. return type for returning vector or string

13. return by value vs. return by reference