www.digitalmars.com         C & C++   DMDScript  

D - singleton classes

reply imr1984 <imr1984_member pathlink.com> writes:
Often programmers make classes that are only intended to have one instance for
the duration of the whole program. These are called singleton classes. D should
have built in support for them so that a singleton object will have its own
methods generated for it, without the use of a this pointer. This would save on
a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 13 2004
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
singletons are one of the most stupid trend-programming-idioms.

most people just use them because they don't know how to design else..

in D, i'd suggest you bether write a module. this _is_ what a singleton
_should_be_.

a.k.a.

mySingleton.d
--------------
module mySingleton;

private int data;

void set(int value) {
data = value;
}

int get() {
return data;
}
--------------

main.d
--------------
import mySingleton; // private import? :D

int main(char[][] args) {
mySingleton.set(10);
printf("%i" \n,mySingleton.get());
}
--------------

like this

In article <bu0da8$1qic$1 digitaldaemon.com>, imr1984 says...

Often programmers make classes that are only intended to have one instance for
the duration of the whole program. These are called singleton classes. D should
have built in support for them so that a singleton object will have its own
methods generated for it, without the use of a this pointer. This would save on
a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 13 2004
next sibling parent reply imr1984 <imr1984_member pathlink.com> writes:
ar cheers for that. So D already has support for it then, you just use global
private variables. cunning.

In article <bu0ef1$1sds$1 digitaldaemon.com>, davepermen says...

singletons are one of the most stupid trend-programming-idioms.

most people just use them because they don't know how to design else..

in D, i'd suggest you bether write a module. this _is_ what a singleton
_should_be_.

a.k.a.

mySingleton.d
--------------
module mySingleton;

private int data;

void set(int value) {
data = value;
}

int get() {
return data;
}
--------------

main.d
--------------
import mySingleton; // private import? :D

int main(char[][] args) {
mySingleton.set(10);
printf("%i" \n,mySingleton.get());
}
--------------

like this

In article <bu0da8$1qic$1 digitaldaemon.com>, imr1984 says...

Often programmers make classes that are only intended to have one instance for
the duration of the whole program. These are called singleton classes. D should
have built in support for them so that a singleton object will have its own
methods generated for it, without the use of a this pointer. This would save on
a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 13 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
as singletons are nothing more than that (globals), yes.. the real module
support of D makes it possible to have them more easy than in c++

but always remember. singletons ARE just globals. if you don't need them, bether
don't make them.

In article <bu0eol$1su2$1 digitaldaemon.com>, imr1984 says...

ar cheers for that. So D already has support for it then, you just use global
private variables. cunning.

In article <bu0ef1$1sds$1 digitaldaemon.com>, davepermen says...

singletons are one of the most stupid trend-programming-idioms.

most people just use them because they don't know how to design else..

in D, i'd suggest you bether write a module. this _is_ what a singleton
_should_be_.

a.k.a.

mySingleton.d
--------------
module mySingleton;

private int data;

void set(int value) {
data = value;
}

int get() {
return data;
}
--------------

main.d
--------------
import mySingleton; // private import? :D

int main(char[][] args) {
mySingleton.set(10);
printf("%i" \n,mySingleton.get());
}
--------------

like this

In article <bu0da8$1qic$1 digitaldaemon.com>, imr1984 says...

Often programmers make classes that are only intended to have one instance for
the duration of the whole program. These are called singleton classes. D should
have built in support for them so that a singleton object will have its own
methods generated for it, without the use of a this pointer. This would save on
a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 13 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
as singletons are nothing more than that (globals), yes.. the real module
support of D makes it possible to have them more easy than in c++



global is a variable that is accessable everywhere. I don't see what these two
definitions have in common.
You could make the instance of the singleton be a global, but you don't have to.
Jan 13 2004
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
i know that they don't theoretically have much in common. but in real life, all
newbies abuse singletons to fit a nice oo-cover around their globals.

