dev-cpp-users

RE: [Dev-C++] Design decision in C++

[Jay B. <jay...@ni...>]

[snip]

=09
	 I =B4ve thought about a class-design for one of my projects.
	I=B4ve several big codeblocks like "compiler" which are seperated into =
classes.
	However, of this classes there is only one instance, like TheCompiler.
	So I thought of implementing this class using static methods rather =
than a regular class (I don=B4t need constructors/destructors).
	So, is it better do use a regular class and create one instance of it =
or to use a class which has only static methods (also easier)
	Where are the caveats?
	=20
	[/snip]
	=20
	Regular class?

[Dev-C++] Re: Design decision in C++

[Kevin B. <kev...@ma...>]

The main advantage to the static idea, of course, is that there will be no 
"this" pointer passed to all your calls, which will make them slightly more 
efficient.
The disadvantages are that the class will be very difficult to generalize 
and reuse, and that the syntax will seem "weird" and probably a bit 
difficult to understand for anybody else who ever needs to maintain this class.

Personally, I would disregard the "efficiency advantage", since it will 
likely be utterly insignificant. You should consider an "optimization" like 
this only when you have clear evidence from performance profiling of a 
working program that it will make some difference. The key is objective 
evidence; developers are notoriously bad at guessing where their 
performance bottlenecks lie. Resist the temptation to over-optimize before 
you know what the bottlenecks are, and especially before you even have a 
working design. The rule is, first make it correct, then make it fast.

If you're going to make all the class members static, you might as well 
just forget the class and define plain old variables and functions in a 
namespace. That would be syntactically almost identical, and conceptually 
cleaner. This all-static idea is *not* the same as a singleton pattern. A 
singleton class in general has no more than one instance at a time. With an 
all-static class, by contrast, there's no point having any instance at all. 
There's nothing for the "this" pointer to point to, so why bother? Ergo, if 
you're going to go this route, you might as well just use a namespace 
instead and avoid confusing future maintainers (and maybe even yourself) 
with a pointless class declaration.

--- Kevin

Re: [Dev-C++] Re: Design decision in C++

[Doug M. <dou...@al...>]

Per and Kevin,

Thanks for your advice.

My ambivalence wrt the Singleton<DataType> class is in part due to the 
instance pointer offset hack, which seems to introduce a risk of 
implementation dependency: are base and derived classes always included 
in a standard order with offsets that never vary from compiler to 
compiler?.  Further, the instance pointer adjustment involves pointer 
<-> int casts that are a bit ugly, despite the elegance of Singleton as 
seen from the outside.

But I take your points as to the limited desirability of fully static 
classes.

(I guess declaring a top-level static _instance_ of a class is a 
different matter, and is useful, e.g., when there is no C++ main 
routine, as was the case in a former project of mine at my last employer.)

--Doug

Re: [Dev-C++] Re: Design decision in C++

[Per W. <pw...@ia...>]

I haven't looked at any Singleton<DataType> class doing any instance
pointer offset hack.

The sample code I sent for a singleton object was just a very fiew lines
of manually added code to the class in question. 100% valid C++ without
any typecasts.

/Per W

On Thu, 11 Mar 2004, Doug MacDonald wrote:

> Per and Kevin,
>
> Thanks for your advice.
>
> My ambivalence wrt the Singleton<DataType> class is in part due to the
> instance pointer offset hack, which seems to introduce a risk of
> implementation dependency: are base and derived classes always included
> in a standard order with offsets that never vary from compiler to
> compiler?.  Further, the instance pointer adjustment involves pointer
> <-> int casts that are a bit ugly, despite the elegance of Singleton as
> seen from the outside.
>
> But I take your points as to the limited desirability of fully static
> classes.
>
> (I guess declaring a top-level static _instance_ of a class is a
> different matter, and is useful, e.g., when there is no C++ main
> routine, as was the case in a former project of mine at my last employer.)
>
> --Doug
>
>
>
>

Re: [Dev-C++] Re: Design decision in C++

[Doug M. <dou...@al...>]

Per,

