Is C++ really portable?

[DeMarcus]

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
....
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Thanks
Daniel Marcus

[Rolf Magnus]

DeMarcus wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

That depends on how efficient you need it to be. Each std::string will
also need to allocate its memory, and many programs also use "_a_lot_"
of strings.
Anyway, I don't see why you would need a factory here. A factory is used
to decide which class to instantiate at runtime. But an instance of
your program is unlikely to migrate from a unix system to a windows
system while running, isn't it? So why don't you just use #ifdef to
select the parts of the code based on the system your program is
compiled for?

[DeMarcus]

Rolf Magnus wrote:

DeMarcus wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

That depends on how efficient you need it to be. Each std::string will
also need to allocate its memory, and many programs also use "_a_lot_"
of strings.
Anyway, I don't see why you would need a factory here. A factory is used
to decide which class to instantiate at runtime. But an instance of
your program is unlikely to migrate from a unix system to a windows
system while running, isn't it? So why don't you just use #ifdef to
select the parts of the code based on the system your program is
compiled for?

I tried to keep away from non-C++ things, but to make it a little more
clear I'm in a position where a very same application can use two
different types of thread libraries (pthread and sproc) which are not
compatible. This means I would really like to be able to wrap and
extract that library so I can load it dynamically without the need to
recompile the application.

I'm stuck to pointers, ain't I?

[Jakob Bieling]

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

I tried to keep away from non-C++ things, but to make it a little more
clear I'm in a position where a very same application can use two
different types of thread libraries (pthread and sproc) which are not
compatible. This means I would really like to be able to wrap and
extract that library so I can load it dynamically without the need to
recompile the application.

I do not really understand why you want to be able to use two different
libraries, unless you are talking about two different libs for two different
OS's. In the latter case, you do not need any pointers, as Rolf Magnus
already pointed out. Maybe it helps to create a common interface that
forwards the calls to the right library. #defines will control to which
library the functions will forward the calls. This way you hide all the
#define acrobatics from the actual user code -- not neccessary, but maybe it
looks nicer :)

hth
--
jb

(replace y with x if you want to reply by e-mail)

[DeMarcus]

Jakob Bieling wrote:

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

I tried to keep away from non-C++ things, but to make it a little more
clear I'm in a position where a very same application can use two
different types of thread libraries (pthread and sproc) which are not
compatible. This means I would really like to be able to wrap and
extract that library so I can load it dynamically without the need to
recompile the application.

I do not really understand why you want to be able to use two different
libraries, unless you are talking about two different libs for two different
OS's. In the latter case, you do not need any pointers, as Rolf Magnus
already pointed out. Maybe it helps to create a common interface that
forwards the calls to the right library. #defines will control to which
library the functions will forward the calls. This way you hide all the
#define acrobatics from the actual user code -- not neccessary, but maybe it
looks nicer :)

To make a even more concrete example I want to make a class like this

class MyThread
{
public:
void start();
...

private:

pthread_t threadID;

};

Then I want to use that class in the application, but now suddenly the
application has to know what pthread_t is, and even worse, now I can
definately not link in any implementation of MyThread using anything
else than pthread_t.

I could always do something like this

class MyThread
{
public:
void start();
...

private:

char variableStore[ 4711 ];
}

and then in the implementation do (pthread_t*)variableStore = whatever;
or (sproc_t*)variableStore = whatever;
But that's DIRTY DIRTY DIRTY!

[Andre Kostur]

DeMarcus <no****@tellus.orb> wrote in
news:40***********************@news3.bahnhof.se:

Jakob Bieling wrote:

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

I tried to keep away from non-C++ things, but to make it a little
more clear I'm in a position where a very same application can use
two different types of thread libraries (pthread and sproc) which are
not compatible. This means I would really like to be able to wrap and
extract that library so I can load it dynamically without the need to
recompile the application.

I do not really understand why you want to be able to use two
different
libraries, unless you are talking about two different libs for two
different OS's. In the latter case, you do not need any pointers, as
Rolf Magnus already pointed out. Maybe it helps to create a common
interface that forwards the calls to the right library. #defines will
control to which library the functions will forward the calls. This
way you hide all the #define acrobatics from the actual user code --
not neccessary, but maybe it looks nicer :)

To make a even more concrete example I want to make a class like this

class MyThread
{
public:
void start();
...

private:

pthread_t threadID;

};

Then I want to use that class in the application, but now suddenly the
application has to know what pthread_t is, and even worse, now I can
definately not link in any implementation of MyThread using anything
else than pthread_t.