In article <bu1bk1$b7n$1 digitaldaemon.com>, Matthias Becker says...

as singletons are nothing more than that (globals), yes.. the real module
support of D makes it possible to have them more easy than in c++



global is a variable that is accessable everywhere. I don't see what these two
definitions have in common.
You could make the instance of the singleton be a global, but you don't have to.
Jan 13 2004
next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
i know that they don't theoretically have much in common. but in real life, all
newbies abuse singletons to fit a nice oo-cover around their globals.



That's true, right.
Jan 14 2004
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bu1coo$d8u$1 digitaldaemon.com...

 i know that they don't theoretically have much in common. but in real




 newbies abuse singletons to fit a nice oo-cover around their globals.



There is still some benefit to laying out your memory usage at compile time.
Depending on your design, some parts of the system may in fact be best
modeled as globals.  For a game, the video device, file system, system
timer, mouse, keyboard, sound card, etc are all going to stay the same for
the duration of the program, so why bother instantiating them on the heap?


 In article <bu1bk1$b7n$1 digitaldaemon.com>, Matthias Becker says...

as singletons are nothing more than that (globals), yes.. the real










support of D makes it possible to have them more easy than in c++










global is a variable that is accessable everywhere. I don't see what







definitions have in common.
You could make the instance of the singleton be a global, but you don't







You are right.  They are really two separate issues.  In practice most of my
"make once" singletons also need a single point of access.

A namespace in C++ is probably the closest thing to a singleton that it has.
But then you still have inter-module startup/shutdown order problems.

Any other use for a singleton doesn't seem very useful... why make a class
if you're only going to use it once?  To get automatic cleanup?  Do you
write your function bodies as classes?

Sean
Jan 15 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bu1bk1$b7n$1 digitaldaemon.com>, Matthias Becker says...

as singletons are nothing more than that (globals), yes.. the real module
support of D makes it possible to have them more easy than in c++



global is a variable that is accessable everywhere. I don't see what these two
definitions have in common.
You could make the instance of the singleton be a global, but you don't have to.



this site

http://home.earthlink.net/~huston2/dp/patterns.html

contains every thing I know about patterns.
check the singleton and why and when should be used.

I prefer to consult that insted of
"Thinking in Patterns" by Bruce Eckel
at http://mindview.net/Books/TIPatterns/

Ant
Jan 13 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


singletons are one of the most stupid trend-programming-idioms.

most people just use them because they don't know how to design else..

in D, i'd suggest you bether write a module. this _is_ what a singleton
_should_be_.

a.k.a.

mySingleton.d
--------------
module mySingleton;

private int data;

void set(int value) {
data = value;
}

int get() {
return data;
}
--------------

main.d
--------------
import mySingleton; // private import? :D

int main(char[][] args) {
mySingleton.set(10);
printf("%i" \n,mySingleton.get());
}
--------------

like this
Jan 13 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
In article <bu0i1p$21m1$2 digitaldaemon.com>, J Anderson says...

But you can't extend that singleton.




anyways, i don't use singletons myself at all. they are 100% useless imho
Jan 13 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


In article <bu0i1p$21m1$2 digitaldaemon.com>, J Anderson says...
  


But you can't extend that singleton.

    



  



don't get virtual functions ;(.  It'd be nice if you could extend 
namespaces (and templates), which included static virtual functions -> 
it might help solve the free operators problem.


anyways, i don't use singletons myself at all. they are 100% useless imho

  



But your right, most of the time I change singletons into classes as I 
realism their more useful that way.  What's an extra memory access on 
the stack at that level anyway? the compiler probably wouldn't beat an 
eyebrow.  It's the inner code you've gota worry about.
Jan 13 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
davepermen wrote:


 In article <bu0i1p$21m1$2 digitaldaemon.com>, J Anderson says...
 

