virtual class not work?
Tony Wu
time), so I put dimension n and Border of each dimension in a class BASS;
and define class POINT for each n dimension data; further more, define
Minolta operation in class Cluster. Both point and cluster class inheritance
from virtual class bass, because they all need dimension n member, and I
only want one BASS.
But when I test it, I found there are many copy of class BASS.
Can you help me! If I just want one object of BASS, how can I do it?
class bass {
public:
int dimension;
float* upBorder;
float* downBorder;
};
class point :virtual public bass {
private:
float* dot;
point* next;
public:
point(float* in) {
dot=new float[dimension];
for(int i=0;i<dimension;i++)
dot[i]=in[i];
}
};
class cluster:virtual public bass {
private:
point* points; file://a lot of points
public:
operation(){
for(int i=0;i<dimension;i++)
file://do some operations;
}
};
void main() {
cluster object;
object.operation();
}
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
John Harrison
Tony Wu <wc...@hotmail.com> wrote in message
news:80fftr$ohu$1...@newsflash.concordia.ca...
You misunderstand the purpose of virtual inheritance, in code such as the
following
class A {};
class B : public virtual A {};
class C : public virtual A {};
class D : public B, public C {};
without virtual inheritance a D object would have two A objects. With
virtual inheritance it has only one. However it is still the case that every
D object has its own seperate A object.
However if you want one bass object which is accessable by all your other
objects why not declare a global variable or constant?
John
Francis Glassborow
<wc...@hotmail.com> writes
>I have a project involving in manipulate n dimension data ( n decided =
in run
>time), so I put dimension n and Border of each dimension in a class =
BASS;
>and define class POINT for each n dimension data; further more, define
inheritance
>from virtual class bass, because they all need dimension n member, and =
I
>only want one BASS.
>But when I test it, I found there are many copy of class BASS.
it?
Maybe I am being particularly stupid but I do not understand the above
and your source code seems to be very deficient in design. IOWs I am
having difficulty with both your natural language and your programming
language material.
Certainly virtual bases will do nothing for you in the way you use them.
They are about inheritance, but cluster and point are related by
containment.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Joerg Barfurth
> Maybe I am being particularly stupid but I do not understand the above
> and your source code seems to be very deficient in design. IOWs I am
> having difficulty with both your natural language and your programming
> language material.
>
>
> Certainly virtual bases will do nothing for you in the way you use them.
> They are about inheritance, but cluster and point are related by
> containment.
He needed a singleton. And he misunderstood virtual inheritance,
assuming it would provide just that: Only one object of the virtual base
class _globally_, instead of one per most derived object.
-- Jörg
Paul Whitehead
>
[snipped a load of code]
> However if you want one bass object which is accessable by all your other
> objects why not declare a global variable or constant?
Aaargh! Maybe I'm being a little hasty, here, but I find global
variables far too much trouble...
There is a *nice* solution to this problem: use the Singleton design
pattern. This is described in the "Design Patterns" book by Gamma et al.
I've also put something up on codeguru some time ago about the
implementation in that book: http://www.codeguru.comm/cpp_mfc. I can't
remember the exact page names but I'm in the section near the bottom on
Singletons.
HTH, Paul.
Jim Gewin
>
> John Harrison wrote:
> >
> [snipped a load of code]
> > However if you want one bass object which is accessable by all your other
> > objects why not declare a global variable or constant?
>
> Aaargh! Maybe I'm being a little hasty, here, but I find global
> variables far too much trouble...
>
> There is a *nice* solution to this problem: use the Singleton design
> pattern. This is described in the "Design Patterns" book by Gamma et al.
> I've also put something up on codeguru some time ago about the
> implementation in that book: http://www.codeguru.comm/cpp_mfc. I can't
> remember the exact page names but I'm in the section near the bottom on
> Singletons.
>
> HTH, Paul.
>
Can you explain how a singleton differs from a global
variable? I don't see much of a difference, but you
apparently do (Aargh! vs *nice*).
J.Barfurth
Jim Gewin <jge...@worldnet.att.net> schrieb in im Newsbeitrag:
87n1sbc...@pineapple.fnet.net...
> Can you explain how a singleton differs from a global
> variable? I don't see much of a difference, but you
> apparently do (Aargh! vs *nice*).
1. It keeps the respective namespace clean. If you use globals with external
linkage outside anonymous namespaces, you have more opportunity to break the
one definition rule.
2. If it is supposed to be a singleton that means that there must be at most
(or exactly) one instance of the class at any given time. This is a class
invariant which the class should enforce. If you use globals, the 'structors
of the class must be public, so you cannot prevent multiple instances at
compile time.
3.You get better extensibility: Behind the scenes a singleton class can be
modified to actually deliver an object of a derived class selected at
runtime (or at compile-time, if that is what you need). With global
variables the type of the variable is fixed (unless you take special
precautions).
4. You have better control over lifetime. By using initialization-on-demand
you can avoid instantiating an object which is never used. You also can
avoid problems with initialization order. With extra care you can avoid
problems with destruction order.
Just to name a few...
--Jörg Barfurth
Jim Gewin
I didn't mean to ask what the difference is between a global object
and a singleton type; I know very well what it is. What I wanted to
know is why every time someone mentions a global object (one that's
available to all functions in all translation units, whether it's
in the global namespace or not), the reply is something like "Ugh!
use a Singleton."
I agree with the "Ugh!" part, of course, for all the reasons that
instigated the research that led to object oriented languages.
What I don't see is how the singleton object, however implemented,
is any less open to abuse than a global object. Why would it be
any better to prefer a) over b) in the snippet below:
a) Singleton_stream::instance( ) << "Hello, world!";
b) std::clog << "Hello, world!";
I truly don't get it, but I must be missing something. Why does
the Singleton suggestion get thrown out every time someone has a
design that includes a global object?
merl...@my-deja.com
<jge...@worldnet.att.net> wrote:
[ snippage re: the goodness of the Singleton pattern ]
> I truly don't get it, but I must be missing something. Why does
> the Singleton suggestion get thrown out every time someone has a
> design that includes a global object?
I obviously can't speak for everyone, but I've been burned so many times
by global POD variables that my reflexive reaction to *any* global with
uncontrolled access is "Ugh!" Global objects that don't support
assignment aren't *quite* as bad (you don't have to worry that Norman
Newguy's code will overwrite the global object with his local object),
but all the things mentioned by Herr Barfurth still apply.
--
Edmund Schweppe aka merl...@my-deja.com
Blissfully free of official positions
Sent via Deja.com http://www.deja.com/
Before you buy.
Joerg Barfurth
> "J.Barfurth" <tech...@bfk-net.de> writes:
> > Jim Gewin <jge...@worldnet.att.net> schrieb in im Newsbeitrag:
> > 87n1sbc...@pineapple.fnet.net...
> >
> > > Can you explain how a singleton differs from a global
> > > variable? I don't see much of a difference, but you
> > > apparently do (Aargh! vs *nice*).
> > 1. It keeps the respective namespace clean. If you use globals with external
...
> > 2. If it is supposed to be a singleton that means that there must be at most
> > (or exactly) one instance of the class at any given time. This is a class
> > invariant which the class should enforce. If you use globals, the 'structors
...
> > 3.You get better extensibility: Behind the scenes a singleton class can be
> > modified to actually deliver an object of a derived class selected at
...
> > 4. You have better control over lifetime. By using initialization-on-demand
...
> > Just to name a few...
> I didn't mean to ask what the difference is between a global object
> and a singleton type; I know very well what it is. What I wanted to
> know is why every time someone mentions a global object (one that's
> available to all functions in all translation units, whether it's
> in the global namespace or not), the reply is something like "Ugh!
> use a Singleton."
Now, if you look back at your question, it seems as though you asked
what you didn't mean...
Personally I wouldn't jump at *every* use of a global, nor would I
always suggest using a singleton.
In this case though, the OP specifically asked for one:
OP> ... I only want one BASS.
OP> But when I test it, I found there are many copy of class BASS.
Basically it is a question of saying what you mean:
- If there ought to be at most one object of a class, make it a
singleton. (See 2. above)
Otherwise, if there ought to be any object with static storage duration,
ask yourself "Why ? Where does this design requirement originate ?"
- From a single function: Make it a block-scoped static if possible
- From a local implementation detail: Make it a global in an anonymous
namespace.
- From the needs of a single class: Make it a static member.
- From the needs of a single module/component/subsystem: Make it a
global in the module's (implementation) namespace. Do not declare it in
a public header file.
- From global needs (cannot be attributed to any of the above): What is
wrong with your design ? [As a last resort use a global]
If compilation dependencies matter or polymorphic use semms possible,
instead of a global object use a global reference. To export that global
from it's originating context, I'd usally use an accessor function. If
that really is too much or too inefficient I#d try a global reference.
It's all about encapsulation and coupling. We have to deal with those at
every level, not only at class scope. So there will be a scope where it
is appropriate to have the object fully available, as an implementation
detail. Beyond that scope we shouldn't expose the same level of detail.
Publically declaring an external object we fully expose its dynamic type
and force all client code to #include the definition of that type.
> I agree with the "Ugh!" part, of course, for all the reasons that
> instigated the research that led to object oriented languages.
> What I don't see is how the singleton object, however implemented,
> is any less open to abuse than a global object. Why would it be
> any better to prefer a) over b) in the snippet below:
>
> a) Singleton_stream::instance( ) << "Hello, world!";
>
> b) std::clog << "Hello, world!";
I'd prefer
std::stdio::log << "Hello world";
or
std::stdio::log() << "Hello world";
or evn
std::stdio().log() << "Hello world";
Whether std::stdio would be a function, a class or just a nested
namespace needs further analysis. To give an implementation more liberty
in implementing this, 'log' might be (1) an ostream& or (2) a function
returning ostream&.
But of course the istream already adds another level of indirection. As
changes specific to standard in- and output will probably done in a
special stdio_streambuf and its supporting infrastructure (for
initialization etc.) the use of a global seems ok in this case. Moreover
namespace std is mostly closed for change by mere mortals :-)
Of course the comittee also had to accomodate the existing code base.
> I truly don't get it, but I must be missing something. Why does
> the Singleton suggestion get thrown out every time someone has a
> design that includes a global object?
The singleton suggestion is (or should be) thrown out whenever there is
a need for one (and only one) object of a kind. When there are problems
with static initialization order, it is often mentioned as a classic
case for initialization-on-demand. For other uses of global objects I
wouldn't suggest singleton. But most of the time there is a better (more
self-documenting) way to achieve the same goal than putting a global
object up for grabs like "here it is, use it as you like".
When I see a global I don't say "Ugh!" but "Why?".
-- Jörg Barfurth
Jim Gewin
jbar...@vossnet.de (Joerg Barfurth) writes:
> Jim Gewin <jge...@worldnet.att.net> wrote:
>
> [snipped]
> always suggest using a singleton.
> In this case though, the OP specifically asked for one:
> OP> ... I only want one BASS.
> OP> But when I test it, I found there are many copy of class BASS.
>
> Basically it is a question of saying what you mean:
> - If there ought to be at most one object of a class, make it a
> singleton. (See 2. above)
>
> Otherwise, if there ought to be any object with static storage duration,
> ask yourself "Why ? Where does this design requirement originate ?"
> - From a single function: Make it a block-scoped static if possible
> - From a local implementation detail: Make it a global in an anonymous
> namespace.
> - From the needs of a single class: Make it a static member.
> - From the needs of a single module/component/subsystem: Make it a
> global in the module's (implementation) namespace. Do not declare it in
> a public header file.
> - From global needs (cannot be attributed to any of the above): What is
> wrong with your design ? [As a last resort use a global]
>
> a need for one (and only one) object of a kind. When there are problems
> with static initialization order, it is often mentioned as a classic
> case for initialization-on-demand. For other uses of global objects I
> wouldn't suggest singleton. But most of the time there is a better (more
> self-documenting) way to achieve the same goal than putting a global
> object up for grabs like "here it is, use it as you like".
>
> When I see a global I don't say "Ugh!" but "Why?".
>
> -- Jörg Barfurth
Thanks for the explanation, Jorg. I apparently missed the
part of the original post in which the author complained
that he was getting too many BASS objects, so I asked my
question in an inappropriate thread.
As for the global object and the "Ugh!" reaction, I'm with
Edmund: I've seen them abused so much that I do have that
reaction.
I'm still curious why I've seen the singleton-to-replace-
global-object suggestion so many times. A writable single-
ton reference is no less vulnerable to his Norman Newguy
than a global. But this isn't the forum for that question,
so I'll drop it.
Thanks again.
Wakeley Purple
(snip)
> Why would it be
>any better to prefer a) over b) in the snippet below:
>
> a) Singleton_stream::instance( ) << "Hello, world!";
>
> b) std::clog << "Hello, world!";
You're right. But std::clog seems to me to be a good model of the Singleton
pattern, and that reinforces the argument that global objects are usually best
implemented as Singletons.
David Bradley
> a) Singleton_stream::instance( ) << "Hello, world!";
>
> b) std::clog << "Hello, world!";
>
> the Singleton suggestion get thrown out every time someone has a
> design that includes a global object?
Personally I've never cared much for the Singleton pattern mechanism. I
prefer a template approach where you wrap your class in a template that acts
as a smart pointer. This approach makes it easy for the user and you don't
have to keep writing all those static member functions. The Singleton
template would have a similar interface to std::auto_ptr. Unfortunately I
don't have access to my source for Singleton. I believe CUJ or C++ Report
had a similar article.
class MyListInstance
{
....
}
typedef Singleton<MyListInstance> GlobalList;
void foo(Item const & i_Item)
{
GlobalList aList; // This will instantiate a single instance of
MyListInstance if needed
aList->AddItem(i_Item);
// Or
GlobalList()->AddItem(i_Item);
Jim Gewin
wa...@iglou.com (Wakeley Purple) writes:
>
> jge...@worldnet.att.net says
>
> (snip)
>
> > Why would it be
> >any better to prefer a) over b) in the snippet below:
> >
> >
> > b) std::clog << "Hello, world!";
>
> pattern, and that reinforces the argument that global objects are usually best
> implemented as Singletons.
>
Surely not clog. Isn't it the same type as cout, which would
preclude using a singleton?
If I have to expose an object globally, I'm quite likely to
want more than one of a given type, again precluding using
a singleton:
extern sig_atomic_t abort_flag = 0;
extern sig_atomic_t alarm_flag = 0;
extern sig_atomic_t child_flag = 0;
or
extern Event_queue receive_queue( 100 );
extern Event_queue process_queue( 100 );
extern Event_queue transmit_queue( 100 );