I could always do something like this

class MyThread
{
public:
void start();
...

private:

char variableStore[ 4711 ];
}

and then in the implementation do (pthread_t*)variableStore =
whatever; or (sproc_t*)variableStore = whatever;
But that's DIRTY DIRTY DIRTY!

Or use some other 3rd party libraries (such as ACE, perhaps
Boost::Thread) which will abstract out the threading details.

[Jakob Bieling]

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

To make a even more concrete example I want to make a class like this

class MyThread
{
public:
void start();
...

private:

pthread_t threadID;

};

Then I want to use that class in the application, but now suddenly the
application has to know what pthread_t is, and even worse, now I can
definately not link in any implementation of MyThread using anything
else than pthread_t.

Ah, a bit more tricky. But still, you will probably be able to use
#defines:

#ifdef _WINDOWS
#define pthread_t HANDLE
#else
#define pthread_t int // or whatever
#endif

Then the implementation will also use #defines to commensate the
difference between the two libraries.

hth
--
jb

(replace y with x if you want to reply by e-mail)

[E. Robert Tisdale]

DeMarcus wrote:

Do I have to live with this? Or do I have to make some kind of

class SystemThing {
...
private: #ifdef unix strange_unix_var uv; #else // must be windows strange_win_var wv; #endif // unix };

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

[SenderX]

> * It will be used _a_lot_, and therefore need to be really efficient.

* It can have two different implementations. (e.g. Unix/Windows)

Here is some crude pseudo-code for portable a semaphore:

/* win_sema.h
-----------------*/

namespace win32
{

class CSema
{

public:

// Sema common interface

private:

HANDLE m_Sema;

};

}

namespace os
{
typedef win32::CSema CSema;
}

/* linux_sema.h
-----------------*/

namespace linux32
{

class CSema
{

public:

// Sema common interface

private:

sem_t m_hSema;

};

}

namespace os
{
typedef linux32::CSema CSema;
}

/* portable_sema.h
----------------------*/

#ifdef USE_WIN32

#include "win_sema.h"

#else

#include "linux_sema.h"

#endif

/* main.c
-------------------------*/

#define USE_WIN32

#include "portable_sema.h"

int main()
{
os::CSema PortableSema;

return 0;
}


Can you see what I did here?

[SenderX]

> Can you see what I did here?

If you still confused I can post code that will compile. Its OT because it
actually has the os specific calls needed to create and implement the
semaphore.

[Stephen Waits]

DeMarcus wrote:

class MyThread
{
public:
void start();
...

private:

pthread_t threadID;

};

We do this in a way that many might think ugly, but it's quite
straightforward, easy to maintain, and does the job just fine.
#if defined(PLATFORM_PSP)
# include "psp/thread_impl_psp.h"
#elif defined(PLATFORM_PS2)
# include "ps2/thread_impl_ps2.h"
#else
# include "undef/thread_impl_undef.h"
#endif

class MyThread
{
public:
...
private:
MyThreadImpl impl;
};
I'm sure you get the idea. It's not very C++-ish as you seem to desire.

FWIW we have a cross platform SDK setup entirely like this building on a
variety of platforms, and even more compilers.

--Steve

[Jeff Schwab]

DeMarcus wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Write a header file to define the interface your library should have.
For each platform, implement the interface in a separate file. Choose
the implementation at link time. For example, if you control your
builds with makefiles and compile with g++, put conditional logic in the
makefiles (or in shell scripts) to define platform-specific arguments to
the compiler's -I, -L, and -R arguments. Wherever there is commonality
between the platform-specific implementations, abstract it into a
separate module. This approach avoids the unfortunate situation in
which you have different implementations in a single file, and have to
pick out the commonality using the preprocessor.

[Jeff Schwab]

Jeff Schwab wrote:

DeMarcus wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Write a header file to define the interface your library should have.
For each platform, implement the interface in a separate file. Choose
the implementation at link time.

Excuse me, that should say "build time," since details of compilation
may be platform-specific.
For example, if you control your
builds with makefiles and compile with g++, put conditional logic in the
makefiles (or in shell scripts) to define platform-specific arguments to
the compiler's -I, -L, and -R arguments. Wherever there is commonality
between the platform-specific implementations, abstract it into a
separate module. This approach avoids the unfortunate situation in
which you have different implementations in a single file, and have to
pick out the commonality using the preprocessor.

[DeMarcus]

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.

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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so 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

class MyThread
{
public:
void start();
...

private:

char varStore[ BIG_ENOUGH_TO_HOLD_THE_BIGGEST_
CLASS_DECLARATION_OF_ALL_POSSIBLE_IMPLEMENTATIONS ];
}

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*)varStore, ... );
}