But you can't extend that singleton.



 hm? show me how to extend a normal one?
 
 anyways, i don't use singletons myself at all. they are 100% useless imho



interface FileSystem {
    File openFile(char[] fileName);
    char[][] getFileList();
}

class ZipFileSystem : FileSystem {
    ...
}

class FtpFileSystem : FileSystem {
    ...
}

class PhysicalFileSystem : FileSystem {
    // This could reasonably be a singleton.
}

A singleton implemented as a module can't be extended, sure, but more 
importantly, they can't implement an interface.

  -- andy
Jan 13 2004
parent reply imr1984 <imr1984_member pathlink.com> writes:
So should i encapsulate the base of my program (the Core if you will) in a class
or should i just leave them as private globals?
Jan 13 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
imr1984 wrote:

 So should i encapsulate the base of my program (the Core if you will) in a
class
 or should i just leave them as private globals?
 



If you are not going to reuse this "core" at other places within your 
hierarchy/project, that is it application specific and not something 
like a layer or a library, you should rather have private globals.

Make everything the simplest way which works. But think a bit and 
refractor if you find a need to duplicate the code within the same 
project. Simply don't be afraid to break the code later on. DBC will 
save you from evil problems after refractoring And have something like 
CVS handy to track versions and show diffs.

-eye
Jan 14 2004
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Right.  Singletons are a terrible hack that attempts to allow C++ to have a
module system, as Turbo Pascal / Delphi had with units and as D does with
modules.

Really you don't want to use an instance of a class, you want a static block
of data that has "methods" which have private visibility onto the scope, and
static ctor and dtor for init at program start and shutdown at program
termination, in the reverse order of initialization.  Module interdependency
order determines which modules get "constructed" first.  You can make it
look like a class if you want, but the fundamental difference is that the
module "class" and the only "instance" are the same thing.

Doing the above in C++ requires all manner of nasty kludges, and is rife
with problems.  It's a pretty fundamental need, and deserves language
support.  But D already got this right, so there's nothing more to do there
from what I can see.  Just look up "static constructors" on the D
Programming Language website.

Sean

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bu0ef1$1sds$1 digitaldaemon.com...

 singletons are one of the most stupid trend-programming-idioms.

 most people just use them because they don't know how to design else..

 in D, i'd suggest you bether write a module. this _is_ what a singleton
 _should_be_.

 a.k.a.

 mySingleton.d
 --------------
 module mySingleton;

 private int data;

 void set(int value) {
 data = value;
 }

 int get() {
 return data;
 }
 --------------

 main.d
 --------------
 import mySingleton; // private import? :D

 int main(char[][] args) {
 mySingleton.set(10);
 printf("%i" \n,mySingleton.get());
 }
 --------------

 like this

 In article <bu0da8$1qic$1 digitaldaemon.com>, imr1984 says...

Often programmers make classes that are only intended to have one







the duration of the whole program. These are called singleton classes. D







have built in support for them so that a singleton object will have its







methods generated for it, without the use of a this pointer. This would







a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 15 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
davepermen wrote:

[...]

 most stupid trend-programming-idioms.




 mySingleton.set(10);
 printf("%i" \n,mySingleton.get());



What do you call a program that allows a private variable ot be set as
well as retrieved by getters and setters, that does not have any side
effects, like for example writing into a protocol file, instead of making
that variable global?

So long.
Mar 08 2004
prev sibling next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
imr1984 wrote:


Often programmers make classes that are only intended to have one instance for
the duration of the whole program. These are called singleton classes. D should
have built in support for them so that a singleton object will have its own
methods generated for it, without the use of a this pointer. This would save on
a this parameter being pushed on stack to a singleton class method.

Walter, what da ya say?
Jan 13 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"imr1984" <imr1984_member pathlink.com> wrote in message
news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one instance




 the duration of the whole program. These are called singleton classes. D




 have built in support for them so that a singleton object will have its




 methods generated for it, without the use of a this pointer. This would




 a this parameter being pushed on stack to a singleton class method.

 Walter, what da ya say?



