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