void MyThread::start()
{
strange_thread_create( (strange_thread_t*)varStore, ... );
}

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.

My hope here was that the C++ compiler could take care
of that somehow, but I realize it's almost impossible.

[Cy Edmunds]

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Thanks
Daniel Marcus

I write a lot of scientific/engineering kind of code which must run on
Windows and Unix. When I have to do something specific to an operating
system (e.g. load a dll/so by name) I try to localize the operating system
dependence to a single file. Polymorphism seems to be very useful here.

The other thing I do is to use Python for "glue" code. It ports across
operating systems pretty much seamlessly. It is too slow for number
crunching but that part of te code can be done in C or C++. This may not be
the NG to plug Python, but it is a joy to use for anything that isn't
time-critical.

--
Cy
http://home.rochester.rr.com/cyhome/

[Siemel Naran]

"DeMarcus" <no****@tellus.orb> wrote in message news:40899cab$0$99624

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.
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.
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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so 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
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.
class MyThread
{
public:
void start();
...

private:

char varStore[ BIG_ENOUGH_TO_HOLD_THE_BIGGEST_
CLASS_DECLARATION_OF_ALL_POSSIBLE_IMPLEMENTATIONS ];
}
The above strikes me as a valid use of reinterpret_cast 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.
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*)varStore, ... );
}

void MyThread::start()
{
strange_thread_create( (strange_thread_t*)varStore, ... );
}
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::operator
new and use pool allocation. But how many threads do you allocate anyway?
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.
You don't have to pray for this. You can use a compile time assert to
assert that sizeof(actual_thread) <= 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.
My hope here was that the C++ compiler could take care
of that somehow, but I realize it's almost impossible.

Not sure if any compiler can do what you're asking for.

[Gianni Mariani]

DeMarcus wrote:

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.

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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so 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

class MyThread
{
public:
void start();
...

private:

char varStore[ BIG_ENOUGH_TO_HOLD_THE_BIGGEST_
CLASS_DECLARATION_OF_ALL_POSSIBLE_IMPLEMENTATIONS ];
}

don't use 'char' - use somthing with the largest alignment
of any of the implemntations you require.

Also, on some systems, a virtual function call is just as fast
as a regular call.

Finally, one possibility is to go ahead and use a factory
but make it so the factory puts the function addresses
directly in the structure.

Somthing like:

class MyThread
{
friend class ThreadImpl;

void ( * StartFuncPtr )( MyThread * );
void ( * CleanupFuncPtr )( MyThread * );

long long var_store[ NUM_BIG_ENUFF ];

public:

inline Start()
{
StartFuncPtr( this );
}

virtual ~MyThread()
{
CleanupFuncPtr( this );
}

MyThread()
{
// factory initialize
ThreadFactoryInitializeNew( this );
}

// application overrides this function
virtual DoStuff() = 0;
};

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*)varStore, ... );
}

void MyThread::start()
{
strange_thread_create( (strange_thread_t*)varStore, ... );
}

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.

My hope here was that the C++ compiler could take care
of that somehow, but I realize it's almost impossible.

It's very possible. You can also make it very safe by making the ugly
nasty stuff private so that nothing else messes with the bits that they
should not.

[Krzysztof Zelechowski]

Uzytkownik "DeMarcus" <no****@tellus.orb> napisal w wiadomosci
news:40***********************@news3.bahnhof.se...

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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so or .dll to put in a specific
directory and suddenly it works.

I think the plugin must be appropriate for your application and not the
opposite.

[DeMarcus]

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

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.

Maybe you're right here, I may not lose much. I know that one shall
never begin with optimizing, but in this case where it is the structure
of the program it feels like if I do this wrong there will be no space
for optimizations later.

I was just worried about all the mutexes that will go from
myMutex.lock();
to
myMutex->lock();
(virtual)

I hope it won't be a too big performance hit.

To make using the factory even faster you can overload MyThread::operator
new and use pool allocation. But how many threads do you allocate anyway?

I really like that pool allocation idea! That's an area where I want to
improve my programming skills. Do you know where to find exhaustive
information about creating rock solid buffer pools?

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.

You don't have to pray for this. You can use a compile time assert to
assert that sizeof(actual_thread) <= 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.

That's something I didn't know about. Do you know where I can read
more about it?

[DeMarcus]

