gcarlton@iinet.net.au (Geoff Carlton) writes:

> This is an idea I posted on the artima C++ wishlist thread.  Seeing all
> the interesting dissection of C++ suggestions I thought I'd reprint it
> here and see what people think.
>
> Sometimes we have debug logging functions that need to be obliterated in
> final, but even empty inline functions incur the overhead of argument
> evaluation.
>
>   Log::Print("Length = %f \n", myvector.Length());
>
> There's no way to avoid the myvector.Length() call in release. This is
> one time that I've seen justifiable use of macros in C++ code, simply
> because there is no other way of doing it.
>
> What's needed is an "optional_args" keyword to tell the compiler it can
> delay or avoid evaluating inline function arguments.

Heck, why not go for full lazy evaluation, like in Haskell?

--
Dave Abrahams
Boost Consulting
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                       ]

David Abrahams wrote:
>
> Heck, why not go for full lazy evaluation, like in Haskell?
>

Well, a change like that would break alot of code out there, since C++
doesn't have any way of differentiating functions that truely have no
side effects - const is not enough of a specification.

That seems to suggest a bottom-up approach of labelling such functions,
but I don't think the optimization advantages would be particularly
great in the general case.

On the other hand, a few top level functions such as assert and logging
really do need to be totally obliterated in some builds.  It would be
nice if C++ allowed this behaviour without resorting to macro workarounds.

Geoff

---
[ 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 the other hand, a few top level functions such as assert and logging
> really do need to be totally obliterated in some builds.  It would be
> nice if C++ allowed this behaviour without resorting to
> macro workarounds.

Maybe what you need is an aspect weaver for C++.

Check this site out:
http://allserv.ugent.be/~kdschutt/aspicere/

Also:
http://gcc.gnu.org/ml/gcc/2005-05/msg00348.html

--
 Pedro Lamar   o


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

This is an idea I posted on the artima C++ wishlist thread.  Seeing all
the interesting dissection of C++ suggestions I thought I'd reprint it
here and see what people think.

Sometimes we have debug logging functions that need to be obliterated in
final, but even empty inline functions incur the overhead of argument
evaluation.

   Log::Print("Length = %f \n", myvector.Length());

There's no way to avoid the myvector.Length() call in release. This is
one time that I've seen justifiable use of macros in C++ code, simply
because there is no other way of doing it.

What's needed is an "optional_args" keyword to tell the compiler it can
delay or avoid evaluating inline function arguments.

template <typename T>
optional_args void Print(int priority, const char* message, T value)
{
   if (priority >= global_priority)
   {
     DoPrint(message, value);
   }
}

If both priority ints are const, the compiler could just nuke the whole
lot, otherwise at least only evaluate the inline arguments until the
DoPrint.

Note I've avoided var-args here since compilers can't easily inline
this, which is necessary for the optimisation to occur.

Geoff

PS: Coupled with runtime reflection, this could also lead to that final
bastion of macros, the assert function.

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