I was mistaken. Mr. Glassborow kindly informed me of the existence of
"self-cloning" which allows "MyObject x = x;" to use the implicit copy
constructor.

Andrew R. Thomas-Cramer wrote in message <7qmn6b$jc5@newsops.execpc.com>...
>Preventing creation requires a private _default_ constructor, undefined,
>with no other constructors declared for the class.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <D7VlSCAfa4z3Ew$x@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:

[snip]
>         X x=x;  // construction by self cloning, a quirk of the language
> // strictly speaking it exhibits undefined behaviour but in practice the
> // only undesired behaviour is that it works:)

I thought the language was changed (since the ARM) so the declaration of x
wasn't visible until after its initialization, which would plug this
loophole, keep from even having this situation, as well as allow other
useful constructs (for example, hiding a non-const value with a const ref
to it, i.e.

    Foo foo;

    {
        Foo const& foo( foo );
        // foo is const
    }
)

Am I mistaken?

[snip]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Preventing creation requires a private _default_ constructor, undefined,
with no other constructors declared for the class.

Francis Glassborow wrote in message ...
>
>Not only is there no need, you can even prevent such creation by
>declaring and not defining a private copy ctor.  It is one way of
>implementing a singleton pattern.
>
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper Jr. wrote in message <37CB2488.95D17A0A@wizard.net>...
>blargg wrote:
>....
>> For static data members, they are *not* necessarily created before any
>> objects of the class are created.

>3.6.2 p3: "... the initialization ... shall occur before the first use
>of any function or object defined in the same translation unit as the
>object to be initialized."

Others have mentioned the problem that statement has with regard to cycles.


Your quote only applies to initializations which occur after main() is
entered.  If a function is used before main() is entered there is no
guarantee that objects in its file will have been initialized.

>Therefore, all you have to do to guarantee that the static members will
>be initialized before any objects of the class are created, is to define
>them in the same translation unit as the constructors for that class.


and insure that none of your class's constructors are called before main().
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

postmast.root.admi.gov@iname.com (blargg) writes:

>In article <D7VlSCAfa4z3Ew$x@robinton.demon.co.uk>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>
>[snip]
>>         X x=x;  // construction by self cloning, a quirk of the language
>> // strictly speaking it exhibits undefined behaviour but in practice the
>> // only undesired behaviour is that it works:)
>
>I thought the language was changed (since the ARM) so the declaration of x
>wasn't visible until after its initialization,

I think you are mistaken.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37f70d24.148511182@nntp.ix.netcom.com>, David Harmon
<source@netcom.com> writes
>On 31 Aug 99 05:44:30 GMT in comp.std.c++, "James Kuyper Jr."
><kuyper@wizard.net> wrote:
>
>>Therefore, all you have to do to guarantee that the static members will
>>be initialized before any objects of the class are created, is to define
>>them in the same translation unit as the constructors for that class.
>
>I don't get it.  Suppose class A has a static member of type class B.
>Class B has a static member of type class A.  How do you get both static
>members each created before the other one?

If it matters, you have a circular dependency.  That is your problem,
not the compilers :)


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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qmn6b$jc5@newsops.execpc.com>, Andrew R. Thomas-Cramer
<artc@prism-cs.com> writes
>Preventing creation requires a private _default_ constructor, undefined,
>with no other constructors declared for the class.

This is a commonly held misconception.  I warn you that you will hate
this but:

class X {
int i_m)
X();
public:
        void set(int i){i_m = i;}
        int get(){return i_m;}
};

int main(){
        X x=x;  // construction by self cloning, a quirk of the language
// strictly speaking it exhibits undefined behaviour but in practice the
// only undesired behaviour is that it works:)
        x.set(1);
        cout << x.get();
        return 0;
}

Compiles and does what you expect.  Declaring a default ctor (or any
ctor that is not a copy ctor) does not inhibit the compiler generating a
copy ctor.  Declaring any ctor (including a copy ctor) prevents the
compiler generating a default ctor.