Krzysztof Zelechowski wrote:

Uzytkownik "DeMarcus" <no****@tellus.orb> napisal w wiadomosci
news:40***********************@news3.bahnhof.se...

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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so or .dll to put in a specific
directory and suddenly it works.

I think the plugin must be appropriate for your application and not the
opposite.

When you're Big Buck Inc. yes. But I'm not. ;) Therefore I will be the
only one losing if the application doesn't work as the customer
expected. If he goes to Big Buck Third Party Plugin Manufacturer Inc.
and ask them to change their plugins they will say they wait until my
app is working properly.

But you're right. This is actually a catch22 situation that probably
will never happen. The thing is that I personaly want to use pthreads
meanwhile many companies in the business use an older variant of
threads, so I need a simple way to deal with both.

[Jakob Bieling]

"DeMarcus" <no****@tellus.orb> wrote in message
news:40***********************@news3.bahnhof.se...

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.
But will you not have to recompile anyway, since you cannot use the
Linux executable on a Windows system anyway?
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
"strangeThread" but not the apps default pthread.
Then it would be neat to just send him a new
strangeThread.so or .dll to put in a specific
directory and suddenly it works.
Well, think about it. That plugin is written after you ceated your app,
so who would ever create a plugin that does not work with the app? Sure, you
do restrict plugin writers to use a specific lib, but that is life ;)
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

As I mentioned in another post, you just create an interface and let the
libraries contain a derived class from that interface and let it do all the
implementation specific stuff. Then you have the dynamic lib export two
functions: create_thread and destroy_thread. In the former you allocate the
derived class with new and return the pointer, in the latter you destroy it
again. The overhead of allocating from the heap will surely be neglectable,
because it is rather unlikely that you will create hundrets of threads ..

hth
--
jb

(replace y with x if you want to reply by e-mail)

[Siemel Naran]

"Gianni Mariani" <gi*******@mariani.ws> wrote in message

Also, on some systems, a virtual function call is just as fast
as a regular call.

How can this be? You have to look up the address of a function in the
virtual table and then call it, so logic suggests it has to be slower. But
maybe I'm overlooking something?

[Siemel Naran]

"DeMarcus" <no****@tellus.orb> wrote in message news:408a2724$0$99624

I really like that pool allocation idea! That's an area where I want to
improve my programming skills. Do you know where to find exhaustive
information about creating rock solid buffer pools?

You don't have to pray for this. You can use a compile time assert to
assert that sizeof(actual_thread) <= 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.

That's something I didn't know about. Do you know where I can read
more about it?

Try google, google newsgroups, browse the boost libraries, etc. Sorry, have
to catch a flight now.

[Daniel T.]

DeMarcus <no****@tellus.orb> wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Part of my job has been to ensure that the code written by the rest of
the people on the team is portable between Windows and MacOS X. Here is
how I solve the problem:

class GenericThingThatsImplementedDifferently {
class Impl;
Impl* pimpl;
public:
void genericFunction();
};

Then I will write two or three source files, one would be Windows
spicific code, one is Mac spicific code, and the last (optional one)
would be for non-spicific code.

[Gianni Mariani]

Siemel Naran wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message

Also, on some systems, a virtual function call is just as fast
as a regular call.

How can this be? You have to look up the address of a function in the
virtual table and then call it, so logic suggests it has to be slower. But
maybe I'm overlooking something?

CPU's today are very advanced and many things that made sense even 10
years ago, no longer are true. The biggest effects come from multiple
issue, speculative execution, cache effects and branch prediction.

For example - look at this code:
class foo
{
public:
virtual bool X() const = 0;

};

bool Y( void * v);

int DY( void ** v)
{
Y( * v );
return 0;
}

int Dfoo( const foo ** v)
{
(*v)->X();
return 0;
}
$ g++ -mtune=pentium4 -c -o xx.o xx.cpp -O3
$ objdump --disassemble xx.o

xx.o: file format elf32-i386

Disassembly of section .text:

00000000 <_Z2DYPPv>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: 8b 55 08 mov 0x8(%ebp),%edx
9: 8b 02 mov (%edx),%eax
b: 89 04 24 mov %eax,(%esp,1)
e: e8 fc ff ff ff call f <_Z2DYPPv+0xf>
13: 31 c0 xor %eax,%eax
15: c9 leave
16: c3 ret
17: 90 nop