Since the only hard thing about singletons - ensuring that the creation and
destruction happens deterministically - is handled in D, by virtue of the
module initialisation, where's the need?
Jan 13 2004
prev sibling parent reply "Phill" <phill pacific.net.au> writes:
You should be able to implement a Singleton pattern
easy.
This is what I do in Java

public class One{
     public static One one;

public static void getOne(){
        if(one == null){
              one new One();
            }
    }

private One(){ // private constructor
   //construct stuff
}

}

This way if there is an instance of One already
you cannot make another One.

This was good for me in Java because I found
that when clicking a JTable for some reason the
Thread goes through the event listener method
twice.

The Singleton pattern solved this problem for
me.


Phill.




"imr1984" <imr1984_member pathlink.com> wrote in message
news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one instance




 the duration of the whole program. These are called singleton classes. D




 have built in support for them so that a singleton object will have its




 methods generated for it, without the use of a this pointer. This would




 a this parameter being pushed on stack to a singleton class method.

 Walter, what da ya say?
Jan 13 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
The best solution is to define a template which creates one instance, when
this instance is requested. For example:

template <class T> class Singleton {
    private T *_object;
    T *object() {
        if (_object == null) _object = new T();
        return _object;
    }
}


"Phill" <phill pacific.net.au> wrote in message
news:bu20mp$1ft2$1 digitaldaemon.com...

 You should be able to implement a Singleton pattern
 easy.
 This is what I do in Java

 public class One{
      public static One one;

 public static void getOne(){
         if(one == null){
               one new One();
             }
     }

 private One(){ // private constructor
    //construct stuff
 }

 }

 This way if there is an instance of One already
 you cannot make another One.

 This was good for me in Java because I found
 that when clicking a JTable for some reason the
 Thread goes through the event listener method
 twice.

 The Singleton pattern solved this problem for
 me.


 Phill.




 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one







 for

 the duration of the whole program. These are called singleton classes. D




 have built in support for them so that a singleton object will have its




 methods generated for it, without the use of a this pointer. This would




 a this parameter being pushed on stack to a singleton class method.

 Walter, what da ya say?
Jan 13 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
No. That leaves you with all the thread nasties and ordering and dead
reference problems.

A valid compromise is to have the singleton notionally initialised during
module initialisation - a wonderful boon from D, and not to be wasted - and
then to have any expensive state created lazily, in a thread-safe fashion.
The state is then reference-counted by the module un/initialisation state,
so there are no dead-references.






"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one instance, when
 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }


 "Phill" <phill pacific.net.au> wrote in message
 news:bu20mp$1ft2$1 digitaldaemon.com...

 You should be able to implement a Singleton pattern
 easy.
 This is what I do in Java

 public class One{
      public static One one;

 public static void getOne(){
         if(one == null){
               one new One();
             }
     }

 private One(){ // private constructor
    //construct stuff
 }

 }

 This way if there is an instance of One already
 you cannot make another One.

 This was good for me in Java because I found
 that when clicking a JTable for some reason the
 Thread goes through the event listener method
 twice.

 The Singleton pattern solved this problem for
 me.


 Phill.




 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one







 for

 the duration of the whole program. These are called singleton classes.










 should

 have built in support for them so that a singleton object will have










 own

 methods generated for it, without the use of a this pointer. This










 save on

 a this parameter being pushed on stack to a singleton class method.

 Walter, what da ya say?
Jan 13 2004
parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
What thread nasties ? if you want to make a template synchronized class, go
ahead. Nothing stops you.

As for the dead reference problems, since the internal pointer is never
nullified, the object will not go away, unless the singleton class is
destroyed. But singletons are supposed to be used that way.

