Header File Object Definition Trick

[Frederick Gotham]

Let's say you want to write a simple header file, and don't want to be
burdened with having to provide a source file as well with it.

There's a problem when the need arises for a global object. You could simply
make the object static... but then you'll have a separate object for each
source file that includes the header.

Do many people use a inline function to get around this?

inline
int &GetGlobal()
{
static int i;
return i;
}

--

Frederick Gotham

[peter koch]

Re: Header File Object Definition Trick


Frederick Gotham wrote:

Let's say you want to write a simple header file, and don't want to be
burdened with having to provide a source file as well with it.
>
There's a problem when the need arises for a global object. You could simply
make the object static... but then you'll have a separate object for each
source file that includes the header.
>
Do many people use a inline function to get around this?
>
inline
int &GetGlobal()
{
static int i;
return i;
}

I don't hope so ;-)

/Peter

[Phlip]

Re: Header File Object Definition Trick

peter koch wrote:

>Do many people use a inline function to get around this?
>>
> inline
> int &GetGlobal()
> {
> static int i;
> return i;
> }

>
I don't hope so ;-)

That's actually a common technique to make i a Singleton:

inline
SingleClass & getSingleton()
{
static SingleClass sc;
return sc;
}

The benefit is sc is well-defined to construct just before that function
enters. If sc were in the global data space, it would define at a random
time before main(), so any code that uses sc before main() would have
undefined behavior.

Now read "Singletoni tis" in news:comp.objec t to avoid singleton abuse! And
don't put this crap in a header - write an implementation file for it. Some
small C++ applications can get by with header-only implementations , but
large scale C++ applications are bound by their compile times, so
implementation files are crucial.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Victor Bazarov]

Re: Header File Object Definition Trick

peter koch wrote:

Frederick Gotham wrote:

>Let's say you want to write a simple header file, and don't want to
>be burdened with having to provide a source file as well with it.
>>
>There's a problem when the need arises for a global object. You
>could simply make the object static... but then you'll have a
>separate object for each source file that includes the header.
>>
>Do many people use a inline function to get around this?
>>
> inline
> int &GetGlobal()
> {
> static int i;
> return i;
> }

>
I don't hope so ;-)

Why not? This is one of singleton implementations . Compare:

class MySingleton {
MySingleton(); // private c-tor, nobody else should construct
public:
static MySingleton& instance() {
static MySingleton s;
return s;
}
};

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[peter koch]

Re: Header File Object Definition Trick


Victor Bazarov wrote:

peter koch wrote:

Frederick Gotham wrote:

Let's say you want to write a simple header file, and don't want to
be burdened with having to provide a source file as well with it.
>
There's a problem when the need arises for a global object. You
could simply make the object static... but then you'll have a
separate object for each source file that includes the header.
>
Do many people use a inline function to get around this?
>
inline
int &GetGlobal()
{
static int i;
return i;
}

I don't hope so ;-)

>
Why not? This is one of singleton implementations . Compare:
>
class MySingleton {
MySingleton(); // private c-tor, nobody else should construct
public:
static MySingleton& instance() {
static MySingleton s;
return s;
}
};
>

Surely - I know that idiom. But Fredericks question was not about
singletons, but rather one of laziness. And when a singleton is
appropriate, you better write something more elaborate than what
Frederick wrote or you'll get in trouble. If for nothing else, theres
the problem about using the function in multithreaded code. This
suddenly is unsafe even if youre only reading.
So put shortly: don't do what Frederick suggests unless you have given
it good thought.

/Peter

[peter koch]

Re: Header File Object Definition Trick


Phlip wrote:

peter koch wrote:
>

Do many people use a inline function to get around this?
>
inline
int &GetGlobal()
{
static int i;
return i;
}

I don't hope so ;-)

>
That's actually a common technique to make i a Singleton:
>
inline
SingleClass & getSingleton()
{
static SingleClass sc;
return sc;
}

Correct.

>
The benefit is sc is well-defined to construct just before that function
enters. If sc were in the global data space, it would define at a random
time before main(), so any code that uses sc before main() would have
undefined behavior.
>
Now read "Singletoni tis" in news:comp.objec t to avoid singleton abuse! And
don't put this crap in a header - write an implementation file for it. Some
small C++ applications can get by with header-only implementations , but
large scale C++ applications are bound by their compile times, so
implementation files are crucial.
>

Right. And it is not just compilation time that is an issue.

/Peter

[Kai-Uwe Bux]

Re: Header File Object Definition Trick

peter koch wrote:

>
Victor Bazarov wrote:

>peter koch wrote:

Frederick Gotham wrote:
>Let's say you want to write a simple header file, and don't want to
>be burdened with having to provide a source file as well with it.
>>
>There's a problem when the need arises for a global object. You
>could simply make the object static... but then you'll have a
>separate object for each source file that includes the header.
>>
>Do many people use a inline function to get around this?
>>
> inline
> int &GetGlobal()
> {
> static int i;
> return i;
> }
>
I don't hope so ;-)

>>
>Why not? This is one of singleton implementations . Compare:
>>
> class MySingleton {
> MySingleton(); // private c-tor, nobody else should construct
> public:
> static MySingleton& instance() {
> static MySingleton s;
> return s;
> }
> };
>>

Surely - I know that idiom. But Fredericks question was not about
singletons, but rather one of laziness.

That maybe the way he put up the problem. However if your interface is
templated, your maybe forced to put your implementation into the header
(e.g., when your compiler does not support "export").

And when a singleton is
appropriate, you better write something more elaborate than what
Frederick wrote or you'll get in trouble. If for nothing else, theres
the problem about using the function in multithreaded code. This
suddenly is unsafe even if youre only reading.

I can see the problems with multithreading for the first call that needs to
create the variable. However, my eyes fail me for the subsequent calls.
Could you elaborate on this one -- it sounds interesting.

So put shortly: don't do what Frederick suggests unless you have given
it good thought.

Well, name some idiom in C++ for which that does not hold :-)


Best

Kai-Uwe Bux

[Frederick Gotham]

Re: Header File Object Definition Trick

peter koch posted:

Surely - I know that idiom. But Fredericks question was not about
singletons, but rather one of laziness.

Using a header just involves a simple #include.

Using a source file involves adding it to your "compile files" and so on...

--

Frederick Gotham

[peter koch]

Re: Header File Object Definition Trick


Kai-Uwe Bux skrev:

peter koch wrote:
>

[snip]

And when a singleton is
appropriate, you better write something more elaborate than what
Frederick wrote or you'll get in trouble. If for nothing else, theres
the problem about using the function in multithreaded code. This
suddenly is unsafe even if youre only reading.

>
I can see the problems with multithreading for the first call that needs to
create the variable. However, my eyes fail me for the subsequent calls.
Could you elaborate on this one -- it sounds interesting.

Well, I do not really have more to add. The only thing to be afraid of
is the first call. (That is two threads calling the same function for
the first time at about the same moment). But even if it sounds like an
unrealistic, it is not. My experience tells me that those problem will
occur if you do not take appropriate guards.
In this case I prefer a plain global variable - or a "real" function
that serialises the access in case there is some dependency you can not
get rid of (as you surely know, the order of construction within one
file is well-defined).

So put shortly: don't do what Frederick suggests unless you have given
it good thought.

>
Well, name some idiom in C++ for which that does not hold :-)

Surely. And this probably holds for any language.

/Peter