I understand now.  You all have been talking about taking a regular 
class and adding code to it to make it a singleton.  My expressed 
ambivalence is toward something a bit different - it's a Singleton 
utility, so to speak.  Below is what I am referring to.  The idea is 
that you implement the Singleton behavior once and for all, as a 
template, then any class can become a singleton by inheriting from it as

class Klass : public Singleton<Klass> {
...
}

It's in making it work in general, through inheritance, that the 
ugliness I spoke of is introduced.

--Doug

#ifndef __SINGLETON_H__INCLUDED__
#define __SINGLETON_H__INCLUDED__

#include <assert.h>

template <typename Type>
class Singleton
{
	protected:
		static Type * ms_pInstance;
		
	public:
	// Constructor
	// The Singleton construct takes care of assinging a
	// value to the
	// instance pointer.  Since this class' child may have
	// more than one
	// parent, we have to do some pointer math to figure out
	// the correct
	// address for the child class
	Singleton ()
	{
		assert (!ms_pInstance);
		int iOffset = (int)(Type *)1 -
			(int)(Singleton<Type> *)(Type *)1;
		ms_pInstance = (Type *)((int)this + iOffset);
	}
		
	// Destructor
	virtual ~Singleton ()
	{
		assert (ms_pInstance);
		ms_pInstance = 0;
	}
		
	// Instance
	// Returns a reference to the singleton
	static Type & Instance ()
	{
		assert (ms_pInstance);
		return (*ms_pInstance);
	}
		
	// InstancePtr
	// Returns a pointer to the singleton
	static Type * InstancePtr ()
	{
		assert (ms_pInstance);
		return ms_pInstance;
	}

         // HasBeenInstantiated
         // Returns true if the class has been instantiated
         static bool HasBeenInstantiated ()
         {
             return (NULL != ms_pInstance);
         }
};

template <typename Type> Type * Singleton<Type>::ms_pInstance = 0;

#endif // __SINGLETON_H__INCLUDED__

> I haven't looked at any Singleton<DataType> class doing any instance 
> pointer offset hack.
> 
> The sample code I sent for a singleton object was just a very fiew
> lines of manually added code to the class in question. 100% valid C++
> without any typecasts.
> 
> /Per W
> 
> On Thu, 11 Mar 2004, Doug MacDonald wrote:
> 
> 
>>> Per and Kevin,
>>> 
>>> Thanks for your advice.
>>> 
>>> My ambivalence wrt the Singleton<DataType> class is in part due
>>> to the instance pointer offset hack, which seems to introduce a
>>> risk of implementation dependency: are base and derived classes
>>> always included in a standard order with offsets that never vary
>>> from compiler to compiler?.  Further, the instance pointer
>>> adjustment involves pointer <-> int casts that are a bit ugly,
>>> despite the elegance of Singleton as seen from the outside.
>>> 
>>> But I take your points as to the limited desirability of fully
>>> static classes.
>>> 
>>> (I guess declaring a top-level static _instance_ of a class is a 
>>> different matter, and is useful, e.g., when there is no C++ main 
>>> routine, as was the case in a former project of mine at my last
>>> employer.)
>>> 
>>> --Doug

RE: [Dev-C++] Re: Design decision in C++

[P.D. v. Z. <pd...@xs...>]

Eek!
You still seem to be having a bad implementation of Singleton. My Singleton
classes are derived from a Singleton utility class template as well, but I
have none of that ugliness in my code. I do need a different bit of ugly
though, a friend declaration, but that seems a lot better than pointer
offsets and the like.
The only extra thing I need to do in the derived classes is declare my
constructor, destructor, copy constructor and assignment operator as
something non-public (along with not implementing the copy constructor and
assignment operator, to catch attempted accidental copying).

Regards,


Paul

P.S.: I didn't actually write the Singleton class template I use myself, I
found it on the internet somewhere a while ago. Later I found an apparently
much better implementation, but I still don't understand the bulk of the
code involved in that one, let alone how to use it.

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Doug
MacDonald
Sent: Friday, March 12, 2004 6:06 AM
To: dev...@li...
Subject: Re: [Dev-C++] Re: Design decision in C++

Per,

I understand now.  You all have been talking about taking a regular 
class and adding code to it to make it a singleton.  My expressed 
ambivalence is toward something a bit different - it's a Singleton 
utility, so to speak.  Below is what I am referring to.  The idea is 
that you implement the Singleton behavior once and for all, as a 
template, then any class can become a singleton by inheriting from it as