I don't see any of the problems you are mentioning.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bu27c5$1q90$1 digitaldaemon.com...

 No. That leaves you with all the thread nasties and ordering and dead
 reference problems.

 A valid compromise is to have the singleton notionally initialised during
 module initialisation - a wonderful boon from D, and not to be wasted -




 then to have any expensive state created lazily, in a thread-safe fashion.
 The state is then reference-counted by the module un/initialisation state,
 so there are no dead-references.






 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one instance,







 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }


 "Phill" <phill pacific.net.au> wrote in message
 news:bu20mp$1ft2$1 digitaldaemon.com...

 You should be able to implement a Singleton pattern
 easy.
 This is what I do in Java

 public class One{
      public static One one;

 public static void getOne(){
         if(one == null){
               one new One();
             }
     }

 private One(){ // private constructor
    //construct stuff
 }

 }

 This way if there is an instance of One already
 you cannot make another One.

 This was good for me in Java because I found
 that when clicking a JTable for some reason the
 Thread goes through the event listener method
 twice.

 The Singleton pattern solved this problem for
 me.


 Phill.




 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one







 for

 the duration of the whole program. These are called singleton













 D

 should

 have built in support for them so that a singleton object will have










 own

 methods generated for it, without the use of a this pointer. This










 save on

 a this parameter being pushed on stack to a singleton class method.

 Walter, what da ya say?
Jan 16 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
The threading problem's very simple: two or more threads may call object()
for "the first time" at the same time.

Q: how many instances of T get created?



"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bu9lqn$20fo$1 digitaldaemon.com...

 What thread nasties ? if you want to make a template synchronized class,




 ahead. Nothing stops you.

 As for the dead reference problems, since the internal pointer is never
 nullified, the object will not go away, unless the singleton class is
 destroyed. But singletons are supposed to be used that way.

 I don't see any of the problems you are mentioning.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu27c5$1q90$1 digitaldaemon.com...

 No. That leaves you with all the thread nasties and ordering and dead
 reference problems.

 A valid compromise is to have the singleton notionally initialised







 module initialisation - a wonderful boon from D, and not to be wasted -




 then to have any expensive state created lazily, in a thread-safe







 The state is then reference-counted by the module un/initialisation







 so there are no dead-references.






 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one instance,







 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }


 "Phill" <phill pacific.net.au> wrote in message
 news:bu20mp$1ft2$1 digitaldaemon.com...

 You should be able to implement a Singleton pattern
 easy.
 This is what I do in Java

 public class One{
      public static One one;

 public static void getOne(){
         if(one == null){
               one new One();
             }
     }

 private One(){ // private constructor
    //construct stuff
 }

 }

 This way if there is an instance of One already
 you cannot make another One.

 This was good for me in Java because I found
 that when clicking a JTable for some reason the
 Thread goes through the event listener method
 twice.

 The Singleton pattern solved this problem for
 me.


 Phill.




 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have one







 for

 the duration of the whole program. These are called singleton













 D

 should

 have built in support for them so that a singleton object will
















 its

 own

 methods generated for it, without the use of a this pointer. This










 save on

 a this parameter being pushed on stack to a singleton class
















 Walter, what da ya say?
Jan 16 2004
parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
That's why there can be a synchronized singleton class:

template <class X> SynchronizeSingleton {

    private Mutex mutex = new Mutex();

    private X object = null;

    public X getObject() {
        mutex.lock();
        if (object == null) object = new X();
        mutex.unlock();
        return object;
    }
}