00000018 <_Z4DfooPPK3foo>:
18: 55 push %ebp
19: 89 e5 mov %esp,%ebp
1b: 83 ec 08 sub $0x8,%esp
1e: 8b 4d 08 mov 0x8(%ebp),%ecx
21: 8b 01 mov (%ecx),%eax
23: 8b 10 mov (%eax),%edx
25: 89 04 24 mov %eax,(%esp,1)
28: ff 12 call *(%edx)
2a: 31 c0 xor %eax,%eax
2c: c9 leave
2d: c3 ret

Note that the code size for the virtual call version is *shorter* than
the non virtual call. On a multiple issue machine, both would execute at
in the same number of cycles.
On an Athlon64 machine:

$ g++ -m64 -c -o xx.o xx.cpp -O3
$ objdump --disassemble xx.o

xx.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <_Z2DYPPv>:
0: 48 83 ec 08 sub $0x8,%rsp
4: 48 8b 3f mov (%rdi),%rdi
7: e8 00 00 00 00 callq c <_Z2DYPPv+0xc>
c: 48 83 c4 08 add $0x8,%rsp
10: 31 c0 xor %eax,%eax
12: c3 retq
13: 90 nop
14: 66 data16
15: 66 data16
16: 66 data16
17: 90 nop
18: 66 data16
19: 66 data16
1a: 66 data16
1b: 90 nop
1c: 66 data16
1d: 66 data16
1e: 66 data16
1f: 90 nop

0000000000000020 <_Z4DfooPPK3foo>:
20: 48 83 ec 08 sub $0x8,%rsp
24: 48 8b 3f mov (%rdi),%rdi
27: 48 8b 07 mov (%rdi),%rax
2a: ff 10 callq *(%rax)
2c: 48 83 c4 08 add $0x8,%rsp
30: 31 c0 xor %eax,%eax
32: c3 retq

Note that the code size again for the virtual call version is *shorter*
than the non virtual call. Note also that the compiler generated a 32
bit instruction for the non-virtual call. On some other erchitectures,
a 64 bit call means loading 2 32 bit values into 2 separate registers
and combining them to create a 64 bit address (mips n64 is an example).

I don't have access to an Itanium compiler but I suspect that it is even
more telling.

In summary, it depends on your code and the architecture, but there are
examples where it can be faster to use virtual functions compared to
non-virtual functions.

The only time it's interesting to use non-virtual functions is where
it's possible to use inlining. As for the OP, inlining is out of the
question.

[DeMarcus]

Daniel T. wrote:

DeMarcus <no****@tellus.orb> wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Part of my job has been to ensure that the code written by the rest of
the people on the team is portable between Windows and MacOS X. Here is
how I solve the problem:

class GenericThingThatsImplementedDifferently {
class Impl;
Impl* pimpl;
public:
void genericFunction();
};

Then I will write two or three source files, one would be Windows
spicific code, one is Mac spicific code, and the last (optional one)
would be for non-spicific code.

Yes, I think this pattern is what they call a 'bridge' and it looks like
it will be the solution I go for.

[Daniel T.]

In article <40**************@tellus.orb>, DeMarcus <no****@tellus.orb>
wrote:

Daniel T. wrote:

DeMarcus <no****@tellus.orb> wrote:

Let's say we're gonna make a system library and have a class with
two prerequisites.

* It will be used _a_lot_, and therefore need to be really efficient.
* It can have two different implementations. (e.g. Unix/Windows)

I feel stuck. The only solution I've seen so far is using the
design pattern 'abstract factory' that gives me a pointer to a pure
virtual interface (which can have whatever implementation). But that
forces me to make a memory allocation every time I need an instance
of that class! That's all but efficient.

Do I have to live with this? Or do I have to make some kind of

class SystemThing
{
...
private:

strange_unix_var uv;
strange_win_var wv;
}

and then use the appropriate variable in the library implementation?

How is this problem commonly solved?

Part of my job has been to ensure that the code written by the rest of
the people on the team is portable between Windows and MacOS X. Here is
how I solve the problem:

class GenericThingThatsImplementedDifferently {
class Impl;
Impl* pimpl;
public:
void genericFunction();
};

Then I will write two or three source files, one would be Windows
spicific code, one is Mac spicific code, and the last (optional one)
would be for non-spicific code.

Yes, I think this pattern is what they call a 'bridge' and it looks like
it will be the solution I go for.

It looks like a bridge but it really isn't. In the Bridgle pattern, the
Implementor can be different for different Abstraction objects within
the same program (in fact the Implementor can be changed out for a
particular Abstraction object at runtime,) in the above all the
Abstraction objects must use the same Implementor.