hiya. i have a lil question... in C++ i have some macros to "guard" functions
for exceptions... if ye are familiar to Unreal source code, ya already know what
i mean. to those who arent heres a short explanation:
i have a function more or less like this:

void foo()
{
guard(foo)
{
// some potentially harmful stuff
} unguard
}

the guard macro creates a string with the function name and enters a try{ block. the unguard macro catches possible exceptions and if one was caught, it rethrows it, but telling that it was thrown from the "foo" function... so when i have an exception somewhere im my proggie, i can always know where it was risen...

Is this possible in D in a similar syntax ? can that be done with no preprocessor in D ? it can really save lots of pain sometimes...

Heretic wrote:
> hiya. i have a lil question... in C++ i have some macros to "guard" functions
> for exceptions... if ye are familiar to Unreal source code, ya already know what
> i mean. to those who arent heres a short explanation:
> i have a function more or less like this:
> 
> void foo()
> {
> guard(foo)
> {  // some potentially harmful stuff
> } unguard
> }
> 
> the guard macro creates a string with the function name and enters a try{ block.
> the unguard macro catches possible exceptions and if one was caught, it rethrows
> it, but telling that it was thrown from the "foo" function... so when i have an
> exception somewhere im my proggie, i can always know where it was risen...
> 
> Is this possible in D in a similar syntax ? can that be done with no
> preprocessor in D ? it can really save lots of pain sometimes...

This is the kind of thing where a preprocessor can come in very handy. No conventional language construct will allow you to extend the language in a way exactly like this, because you want to have the beginning of a code block (try) sandwiched in one construct (guard) and the end in another (unguard).

The only thing I can think of that lets you do something similar is the following:

Have a global stack (thread-local if your app is multi-threaded) with the names of the functions that are currently executing. Derive all exceptions from the same base class. In the constructor of the base exception class, copy the contents of that function stack.

Now all you have to do is update the stack each time a function is entered/left, so that it reflects the current call chain. You can do this with auto objects in D:

auto class FuncCall
{
	this(char[] name)
	{
		g_FuncCallStack.push(name);
	}
	~this()
	{
		g_FuncCallStrack.pop();
	}
}

Then, all you have to do is instantiate one of these objects in each function.

void foo()
{
	FuncCall c=new FuncCall("foo");

	...
}

Note that the FuncCall class is an "auto" class, so its objects are automatically destroyed when the reference "c" goes out of scope (i.e. when the function exits). This is necessary, because otherwise the function name will remain on the stack until the FuncCall object is garbage collected, which can be loooong after the function was exited.

Matthew has proposed a better syntax for auto objects that would make this even easier:

void foo()
{
	FuncCall c("foo");

	...
}

This is not (yet?) possible, though. So you'll have to use the first version for the time being.

Hope this helps...

Hauke

k, 10x for a thorough answer ;)

the latter syntax seems quite good to me :)
however there`s one problem remaining... and i dunno whether it can be solved
while maintaining simple syntax. i have actually also macro guard_critical...
and this one in the release build in c++ turns into nothing... so in debug i can
test the app and in release i get full speed in time critical code. in cpp this
is again done by a macro checking for "NDEBUG"...

any clue this time ? :(

Why not just use an auto class template?

"Heretic" <Heretic_member@pathlink.com> wrote in message news:bt2bh4$6dj$1@digitaldaemon.com...
> hiya. i have a lil question... in C++ i have some macros to "guard"
functions
> for exceptions... if ye are familiar to Unreal source code, ya already
know what
> i mean. to those who arent heres a short explanation:
> i have a function more or less like this:
>
> void foo()
> {
> guard(foo)
> {
> // some potentially harmful stuff
> } unguard
> }
>
> the guard macro creates a string with the function name and enters a
try{ block.
> the unguard macro catches possible exceptions and if one was caught, it
rethrows
> it, but telling that it was thrown from the "foo" function... so when i
have an
> exception somewhere im my proggie, i can always know where it was risen...
>
> Is this possible in D in a similar syntax ? can that be done with no preprocessor in D ? it can really save lots of pain sometimes...
>
>

Hmm.. I appear to be suffering from premature opinionation. Please ignore in favour of Hauke's much better response. :)

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt2n8q$oee$1@digitaldaemon.com...
> Why not just use an auto class template?
>
> "Heretic" <Heretic_member@pathlink.com> wrote in message news:bt2bh4$6dj$1@digitaldaemon.com...
> > hiya. i have a lil question... in C++ i have some macros to "guard"
> functions
> > for exceptions... if ye are familiar to Unreal source code, ya already
> know what
> > i mean. to those who arent heres a short explanation:
> > i have a function more or less like this:
> >
> > void foo()
> > {
> > guard(foo)
> > {
> > // some potentially harmful stuff
> > } unguard
> > }
> >
> > the guard macro creates a string with the function name and enters a
> try{ block.
> > the unguard macro catches possible exceptions and if one was caught, it
> rethrows
> > it, but telling that it was thrown from the "foo" function... so when i
> have an
> > exception somewhere im my proggie, i can always know where it was
risen...
> >
> > Is this possible in D in a similar syntax ? can that be done with no preprocessor in D ? it can really save lots of pain sometimes...
> >
> >
>
>

You can make an auto class that is version aware and, if you can make it do nothing in release, the compiler will elide it for you. :)

"Heretic" <Heretic_member@pathlink.com> wrote in message news:bt2jnm$ja3$1@digitaldaemon.com...
> k, 10x for a thorough answer ;)
>
> the latter syntax seems quite good to me :)
> however there`s one problem remaining... and i dunno whether it can be
solved
> while maintaining simple syntax. i have actually also macro
guard_critical...
> and this one in the release build in c++ turns into nothing... so in debug
i can
> test the app and in release i get full speed in time critical code. in cpp
this
> is again done by a macro checking for "NDEBUG"...
>
> any clue this time ? :(
>
>

In article <bt2ndr$oin$1@digitaldaemon.com>, Matthew says...
>
>You can make an auto class that is version aware and, if you can make it do nothing in release, the compiler will elide it for you. :)