It's dead easy.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bua4ih$2o0h$1 digitaldaemon.com...

 The threading problem's very simple: two or more threads may call object()
 for "the first time" at the same time.

 Q: how many instances of T get created?



 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:bu9lqn$20fo$1 digitaldaemon.com...

 What thread nasties ? if you want to make a template synchronized class,




 ahead. Nothing stops you.

 As for the dead reference problems, since the internal pointer is never
 nullified, the object will not go away, unless the singleton class is
 destroyed. But singletons are supposed to be used that way.

 I don't see any of the problems you are mentioning.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bu27c5$1q90$1 digitaldaemon.com...

 No. That leaves you with all the thread nasties and ordering and dead
 reference problems.

 A valid compromise is to have the singleton notionally initialised







 module initialisation - a wonderful boon from D, and not to be










 and

 then to have any expensive state created lazily, in a thread-safe







 The state is then reference-counted by the module un/initialisation







 so there are no dead-references.






 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one













 when

 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }


 "Phill" <phill pacific.net.au> wrote in message
 news:bu20mp$1ft2$1 digitaldaemon.com...

 You should be able to implement a Singleton pattern
 easy.
 This is what I do in Java

 public class One{
      public static One one;

 public static void getOne(){
         if(one == null){
               one new One();
             }
     }

 private One(){ // private constructor
    //construct stuff
 }

 }

 This way if there is an instance of One already
 you cannot make another One.

 This was good for me in Java because I found
 that when clicking a JTable for some reason the
 Thread goes through the event listener method
 twice.

 The Singleton pattern solved this problem for
 me.


 Phill.




 "imr1984" <imr1984_member pathlink.com> wrote in message
 news:bu0da8$1qic$1 digitaldaemon.com...

 Often programmers make classes that are only intended to have



















 instance

 for

 the duration of the whole program. These are called singleton













 D

 should

 have built in support for them so that a singleton object will
















 its

 own

 methods generated for it, without the use of a this pointer.



















 would

 save on

 a this parameter being pushed on stack to a singleton class
















 Walter, what da ya say?
Jan 17 2004
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Unfortunately that sprinkles code to create a new T all over your program,
whereever it is used.

C++ sucks.

Sean

"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one instance, when
 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }
Jan 22 2004
parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bup6kr$2rv5$1 digitaldaemon.com...

 Unfortunately that sprinkles code to create a new T all over your program,
 whereever it is used.

 C++ sucks.



It's the implementation that sucks, not the language protocol. The language
does not say that each time a template declaration is created, a new class
is compiled. It may well have been one class throughout the compiling
process, as long as the type is the same.

I don't see why D should be litterred with such petite details as
singletons, when the language itself offers the most elegant mechanism for
it.


 Sean

 "Achilleas Margaritis" <axilmar b-online.gr> wrote in message
 news:bu21hi$1h9a$1 digitaldaemon.com...

 The best solution is to define a template which creates one instance,







 this instance is requested. For example:

 template <class T> class Singleton {
     private T *_object;
     T *object() {
         if (_object == null) _object = new T();
         return _object;
     }
 }
Jan 24 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
The best solution is to define a template which creates one instance, when
this instance is requested. For example:

template <class T> class Singleton {
    private T *_object;
    T *object() {
        if (_object == null) _object = new T();
        return _object;
    }
}



What's that? It isn't D, not C++ nor Java, nor C#. What is it?
Jan 22 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bup8jt$2vb8$1 digitaldaemon.com...

The best solution is to define a template which creates one instance,







this instance is requested. For example:

template <class T> class Singleton {
    private T *_object;
    T *object() {
        if (_object == null) _object = new T();
        return _object;
    }
}



 What's that? It isn't D, not C++ nor Java, nor C#. What is it?



It's D-T, the pseudo-code for D templates that a lot of us poor inculcated
C++ template chappies use. Seems not in the least noteworthy to me.
Jan 23 2004
prev sibling parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
Pseudo C/D/Java/C#!!!

"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bup8jt$2vb8$1 digitaldaemon.com...

The best solution is to define a template which creates one instance,







this instance is requested. For example:

template <class T> class Singleton {
    private T *_object;
    T *object() {
        if (_object == null) _object = new T();
        return _object;
    }
}



 What's that? It isn't D, not C++ nor Java, nor C#. What is it?
Jan 24 2004