Unfortunately many books get this wrong and most experts forget it
sometimes.


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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Aug 99 05:44:30 GMT in comp.std.c++, "James Kuyper Jr."
<kuyper@wizard.net> wrote:

>Therefore, all you have to do to guarantee that the static members will
>be initialized before any objects of the class are created, is to define
>them in the same translation unit as the constructors for that class.

I don't get it.  Suppose class A has a static member of type class B.
Class B has a static member of type class A.  How do you get both static
members each created before the other one?



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37f70d24.148511182@nntp.ix.netcom.com>, source@netcom.com
(David Harmon) wrote:

> On 31 Aug 99 05:44:30 GMT in comp.std.c++, "James Kuyper Jr."
> <kuyper@wizard.net> wrote:
>
> >Therefore, all you have to do to guarantee that the static members will
> >be initialized before any objects of the class are created, is to define
> >them in the same translation unit as the constructors for that class.
>
> I don't get it.  Suppose class A has a static member of type class B.
> Class B has a static member of type class A.  How do you get both static
> members each created before the other one?

Yep. I don't care what the standard says, because it's an intractable
problem in general. Plus, I don't think the standard even guarantees what
James mentioned, without this impossible situation. I can come up with
some complex initializations that are solvable, but would require much
more compiler/linker smarts than is reasonable. Consider


