Do you think this code will produce any undefined behavior?
Chris Thomasson
tinkering around with ways to wrap the function pointer logic. I am a
C/Assembly programmer that doesn't make a lot of use of C++. So my skills
can be improved upon for sure. I was wondering if I was subjecting my first
attempt at a function pointer to any undefined behavior(s). Here is the
code:
http://appcore.home.comcast.net/vzoom/raii/scope-guard.cpp
I'm basically using Andrei and Petru scopeguard technique, with one small
tweak: I am using a function pointer to the templated call details, instead
of a boolean. That way I can use it like a scopeguard by testing the value
of the function pointer against NULL, and I can call it like a virtual
function of sorts. So, I can call it virtually, or locally through the
templated SafeWxecute function... Does this sound Kosher to you C++ gurus'?
;^)
Thank you all for your time,
Chris Thomasson
Alf P. Steinbach
No. A scopeguard's job is to clean up. Executing the clean-up action
more than once is bound to lead to problems. If you want a "delegate",
a callable entity that wraps an object pointer plus member function
pointer, consider the standard library and Boost/TR1 classes for that.
The Boost classes are superior because they build on the experience with
the standard library, plus additional techniques developed after 1998.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Chris Thomasson
news:4s4g10F...@mid.individual.net...
>* Chris Thomasson:
>> I am working on a high-speed futures implementation in C++,
[...]
>> I was wondering if I was subjecting my first attempt at a function
>> pointer to any undefined behavior(s). Here is the code:
>>
>> http://appcore.home.comcast.net/vzoom/raii/scope-guard.cpp
>>
>> I'm basically using Andrei and Petru scopeguard technique, with one small
>> tweak:
[...]
>> So, I can call it virtually, or locally through the templated SafeWxecute
>> function... Does this sound Kosher to you C++ gurus'?
>>
>> ;^)
>
> No. A scopeguard's job is to clean up.
Okay... I think the name I used for the object didn't safely match its
functionality. Therefore, I will rename the entire object to something like:
'funcall_base' which will not call anything in the destructor; it won't use
its scope in any aspect of its functionality...
> Executing the clean-up action more than once is bound to lead to problems.
Then I can add a variant called 'funcall_scoped' which will indeed invoke
the call in its destructor, only if it was not previously "Dismissed". That
should define my indented usage a bit clearer than before...
> If you want a "delegate", a callable entity that wraps an object pointer
> plus member function pointer,
That's kind of what I am after, except I kind of want to stay away from
virtual destructors/functions in 'funcall_base' because it ultimately has to
be a POD that is compatible with my low-level C/Assembly library, which
contains the actual implementation details of my new futures algorithm. It
should have a single member which is a function pointer of a type that is
"standard" to my low-level library:
class funcall_base {
typedef void (*fpfuturesapi_t) (void const*);
fpfuturesapi_t m_fpcall_virtual;
};
So that the library can call it directly to get the actual templated
implementation details to invoke itself. Also, I think I can skip calls
into the function pointer contained in 'funcall_base':
class funcall_base {
public:
void execute_virtual() {
m_fpcall_virtual(this);
}
};
when the type of its templated call details are known by the caller in
advance:
class funcall_base {
public:
template<typename T_calldetail>
void execute_proxy() {
static_cast<T_calldetail*>(this)->execute_direct();
}
};
// assume mycall is base class of calldetails_t
funcall_base mycall;
// I think that this call:
mycall.execute_virtual();
// should have more overhead than this call:
mycall.execute_proxy<calldetails_t>();
// Am I way off base here?
:^)
I would appreciate it if you could clarify a bit...
> consider the standard library and Boost/TR1 classes for that. The Boost
> classes are superior because they build on the experience with the
> standard library, plus additional techniques developed after 1998.
Unfortunately, I can't make use of any part of Boost, or any other
third-party library, in the implementation details of my C++ futures
library.
;^(...
Thanks for your patience!
gottlo...@gmail.com
Chris Thomasson wrote:
> Unfortunately, I can't make use of any part of Boost, or any other
> third-party library, in the implementation details of my C++ futures
> library.
>
> ;^(...
>
>
Why not? You know that boost is open source but NOT GPL, right? It is
more like BSD license - use it in open source or commercial, whatever
you want.
Tony
VJ
Alf P. Steinbach
> gottlo...@gmail.com wrote:
>> Chris Thomasson wrote:
>>
>>> Unfortunately, I can't make use of any part of Boost, or any other
>>> third-party library, in the implementation details of my C++ futures
>>> library.
>>
>> more like BSD license - use it in open source or commercial, whatever
>> you want.
>>
> Boost is not suitable for some projects, because it is big library.
That is a misconception.
Boost is essentially a library of smaller independent libraries, most of
which are in turn collections of largely independent header files and
nothing more.
It follows the general C++ philosophy of not paying (in size etc.) for
what you don't use.
VJ
> * VJ:
>
>> gottlo...@gmail.com wrote:
>>
>>>
>>> Why not? You know that boost is open source but NOT GPL, right? It is
>>> more like BSD license - use it in open source or commercial, whatever
>>> you want.
>>>
>> Boost is not suitable for some projects, because it is big library.
>
>
> That is a misconception.
>
> Boost is essentially a library of smaller independent libraries, most of
> which are in turn collections of largely independent header files and
> nothing more.
Thats correct, but there are other libraries, which are smaller in size,
but do not have full boost functionality.
>
> It follows the general C++ philosophy of not paying (in size etc.) for
> what you don't use.
>
So, when you compile it how big it is?
This is not true if you are dynamicaly linking boost library
Alf P. Steinbach
There's no single boost library. If you use a part such as
boost::shared_ptr there isn't anything to link in: it's all in the
header files. It's not meaningful to ask for the compiled size of the
full library: first of all that size can't be accurately defined since
much of the code is in header files, and secondly because the parts that
are compiled may not necessarily be used by you and incur no size overhead.
> This is not true if you are dynamicaly linking boost library
?
VJ
> * VJ:
>
>> Alf P. Steinbach wrote:
>>
>>> * VJ:
>>>
>>>> gottlo...@gmail.com wrote:
>>>>
>>>>>
>>>>> Why not? You know that boost is open source but NOT GPL, right?
>>>>> It is
>>>>> more like BSD license - use it in open source or commercial, whatever
>>>>> you want.
>>>>>
>>>> Boost is not suitable for some projects, because it is big library.
>>>
>>>
>>>
>>> That is a misconception.
>>>
>>> Boost is essentially a library of smaller independent libraries, most
>>> of which are in turn collections of largely independent header files
>>> and nothing more.
>>
>>
>> Thats correct, but there are other libraries, which are smaller in
>> size, but do not have full boost functionality.
>>
>>>
>>> It follows the general C++ philosophy of not paying (in size etc.)
>>> for what you don't use.
>>>
>>
>> So, when you compile it how big it is?
>
>
> There's no single boost library. If you use a part such as
> boost::shared_ptr there isn't anything to link in: it's all in the
> header files. It's not meaningful to ask for the compiled size of the
I know the original concept was to have everything in header files. But
they abandoned it
> full library: first of all that size can't be accurately defined since
> much of the code is in header files, and secondly because the parts that
> are compiled may not necessarily be used by you and incur no size overhead.
>
Therefore the conclusion is: it depends what you use.
Does it means that the boost library will not boost much the size of
your program?
For our project, that was the reason not to use this library
Chris Thomasson
news:1163741978.2...@e3g2000cwe.googlegroups.com...
> Chris Thomasson wrote:
>
>> Unfortunately, I can't make use of any part of Boost, or any other
>> third-party library, in the implementation details of my C++ futures
>> library.
[...]
> Why not?
[...]
I am creating the C++ API in order to wrap a low-level C API that abstracts
an external futures library written in Assembly Language. Therefore, the
"function-call base object" needs to be a POD which I am currently declaring
like this:
-----------
// declare
struct funcall_base_pod {
typedef void (*fpfuturesapi_t) (void const*);
fpfuturesapi_t m_fpcall_virtual;
void execute_virtual();
template<typename T_calldetail> void execute_proxy();
};
and defining like this:
-----------
// define
void funcall_base_pod::execute_virtual() {
m_fpcall_virtual(this);
}
template<typename T_calldetail>
void funcall_base_pod::execute_proxy() {
/* T_calldetail MUST directly derive from this 'funcall_base_pod'
* T_calldetail interface MUST have execute_direct()
*/
static_cast<T_calldetail*>(this)->execute_direct();
}
and asserting its size it equal to that of a pointer to void like this:
-----------
// assertion
namespace {
namespace assertion {
template<bool T> struct assert_static;
template<> struct assert_static<true> {
};
assert_static<(sizeof(funcall_base_pod) == sizeof(void*))>
assert_funcall_base_pod_sizeof_voidptr;
}} // namespace anonymous::assertion
I don't think Boost will work to well with the requirements of my low-level
Assembly Language library... Anyway, I really wondering if the member
functions of 'funcall_base_pod' will subject the caller to any undefined
behavior(s)...
Alf P. Steinbach
>
> Does it means that the boost library will not boost much the size of
> your program?
>
> For our project, that was the reason not to use this library
If you mean, Boost was not used because it would not inflate much the
sizes of the programs, well, that may make sense from a marketing point
of view when a main selling point is huge size.
If you mean, Boost was not used because it would not reduce much the
sizes of the programs, then that doesn't make much sense. The point of
Boost is not to reduce the sizes of programs, although it can do that.
The point is to provide solid, dependable, standardized tools for
solving common programming problems, like smart pointers.
If you mean, Boost was not used because it would not reduce much the
size of the program text, then I strongly suspect that incorrect and/or
unmaintainable very short program text was compared to incorrect /and/or
incompetently written somewhat longer text using Boost. Anyway, what
do you then do with the next version of the compiler? Refuse to use the
standard library because it then incorporates parts of Boost?