Yeah, i can only HOPE the compiler will elide it :( cuz even if it ALLOCS an object that *does nothing* and then gets deleted, if this is done 1,000,000 times a second (im into game programming), it wont be too good :( ill have to try and implement this with dmd and if it doesnt work, i`ll pray for the GCC frontend ;)

"Heretic" <Heretic_member@pathlink.com> wrote in message news:bt4644$2vf7$1@digitaldaemon.com...
> In article <bt2ndr$oin$1@digitaldaemon.com>, Matthew says...
> >
> >You can make an auto class that is version aware and, if you can make it
do
> >nothing in release, the compiler will elide it for you. :)
>
> Yeah, i can only HOPE the compiler will elide it :( cuz even if it ALLOCS
an
> object that *does nothing* and then gets deleted, if this is done
1,000,000
> times a second (im into game programming), it wont be too good :( ill have
to
> try and implement this with dmd and if it doesnt work, i`ll pray for the
GCC
> frontend ;)

IIRC, we were talking about auto objects, which exist on the stack, so elision will be simple. I'd be surprised, though not shocked, if the compiler could elide from existence empty heap objects at this point in the development

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt4mes$lgt$2@digitaldaemon.com...
>
> "Heretic" <Heretic_member@pathlink.com> wrote in message news:bt4644$2vf7$1@digitaldaemon.com...
> > In article <bt2ndr$oin$1@digitaldaemon.com>, Matthew says...
> > >
> > >You can make an auto class that is version aware and, if you can make
it
> do
> > >nothing in release, the compiler will elide it for you. :)
> >
> > Yeah, i can only HOPE the compiler will elide it :( cuz even if it
ALLOCS
> an
> > object that *does nothing* and then gets deleted, if this is done
> 1,000,000
> > times a second (im into game programming), it wont be too good :( ill
have
> to
> > try and implement this with dmd and if it doesnt work, i`ll pray for the
> GCC
> > frontend ;)
>
> IIRC, we were talking about auto objects, which exist on the stack, so elision will be simple. I'd be surprised, though not shocked, if the compiler could elide from existence empty heap objects at this point in
the
> development

What matters most right now is if the language semantics allow the removal of it. Better optimizing compilers will come in time, just like they have for C++.

Agreed

"Walter" <walter@digitalmars.com> wrote in message news:bt4pk4$q0o$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:bt4mes$lgt$2@digitaldaemon.com...
> >
> > "Heretic" <Heretic_member@pathlink.com> wrote in message news:bt4644$2vf7$1@digitaldaemon.com...
> > > In article <bt2ndr$oin$1@digitaldaemon.com>, Matthew says...
> > > >
> > > >You can make an auto class that is version aware and, if you can make
> it
> > do
> > > >nothing in release, the compiler will elide it for you. :)
> > >
> > > Yeah, i can only HOPE the compiler will elide it :( cuz even if it
> ALLOCS
> > an
> > > object that *does nothing* and then gets deleted, if this is done
> > 1,000,000
> > > times a second (im into game programming), it wont be too good :( ill
> have
> > to
> > > try and implement this with dmd and if it doesnt work, i`ll pray for
the
> > GCC
> > > frontend ;)
> >
> > IIRC, we were talking about auto objects, which exist on the stack, so elision will be simple. I'd be surprised, though not shocked, if the compiler could elide from existence empty heap objects at this point in
> the
> > development
>
> What matters most right now is if the language semantics allow the removal of it. Better optimizing compilers will come in time, just like they have for C++.
>
>