class Klass : public Singleton<Klass> {
...
}

It's in making it work in general, through inheritance, that the 
ugliness I spoke of is introduced.

--Doug

#ifndef __SINGLETON_H__INCLUDED__
#define __SINGLETON_H__INCLUDED__

#include <assert.h>

template <typename Type>
class Singleton
{
	protected:
		static Type * ms_pInstance;
		
	public:
	// Constructor
	// The Singleton construct takes care of assinging a
	// value to the
	// instance pointer.  Since this class' child may have
	// more than one
	// parent, we have to do some pointer math to figure out
	// the correct
	// address for the child class
	Singleton ()
	{
		assert (!ms_pInstance);
		int iOffset = (int)(Type *)1 -
			(int)(Singleton<Type> *)(Type *)1;
		ms_pInstance = (Type *)((int)this + iOffset);
	}
		
	// Destructor
	virtual ~Singleton ()
	{
		assert (ms_pInstance);
		ms_pInstance = 0;
	}
		
	// Instance
	// Returns a reference to the singleton
	static Type & Instance ()
	{
		assert (ms_pInstance);
		return (*ms_pInstance);
	}
		
	// InstancePtr
	// Returns a pointer to the singleton
	static Type * InstancePtr ()
	{
		assert (ms_pInstance);
		return ms_pInstance;
	}

         // HasBeenInstantiated
         // Returns true if the class has been instantiated
         static bool HasBeenInstantiated ()
         {
             return (NULL != ms_pInstance);
         }
};

template <typename Type> Type * Singleton<Type>::ms_pInstance = 0;

#endif // __SINGLETON_H__INCLUDED__

> I haven't looked at any Singleton<DataType> class doing any instance 
> pointer offset hack.
> 
> The sample code I sent for a singleton object was just a very fiew
> lines of manually added code to the class in question. 100% valid C++
> without any typecasts.
> 
> /Per W
> 
> On Thu, 11 Mar 2004, Doug MacDonald wrote:
> 
> 
>>> Per and Kevin,
>>> 
>>> Thanks for your advice.
>>> 
>>> My ambivalence wrt the Singleton<DataType> class is in part due
>>> to the instance pointer offset hack, which seems to introduce a
>>> risk of implementation dependency: are base and derived classes
>>> always included in a standard order with offsets that never vary
>>> from compiler to compiler?.  Further, the instance pointer
>>> adjustment involves pointer <-> int casts that are a bit ugly,
>>> despite the elegance of Singleton as seen from the outside.
>>> 
>>> But I take your points as to the limited desirability of fully
>>> static classes.
>>> 
>>> (I guess declaring a top-level static _instance_ of a class is a 
>>> different matter, and is useful, e.g., when there is no C++ main 
>>> routine, as was the case in a former project of mine at my last
>>> employer.)
>>> 
>>> --Doug





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

[Dev-C++] other programs through our program...

[Siva C. <siv...@ya...>]

hello,

this is might be an easy one(and could be out of
place!)...

How do we run the standard windows programs through
our application. for example clicking the help menu
starts the IE!!

TIA

Siva Chandra

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: [Dev-C++] other programs through our program...

[<gen...@ya...>]

it's really easy. use ShellExecute()/ShellExecuteInfo() (defined in shellapi.h) to run programs. i think it works with registered windows programs, so it's like Start -> Run... i used it to run my favorite emulators once from a menu :D

		
---------------------------------
  Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now

Re: [Dev-C++] Re: Design decision in C++

[Doug M. <dou...@al...>]

Hi Paul,

If it's not proprietary, may I see the Singleton class template 
definition from which you derive your singleton classes?  I'd be 
interested to try to convince my client to switch to a better 
implementation.

Doug

