Board index » cppbuilder » Is there a tricky way to assert, that a function about to be called is not the current function?

2007-03-13 06:14:35 PM
cppbuilder49
Is there a tricky way to assert, that a function about to be called is
not the current function?
This sounds a little strange, but I had a function which calls a
simply modified overloaded function with some minor differences
(instead of an enum in one parameter, it has an int).
Instead of calling the intended other function, it called itself
'eternally' (which finally caused an exception).
Just be rearranging the function headers this problem was 'solved'.
Probably I could (and perhaps will anyway) redesign the functions, but
I think it would be interesting to find out, if there is a way to do
this.
I see two difficulties:
(1) find out the address of the function which is intended to be
called
(2) find out the address of the function we are currently in
~~~~~~~~~
I implemented a mechanism, but unfortunately it is not thread-safe.
But this is a little different question, so I post in in a separate
posting.
Thanks,
Michael
 

<MR>writes:
stumble upon it. The signatures are so close that callers will be
confused, and accidents can (and as you demonstrated, will) happen.
When functions are overloaded, it's a good idea to not make the
differniation subtle, but overt and obvious. Severely different types
(like user-defined types) or different number of parameters, etc.
It certainly works to overload on types that are very similar or are
convertable to each other, but the user is not always aware of all the
options, and oftentimes thinks she is calling when when really calling
the other. One classic example is:
void f(std::string const & arg);
void f(bool arg);
int main()
{
f("hello world");
}
Guess which f is called? Even if you know the conversion rules and
know that f(bool) is called, think of other people on your team and
worry about what would happen if this code tricked them.
your application. Thus, the OS sent your process a "structured
exception" (similar to a unix signal), the VCL handler received the
notification and raised an Exception, which you saw.
Personally I think it was a mistake for the VCL to swallow structured
exceptions and translate them into normal exceptions. People "catch"
the exception and then think everything is handled and fine, when in
reality serious memory corruption could have happened.
It's like receiving a telegram that a loved one just died, but before
reading it, your neighbor runs across the yard, grabs the telegram and
burns it. You are left not knowing what happened, but at least you
feel better. It does not, however, bring them back to life.
(Sorry to rant, but when I see people say that a memory error caused
an "exception" I like to clairify the real situation. The VCL
intercepted the truth, and made it look much more cheery.)
result in the same function call regardless of order of #includes. If
such a re-arrangement actually changes behavior, either your code or the
compiler has somehting wrong with it. Look for whether you have
circluar inclusions between your headers. If you do, it is important
that you break the cycle, or else you will have different results
depending on order of includes.
you wish to call, then assign the function to it. Then you can invoke
the function through that pointer, which ensures you're calling the
"right one".
a method to do it, you'd have portability issues between vendors and
possibly even between different releases of Borland's compiler.
Sorry to get preachy, but sometimes I just like to clear the air. It
wasn't just you, but it seemed about time to say these things again.
:)
--
Chris (TeamB);
 

I think the solution to that problem lies in revisiting the design of the
program and not in efforts to provide {*word*118} means to circumvent the
problem.
In your case the function has overloads where the argument is an int or an
enum, two items for which the language specification clearly indicates one
can easily, automatically and quietly be converted to the other during
compilation.
Look up the keyword 'explicit' for one thing that you might try.
For a general way out, design your program to provide function overloads
that differ in a more specific manner. If you are backed into a corner
where a given argument in the overloads must have int and enum instances,
consider changing the calling parameter order or adding another parameter
and resolve to avoid painting yourself into such a corner in the future.
. Ed

{smallsort}

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >schrieb:
Just: sometimes things are possbile, you never thought they are at
first..
Thanks,
Michael
 

<MR>writes:
standard is single threaded, and so the langauge makes no mention of
threads and makes no requirements on code in MT environments.
However, the *next* C++ standard (hopefully released in 2009) will be
(or I should say, is expected to be) including a multi-threaded
virtual machine with language addressing some thread-safety issues,
and also including some Standard Library additions to encapsulate
thread-related objects. (Based on the Boost Thread library.)
--
Chris (TeamB);