// a.cpp

    extern void (*f)();
    extern void f1();

    int a = ((f = f1, 0);

// b.cpp

    extern void f2();
    void (*f)();

    int b = ((f ? f() : f2()), 0);

// d.cpp

    int* dp = new int;

    void f1() {
        assert( dp );
    }

// e.cpp

    int* ep = new int;

    void f2() {
        assert( ep );
    }


Depending on the order of initialization, when static initialization is
performed for b.cpp, f will either be 0 or point to f1. In initializing b,
a call to f1 or f2 will be made. This means that the static
initializations for d.cpp and e.cpp will need to have been performed
already. I don't see how a compiler could be smart enough to determine
that the initialization of b in b.cpp may require static initialization
for d.cpp to already have been performed if it happens to perform static
initialization for a.cpp before b.cpp. I suppose it could perform static
initialization on the first function call for a module, but the
performance overhead of this could be significant - either there is some
sort of flag checked for a function call, or it relies on a virtual memory
hook when the code is loaded from disk. I can't imagine the standard
requiring either of these.

If this example is solved easily by current compilers (which I highly
doubt), for example, by considering a directed acyclic graph of
dependencies between entities in the modules, we could just add some
cyclic dependences that don't turn out to be cyclic at run-time
(preventing infinite recursion).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37C9E513.43FD@despam.pangea.ca>, Harvey Taylor
<het@despam.pangea.ca> writes
>Hi Folks,
>       This might seem odd, but...
>       If you have a class which has only static data
>       and static member functions, is it necessary
>       to bother creating an instance of the class?
><curious>
>-het

Not only is there no need, you can even prevent such creation by
declaring and not defining a private copy ctor.  It is one way of
implementing a singleton pattern.


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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qduga$k0m$1@nnrp1.deja.com>, wmm@fastdial.net wrote:

> In article <37C9E513.43FD@despam.pangea.ca>,
>   Harvey Taylor <het@despam.pangea.ca> wrote:
> > Hi Folks,
> >       This might seem odd, but...
> >       If you have a class which has only static data
> >       and static member functions, is it necessary
> >       to bother creating an instance of the class?
>
> No.  Static members are completely independent of any instance and
> exist before any instances are created and after any instances are
> destroyed.

Well, for static function members, of course they always exist (when I
first read your statement, it sounded odd until I realized the poster
asked about static data members as well :-)

For static data members, they are *not* necessarily created before any
objects of the class are created.

    class Y {
    public:
        int i;
        Y() : i( 1 ) { }
    };

    class X {
        static Y y;
    public:
        X();
    };

    X x;

    Y X::y;

    X::X() {
        assert( y.i == 1 ); // *will* fail
    }

    int main() { }

This isn't specific to static members of classes, but it does invalidate
your statement about static data members' lifetimes surrounding the
lifetimes of any objects of the class, and could be a surprise to someone
naively expecting this to be the case.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 30 Aug 99 12:49:12 GMT in comp.std.c++, wmm@fastdial.net wrote:

>No.  Static members are completely independent of any instance and
>exist before any instances are created and after any instances are
>destroyed.

I think that is mistaken.  For static members that are defined in one
compile unit, and static instances that are defined in a different
compile unit, there can be no guarantee about which is created first,
right?



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg wrote:
....
> For static data members, they are *not* necessarily created before any
> objects of the class are created.

9.4.2 p7: "Static data members are initialized and destroyed exactly
like non-local objects (3.6.2, 3.6.3)"

3.6.2 p3: "... the initialization ... shall occur before the first use
of any function or object defined in the same translation unit as the
object to be initialized."

Therefore, all you have to do to guarantee that the static members will
be initialized before any objects of the class are created, is to define
them in the same translation unit as the constructors for that class.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37def511.76801531@nntp.ix.netcom.com>,
  source@netcom.com (David Harmon) wrote:
>
> On 30 Aug 99 12:49:12 GMT in comp.std.c++, wmm@fastdial.net wrote:
>
> >No.  Static members are completely independent of any instance and
> >exist before any instances are created and after any instances are
> >destroyed.
>
> I think that is mistaken.  For static members that are defined in one
> compile unit, and static instances that are defined in a different
> compile unit, there can be no guarantee about which is created first,
> right?

That's true.  I was addressing the original poster's concern about
whether it was necessary to have an instance of a class in order to
access its static members, and I overstated the answer in a way that
ignored the indeterminacy of order of static initialization in
different compilation units.  Mea culpa.

What I intended to say was that, even if you never create an object
of a class, or if all auto and heap objects of that class have been
destroyed, the static members of the class exist and can be used,
subject to constraints of order of static initialization.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi Folks,
 This might seem odd, but...
 If you have a class which has only static data
 and static member functions, is it necessary
 to bother creating an instance of the class?
<curious>
-het

--
 "There are beings in the universe billions of years older than us
  and we have as much chance of communicating with them
  as we do with an ant." - G'Kar

 Harvey Taylor         Internet: het@despam.portal.ca
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Harvey Taylor wrote:
>
> Hi Folks,
>         This might seem odd, but...
>         If you have a class which has only static data
>         and static member functions, is it necessary
>         to bother creating an instance of the class?
> <curious>
> -het

Nothing requires you to ever bother creating an instance of any class.
It is true that you can use the static members without having an actual
instance. However, if all the members are static, you might be better
off using a namespace  rather than a class.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37C9E513.43FD@despam.pangea.ca>, Harvey Taylor
<het@despam.pangea.ca> wrote:

> This might seem odd, but...
> If you have a class which has only static data
> and static member functions, is it necessary
> to bother creating an instance of the class?

If you want an object of the class, create one. If you don't, don't. Am I
missing something?

    class X {
    public:
        static void f();
    };

If you want an X, make one:

    X x;

If you don't, don't. Static functions of a class don't operate on an object:

    X::f();

They can also be called as a member of an object, though the effect the same:

    X x;

    x.f();

Before namespaces, people would make static functions of a class to
simulate namespaces. This still has some uses that namespaces don't
provide. Friendship can be given to a whole class, and static helper
functions can be put into it. This can be more convenient than naming a
bunch of individual functions:

// file "X.h"

    class X {
        int i;
        struct Impl;
        friend struct Impl;
    public:
        // ...
    };

// file "X.cpp"

    struct X::Impl {
        // can access member i of X objects
        static int get_i( X const& x ) { return x.i; }
    };

Other examples of class protection, name injection, and friends combined
with classes with only static functions can be constructed.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37C9E513.43FD@despam.pangea.ca>,
  Harvey Taylor <het@despam.pangea.ca> wrote:
> Hi Folks,
>  This might seem odd, but...
>  If you have a class which has only static data
>  and static member functions, is it necessary
>  to bother creating an instance of the class?

No.  Static members are completely independent of any instance and
exist before any instances are created and after any instances are
destroyed.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]