> Eek! You still seem to be having a bad implementation of Singleton.
> My Singleton classes are derived from a Singleton utility class
> template as well, but I have none of that ugliness in my code. I do
> need a different bit of ugly though, a friend declaration, but that
> seems a lot better than pointer offsets and the like. The only extra
> thing I need to do in the derived classes is declare my constructor,
> destructor, copy constructor and assignment operator as something
> non-public (along with not implementing the copy constructor and 
> assignment operator, to catch attempted accidental copying).
> 
> Regards,
> 
> 
> Paul
> 
> P.S.: I didn't actually write the Singleton class template I use
> myself, I found it on the internet somewhere a while ago. Later I
> found an apparently much better implementation, but I still don't
> understand the bulk of the code involved in that one, let alone how
> to use it.
> 
> -----Original Message-----
> 
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf Of Doug 
> MacDonald Sent: Friday, March 12, 2004 6:06 AM To:
> dev...@li... Subject: Re: [Dev-C++] Re: Design
> decision in C++
> 
> Per,
> 
> I understand now.  You all have been talking about taking a regular 
> class and adding code to it to make it a singleton.  My expressed 
> ambivalence is toward something a bit different - it's a Singleton 
> utility, so to speak.  Below is what I am referring to.  The idea is
>  that you implement the Singleton behavior once and for all, as a 
> template, then any class can become a singleton by inheriting from it
> as
> 
> class Klass : public Singleton<Klass> { ... }
> 
> It's in making it work in general, through inheritance, that the 
> ugliness I spoke of is introduced.
> 
> --Doug
> 
> #ifndef __SINGLETON_H__INCLUDED__ #define __SINGLETON_H__INCLUDED__
> 
> #include <assert.h>
> 
> template <typename Type> class Singleton { protected: static Type *
> ms_pInstance;
> 
> public: // Constructor // The Singleton construct takes care of
> assinging a // value to the // instance pointer.  Since this class'
> child may have // more than one // parent, we have to do some pointer
> math to figure out // the correct // address for the child class 
> Singleton () { assert (!ms_pInstance); int iOffset = (int)(Type *)1 -
>  (int)(Singleton<Type> *)(Type *)1; ms_pInstance = (Type *)((int)this
> + iOffset); }
> 
> // Destructor virtual ~Singleton () { assert (ms_pInstance); 
> ms_pInstance = 0; }
> 
> // Instance // Returns a reference to the singleton static Type &
> Instance () { assert (ms_pInstance); return (*ms_pInstance); }
> 
> // InstancePtr // Returns a pointer to the singleton static Type *
> InstancePtr () { assert (ms_pInstance); return ms_pInstance; }
> 
> // HasBeenInstantiated // Returns true if the class has been
> instantiated static bool HasBeenInstantiated () { return (NULL !=
> ms_pInstance); } };
> 
> template <typename Type> Type * Singleton<Type>::ms_pInstance = 0;
> 
> #endif // __SINGLETON_H__INCLUDED__
> 
> 
>>> I haven't looked at any Singleton<DataType> class doing any
>>> instance pointer offset hack.
>>> 
>>> The sample code I sent for a singleton object was just a very
>>> fiew lines of manually added code to the class in question. 100%
>>> valid C++ without any typecasts.
>>> 
>>> /Per W
>>> 
>>> On Thu, 11 Mar 2004, Doug MacDonald wrote:
>>> 
>>> 
>> 
>>>>>>> Per and Kevin,
>>>>>>> 
>>>>>>> Thanks for your advice.
>>>>>>> 
>>>>>>> My ambivalence wrt the Singleton<DataType> class is in
>>>>>>> part due to the instance pointer offset hack, which seems
>>>>>>> to introduce a risk of implementation dependency: are
>>>>>>> base and derived classes always included in a standard
>>>>>>> order with offsets that never vary from compiler to
>>>>>>> compiler?.  Further, the instance pointer adjustment
>>>>>>> involves pointer <-> int casts that are a bit ugly, 
>>>>>>> despite the elegance of Singleton as seen from the
>>>>>>> outside.
>>>>>>> 
>>>>>>> But I take your points as to the limited desirability of
>>>>>>> fully static classes.
>>>>>>> 
>>>>>>> (I guess declaring a top-level static _instance_ of a
>>>>>>> class is a different matter, and is useful, e.g., when
>>>>>>> there is no C++ main routine, as was the case in a former
>>>>>>> project of mine at my last employer.)
>>>>>>> 
>>>>>>> --Doug