Re: Is C++ really portable?
"DeMarcus" <nobody@tellus. orb> wrote in message news:40899cab$0 $99624
[color=blue]
> Thank all of you for all your answers, I really
> appreciate it. But there's one very imporatant
> thing that I might have been a little vague about,
> and that is the importance of not having to
> recompile the application because of a library
> change. Therefore #ifdef won't do.[/color]
An ifdef in the cpp file will work. But then you're using the pointer to
implementation idea, so you pay the cost of a non-inline function call.
[color=blue]
> Suppose you sell your application to someone and
> this guy in turn buys a plugin to it from a third
> party vendor, where this plugin only supports
> "strangeThr ead" but not the apps default pthread.
> Then it would be neat to just send him a new
> strangeThread.s o or .dll to put in a specific
> directory and suddenly it works.
>
> It's feasible with the design patterns 'abstract
> factory' or 'bridge', but both of them result in
> an overhead with pointer referencing and memory
> allocation. I just wanted that C++ could do it
> anyway, but the only solution I can see right now
> is this solution[/color]
Have you actually measured it to determine it is a bottleneck? How many
MyThread objects do you create? How does the time spent in creating the
DerivedMyThread object and calling its virtual functions compare to the time
spent in the rest of the application? It might not be anything at all.
[color=blue]
> class MyThread
> {
> public:
> void start();
> ...
>
> private:
>
> char varStore[ BIG_ENOUGH_TO_H OLD_THE_BIGGEST _
> CLASS_DECLARATI ON_OF_ALL_POSSI BLE_IMPLEMENTAT IONS ];
> }[/color]
The above strikes me as a valid use of reinterpret_cas t in general, but only
a last resort if profiling suggests it. Pay attention to alignment issues
though. The char type usually has alignment 1, whereas pthread_t may have
alignment 4. To solve, there is no perfect way, but you can create a union
of all fundamental types along with your varStore[...] variable. The
union's size will be at least varStore[...] and will be properly aligned.
[color=blue]
> The header above could be used by anyone compiling
> the application or third party plugins.
>
> // Here's two different examples of implementation
> void MyThread::start ()
> {
> pthread_create( (pthread_t*)var Store, ... );
> }
>
> void MyThread::start ()
> {
> strange_thread_ create( (strange_thread _t*)varStore, ... );
> }[/color]
How does the cost of a factory compare to the cost of pthread_create?
To make using the factory even faster you can overload MyThread::opera tor
new and use pool allocation. But how many threads do you allocate anyway?
[color=blue]
> If I do this dirty implementation then I can compile
> the application once and hope and pray nobody makes
> a thread library with a bigger class declaration than
> BIG_ENOUGH_... that the application was compiled with.[/color]
You don't have to pray for this. You can use a compile time assert to
assert that sizeof(actual_t hread) <= sizeof(varStore ). These compile time
asserts work by creating an array of size zero if the condition is false,
and such a thing fails compilation.
[color=blue]
> My hope here was that the C++ compiler could take care
> of that somehow, but I realize it's almost impossible.[/color]
Not sure if any compiler can do what you're asking for.
"DeMarcus" <nobody@tellus. orb> wrote in message news:40899cab$0 $99624
[color=blue]
> Thank all of you for all your answers, I really
> appreciate it. But there's one very imporatant
> thing that I might have been a little vague about,
> and that is the importance of not having to
> recompile the application because of a library
> change. Therefore #ifdef won't do.[/color]
An ifdef in the cpp file will work. But then you're using the pointer to
implementation idea, so you pay the cost of a non-inline function call.
[color=blue]
> Suppose you sell your application to someone and
> this guy in turn buys a plugin to it from a third
> party vendor, where this plugin only supports
> "strangeThr ead" but not the apps default pthread.
> Then it would be neat to just send him a new
> strangeThread.s o or .dll to put in a specific
> directory and suddenly it works.
>
> It's feasible with the design patterns 'abstract
> factory' or 'bridge', but both of them result in
> an overhead with pointer referencing and memory
> allocation. I just wanted that C++ could do it
> anyway, but the only solution I can see right now
> is this solution[/color]
Have you actually measured it to determine it is a bottleneck? How many
MyThread objects do you create? How does the time spent in creating the
DerivedMyThread object and calling its virtual functions compare to the time
spent in the rest of the application? It might not be anything at all.
[color=blue]
> class MyThread
> {
> public:
> void start();
> ...
>
> private:
>
> char varStore[ BIG_ENOUGH_TO_H OLD_THE_BIGGEST _
> CLASS_DECLARATI ON_OF_ALL_POSSI BLE_IMPLEMENTAT IONS ];
> }[/color]
The above strikes me as a valid use of reinterpret_cas t in general, but only
a last resort if profiling suggests it. Pay attention to alignment issues
though. The char type usually has alignment 1, whereas pthread_t may have
alignment 4. To solve, there is no perfect way, but you can create a union
of all fundamental types along with your varStore[...] variable. The
union's size will be at least varStore[...] and will be properly aligned.
[color=blue]
> The header above could be used by anyone compiling
> the application or third party plugins.
>
> // Here's two different examples of implementation
> void MyThread::start ()
> {
> pthread_create( (pthread_t*)var Store, ... );
> }
>
> void MyThread::start ()
> {
> strange_thread_ create( (strange_thread _t*)varStore, ... );
> }[/color]
How does the cost of a factory compare to the cost of pthread_create?
To make using the factory even faster you can overload MyThread::opera tor
new and use pool allocation. But how many threads do you allocate anyway?
[color=blue]
> If I do this dirty implementation then I can compile
> the application once and hope and pray nobody makes
> a thread library with a bigger class declaration than
> BIG_ENOUGH_... that the application was compiled with.[/color]
You don't have to pray for this. You can use a compile time assert to
assert that sizeof(actual_t hread) <= sizeof(varStore ). These compile time
asserts work by creating an array of size zero if the condition is false,
and such a thing fails compilation.
[color=blue]
> My hope here was that the C++ compiler could take care
> of that somehow, but I realize it's almost impossible.[/color]
Not sure if any compiler can do what you're asking for.
Comment