Copy construction with inaccessible base class copy c-tor

Discussion in 'C++' started by Victor Bazarov, Feb 27, 2007.

  1. Hello,

    Take a look at this program:
    -----------------------------------
    class B
    {
    B(const B&);
    B& operator=(const B&);
    public:
    B(int);
    };

    class C : public B
    {
    public:
    C(int);
    };

    int main()
    {
    C c = C(42); // Comeau: no error
    B b = B(42); // Comeau: error
    }

    -----------------------------------
    Both 'c' and 'b' are copy-constructed, as I understand it.
    B's copy c-tor is inaccessible, so construction of 'b' is
    ill-formed. And Comeau (online test drive) flags it such.
    But it lets the construction of 'c' through. Should it?

    As I understand it, a temporary can be omitted, but its
    creation should be possible (12.2/1) as if it weren't omitted.
    And since C's copy c-tor cannot be created (12.8/7), the code
    that requires (or would require) it is also ill-formed.
    Where do I err? Or do I?

    Thanks!

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Victor Bazarov, Feb 27, 2007
    #1
    1. Advertising

  2. Victor Bazarov

    Arun Guest

    Hello,

    On Feb 26, 9:35 pm, "Victor Bazarov" <> wrote:
    > Hello,
    >
    > Take a look at this program:
    > -----------------------------------
    > class B
    > {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    >
    > };
    >
    > class C : public B
    > {
    > public:
    > C(int);
    >
    > };
    >
    > int main()
    > {
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    >
    > }
    >
    > -----------------------------------
    > Both 'c' and 'b' are copy-constructed, as I understand it.


    If everything were right the copy constructor would be called.

    > B's copy c-tor is inaccessible, so construction of 'b' is
    > ill-formed. And Comeau (online test drive) flags it such.


    yes. b cannot be copy constructed.

    > But it lets the construction of 'c' through. Should it?
    >


    NO. c cannot be copy constructed as well. Compiler shall not generate
    a copy constructor as the base class copy constructor is private.
    SO this is an error too.

    > As I understand it, a temporary can be omitted, but its
    > creation should be possible (12.2/1) as if it weren't omitted.
    > And since C's copy c-tor cannot be created (12.8/7), the code
    > that requires (or would require) it is also ill-formed.
    > Where do I err? Or do I?
    >
    > Thanks!
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Arun, Feb 27, 2007
    #2
    1. Advertising

  3. Victor Bazarov

    Ian Collins Guest

    Victor Bazarov wrote:
    > Hello,
    >
    > Take a look at this program:
    > -----------------------------------
    > class B
    > {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    > };
    >
    > class C : public B
    > {
    > public:
    > C(int);
    > };
    >
    > int main()
    > {
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    > }
    >
    > -----------------------------------
    > Both 'c' and 'b' are copy-constructed, as I understand it.
    > B's copy c-tor is inaccessible, so construction of 'b' is
    > ill-formed. And Comeau (online test drive) flags it such.
    > But it lets the construction of 'c' through. Should it?
    >

    Sounds logical. gcc rejects both lines, Sun CC only barfs on C c = C(42);

    --
    Ian Collins.

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Ian Collins, Feb 27, 2007
    #3
  4. On Feb 27, 3:35 am, "Victor Bazarov" <> wrote:
    [...]
    > class B {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    > };
    >
    > class C : public B {
    > public:
    > C(int);
    > };
    >
    > int main() {
    > C c = C(42); // Comeau: no error
    > }

    [...]
    > As I understand it, a temporary can be omitted, but its
    > creation should be possible (12.2/1) as if it weren't omitted.
    > And since C's copy c-tor cannot be created (12.8/7), the code
    > that requires (or would require) it is also ill-formed.
    > Where do I err? Or do I?


    I believe you're right. To me 12.8-7 appears quite clear on the
    subject: The copy constructor is defined even if it's use is elided
    and as it has an inaccessible base class copy constructor, the program
    is ill-formed.

    Cheers,
    Nicola Musatti


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Nicola Musatti, Feb 27, 2007
    #4
  5. Victor Bazarov

    Craig Scott Guest

    On Feb 27, 1:35 pm, "Victor Bazarov" <> wrote:
    > Hello,
    >
    > Take a look at this program:
    > -----------------------------------
    > class B
    > {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    >
    > };
    >
    > class C : public B
    > {
    > public:
    > C(int);
    >
    > };
    >
    > int main()
    > {
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    >
    > }
    >
    > -----------------------------------
    > Both 'c' and 'b' are copy-constructed, as I understand it.
    > B's copy c-tor is inaccessible, so construction of 'b' is
    > ill-formed. And Comeau (online test drive) flags it such.
    > But it lets the construction of 'c' through. Should it?
    >
    > As I understand it, a temporary can be omitted, but its
    > creation should be possible (12.2/1) as if it weren't omitted.
    > And since C's copy c-tor cannot be created (12.8/7), the code
    > that requires (or would require) it is also ill-formed.
    > Where do I err? Or do I?


    To my reading, section 12.8.7 (which you mention) is very clear on
    this point:

    "A program is illformed if the class for which a copy constructor is
    implicitly defined has ... a base class with an inaccessible or
    ambiguous copy constructor."

    This is exactly your situation, since C has an implicit copy
    constructor and the copy constructor in its base, B, is inaccessible.
    If there is any confusion about whether the copy constructor or the
    assignment operator is being used, the assignment operator is subject
    to the same restriction (see 12.8.12) and would make the example ill
    formed for the same reasons. Thus, any discussion about whether the
    compiler is allowed to by-pass the assignment operator and use the
    copy constructor instead should reach the same conclusion. For
    reference, 12.8.15 discusses how the compiler is allowed to by-pass
    the assignment and directly copy-construct in-place, but it should be
    noted that it does not *require* an implementation to do that.

    --
    Computational Fluid Dynamics, CSIRO (CMIS)
    Melbourne, Australia


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Craig Scott, Feb 27, 2007
    #5
  6. Victor Bazarov

    Kai-Uwe Bux Guest

    Victor Bazarov wrote:

    > Hello,
    >
    > Take a look at this program:
    > -----------------------------------
    > class B
    > {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    > };
    >
    > class C : public B
    > {
    > public:
    > C(int);
    > };
    >
    > int main()
    > {
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    > }
    >
    > -----------------------------------
    > Both 'c' and 'b' are copy-constructed, as I understand it.
    > B's copy c-tor is inaccessible, so construction of 'b' is
    > ill-formed. And Comeau (online test drive) flags it such.
    > But it lets the construction of 'c' through. Should it?
    >
    > As I understand it, a temporary can be omitted, but its
    > creation should be possible (12.2/1) as if it weren't omitted.
    > And since C's copy c-tor cannot be created (12.8/7), the code
    > that requires (or would require) it is also ill-formed.
    > Where do I err? Or do I?


    You are quite correct. I think this is a bug in Comeau. If I am not
    mistaken, a similar (maybe the same) bug already appeared about a year ago
    on this list:

    http://groups.google.com/group/comp.lang.c /browse_frm/thread/a455c59346fecc7c/5ddba796ee5478f5


    Best

    Kai-Uwe Bux

    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Kai-Uwe Bux, Feb 28, 2007
    #6
  7. Victor Bazarov

    Old Wolf Guest

    On Feb 27, 3:35 pm, "Victor Bazarov" <> wrote:
    > class B
    > {
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    >
    > };
    >
    > class C : public B
    > {
    > public:
    > C(int);
    >
    > };
    >
    > int main()
    > {
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    > }


    The compiler should generate an error because you haven't provided
    a body for the constructor of C. I'm assuming that either the
    compiler stopped when it got the error on the B line, or it did
    generate the error but you failed to report it.

    AFAIK the C++ standard only says that compilers must generate a
    diagnostic for particular erroneous code, and you reported that
    a diagnostic was generated, so the behaviour is conforming. The
    standard doesn't require that multiple diagnostics be produced,
    even if there are multiple errors.

    Try adding in bodies for all functions, and taking out the 'B' line
    and see if you get an error. (If there is still no error, it would
    be interesting to add further code to see how the compiler is
    constructing the B part of the C object).


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Old Wolf, Mar 1, 2007
    #7
  8. Victor Bazarov

    James Kanze Guest

    On Mar 1, 8:55 am, "Old Wolf" <> wrote:
    > On Feb 27, 3:35 pm, "Victor Bazarov" <> wrote:


    > > class B
    > > {
    > > B(const B&);
    > > B& operator=(const B&);
    > > public:
    > > B(int);
    > > };


    > > class C : public B
    > > {
    > > public:
    > > C(int);
    > > };


    > > int main()
    > > {
    > > C c = C(42); // Comeau: no error
    > > B b = B(42); // Comeau: error
    > > }


    > The compiler should generate an error because you haven't provided
    > a body for the constructor of C.


    That's undefined behavior, not an error requiring a diagnostic.
    Most implementations will only detect it when linking, and of
    course, he never got that far.

    [...]
    > Try adding in bodies for all functions, and taking out the 'B' line
    > and see if you get an error. (If there is still no error, it would
    > be interesting to add further code to see how the compiler is
    > constructing the B part of the C object).


    The error is, of course, that an accessible copy constructor is
    required, but that the compiler cannot generate one for C,
    because there isn't one for B. There is no requirement that the
    copy constructor actually be called, however, and I know of no
    compiler that will call it.

    What is doubtlessly occuring is that the Comeau compiler sees
    that it can generate the declaration for the copy constructor
    for C, and doesn't go any further, since it doesn't actually
    need the definition. (The standard makes it clear, however,
    that it is a diagnosible error if the compiler is unable to
    generate the definition, even if it doesn't use it.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    James Kanze, Mar 1, 2007
    #8
  9. On 1 Mrz., 13:59, "James Kanze" <> wrote:
    > That's undefined behavior, not an error requiring a diagnostic.
    > Most implementations will only detect it when linking, and of
    > course, he never got that far.


    That's an interesting position, I never realized that. Does that mean,
    that essentially every C++ program more or less relies on this kind
    of UB? Even the standard provides class definitions, where
    some of the usual suspects (copy c'tor, assignment op)
    are declared but not defined, e.g. (I take N2134 as reference):

    20.5.14.2:
    // 20.5.14.2.6, undefined operators:
    template<class Function2> bool operator==(const function<Function2>&);
    template<class Function2> bool operator!=(const function<Function2>&);

    22.1.1.1.2:
    facet(const facet&); // not defined
    void operator=(const facet&); // not defined

    22.1.1.1.3:
    void operator=(const id&); // not defined
    id(const id&); // not defined

    27.4.4:
    basic_ios(const basic_ios& ); // not defined
    basic_ios& operator=(const basic_ios&); // not defined

    27.6.1.1.2:
    sentry(const sentry&); // not defined
    sentry& operator=(const sentry&); // not defined

    27.6.2.3:
    sentry(const sentry&); // not defined
    sentry& operator=(const sentry&); // not defined

    Of course one can argue that the standard is allowed to demand
    that and library writers have to ensure it's realization, but that
    seems
    somewhat unsatisfactory to me.

    Is this one of the implicite rules or explicitely spoken out?
    (I haven't searched yet)

    Greetings,

    Daniel





    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    =?iso-8859-1?q?Daniel_Kr=FCgler?=, Mar 1, 2007
    #9
  10. Victor Bazarov

    Guest

    What about this ?
    -------------------------
    class B
    {
    protected:
    B(const B&);
    B& operator=(const B&);
    public:
    B(int);
    };
    class C : public B
    {
    public:
    C(int);
    };
    int main()
    {
    C c = C(42); //
    B b = B(42); //
    }
    ------------------------
    copy ctor of base class is set to protected.


    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    , Mar 1, 2007
    #10
  11. wrote:
    > What about this ?
    > -------------------------
    > class B
    > {
    > protected:
    > B(const B&);
    > B& operator=(const B&);
    > public:
    > B(int);
    > };
    > class C : public B
    > {
    > public:
    > C(int);
    > };
    > int main()
    > {
    > C c = C(42); //
    > B b = B(42); //
    > }
    > ------------------------
    > copy ctor of base class is set to protected.


    The construction of 'c' should compile, the construction of
    'b' should not, IMO. 'C' has an implicit copy c-tor, which
    calls the explicit copy c-tor for 'B', which it can do because
    the protected access is granted to 'C'.

    The construction of 'b' should NOT compile because it involves
    making a copy of the temporary, and 'main' has no access to the
    protected copy c-tor in 'B'.

    I can see the correct behaviour in Comeau, but I have no way of
    verifying this with GNU C++ at this time.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask



    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Victor Bazarov, Mar 1, 2007
    #11
  12. On Mar 1, 4:03 pm, "Daniel Krügler" <>
    wrote:
    > On 1 Mrz., 13:59, "James Kanze" <> wrote:
    >
    > > That's undefined behavior, not an error requiring a diagnostic.
    > > Most implementations will only detect it when linking, and of
    > > course, he never got that far.

    >
    > That's an interesting position, I never realized that. Does that mean,
    > that essentially every C++ program more or less relies on this kind
    > of UB? Even the standard provides class definitions, where
    > some of the usual suspects (copy c'tor, assignment op)
    > are declared but not defined, e.g. (I take N2134 as reference):
    >
    > 20.5.14.2:
    > // 20.5.14.2.6, undefined operators:
    > template<class Function2> bool operator==(const function<Function2>&);
    > template<class Function2> bool operator!=(const function<Function2>&);


    I'm not sure whether I misunderstood James or you did. Just to be
    sure, in my opinion the following invokes undefined behaviour:

    class A {
    public:
    A();
    };

    class B : public A {
    };

    int main() {
    B b;
    }

    A compiler might be able to generate a definition for B::B(), however
    this would contain a call to A::A() which cannot be resolved by the
    linker. This not very different from the following program:

    void f();

    int main() {
    f();
    }

    The following, instead, is downright malformed:

    class C {
    private:
    C();
    };

    class D : public C {
    };

    int main() {
    D d;
    }

    The compiler is not allowed to generate a definition for D::D()
    because C::C() is not accessible. In a way malformation kicks in
    before undefined behaviour does.

    Cheers,
    Nicola Musatti



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Nicola Musatti, Mar 1, 2007
    #12
  13. On 1 Mrz., 18:56, "Nicola Musatti" <> wrote:
    > I'm not sure whether I misunderstood James or you did. Just to be
    > sure, in my opinion the following invokes undefined behaviour:


    I'm quite sure that you didn't misunderstood James. Don't ask me why,
    but I got totally lost in an arcane idea.
    Fact is, as you correctly said, that an inaccessible and not defined
    class member is (normally) harmless, because access rules apply before
    the compiler has finished. What I indeed never consciously realised,
    (but this was not what I meant in my previous posting) was that an
    used but undefined entity (e.g. usual function or function member)
    causes UB, most probably because I always relied on the linker to
    recognize such situations. What I want to say is, that according to
    the outcome of this discussion even

    class T {
    T(); // not defined;
    public:
    static void foo() {
    T item;
    }
    };

    int main() {
    T::foo();
    }

    or even simpler

    void foo(); // not defined

    int main() {
    foo();
    }

    causes UB. I assume that this surprising result
    (at least for me) is related to the fact that the
    C++ standard does not describe a linker model.
    The existence of the linker and the occurence of
    a linker error here and there seems so natural
    for most of us that I never considered its cause
    to be a programmers fault which actually belongs
    to the UB family.

    Greetings from Bremen,

    Daniel Krügler



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    =?iso-8859-1?q?Daniel_Kr=FCgler?=, Mar 2, 2007
    #13
  14. Victor Bazarov

    James Kanze Guest

    On Mar 1, 4:03 pm, "Daniel Krügler" <>
    wrote:
    > On 1 Mrz., 13:59, "James Kanze" <> wrote:


    > > That's undefined behavior, not an error requiring a diagnostic.
    > > Most implementations will only detect it when linking, and of
    > > course, he never got that far.


    > That's an interesting position, I never realized that. Does that mean,
    > that essentially every C++ program more or less relies on this kind
    > of UB? Even the standard provides class definitions, where
    > some of the usual suspects (copy c'tor, assignment op)
    > are declared but not defined, e.g. (I take N2134 as reference):


    I'm afraid I wasn't very clear. Old Wolf said "The compiler
    should generate an error because you haven't provided a body for
    the constructor of C." That's really the only statement I'm
    responding to; not providing bodies (or providing multiple
    bodies) to a function that is actually used is a violation of
    the one definition rule, and as such is undefined behavior.
    (Not providing bodies to a function which is not actually used
    is perfectly legal. Applying the standard's definition of
    "used", i.e. virtual functions are always used, as is a user
    declared operator delete, and maybe some other special cases.)

    The original code requires a diagnostic (and will require one
    even if bodies are provided for all of the user defined
    functions) because the compiler is required to generated the
    definition of the implicite copy constructor, and can't.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    James Kanze, Mar 3, 2007
    #14
  15. Victor Bazarov

    James Kanze Guest

    On Mar 2, 12:28 pm, "Daniel Krügler" <>
    wrote:
    > On 1 Mrz., 18:56, "Nicola Musatti" <> wrote:


    > > I'm not sure whether I misunderstood James or you did. Just to be
    > > sure, in my opinion the following invokes undefined behaviour:


    > I'm quite sure that you didn't misunderstood James. Don't ask me why,
    > but I got totally lost in an arcane idea.


    When I reread my statement, I got confused by it myself, so the
    problem is on my side.

    > Fact is, as you correctly said, that an inaccessible and not defined
    > class member is (normally) harmless, because access rules apply before
    > the compiler has finished. What I indeed never consciously realised,
    > (but this was not what I meant in my previous posting) was that an
    > used but undefined entity (e.g. usual function or function member)
    > causes UB, most probably because I always relied on the linker to
    > recognize such situations. What I want to say is, that according to
    > the outcome of this discussion even


    > class T {
    > T(); // not defined;
    > public:
    > static void foo() {
    > T item;
    > }
    > };


    > int main() {
    > T::foo();
    >
    > }


    > or even simpler


    > void foo(); // not defined


    > int main() {
    > foo();
    >
    > }


    > causes UB.


    That's correct. In practice, in this particular case, you will
    certainly get an error from the linker (although I once used a
    linker, many, many years ago, that would occasionally use the
    address 0, rather than reporting an undefined external).

    > I assume that this surprising result
    > (at least for me) is related to the fact that the
    > C++ standard does not describe a linker model.
    > The existence of the linker and the occurence of
    > a linker error here and there seems so natural
    > for most of us that I never considered its cause
    > to be a programmers fault which actually belongs
    > to the UB family.


    I think that the real reason is that this is part of a larger
    rule, the one definition rule, and there are some violations of
    this rule which are not easily detected. If, for example,
    instead of providing no definition, you provide two, and you
    link through libraries. It wouldn't be too difficult for the
    standard to require a diagnostic in the case of a missing
    definition; it may not describe the exact linker model, but it
    does talk about resolving external symbols, and such, in the
    phases of compilation. It's probably not worth addressing now,
    however; hopefully, the next version of the standard will
    contain some support for dynamic linking, and then, you do sort
    of get undefined behavior.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



    --
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    James Kanze, Mar 3, 2007
    #15
  16. Victor Bazarov

    Greg Comeau Guest

    In article <ervn2p$as5$>,
    Victor Bazarov <> wrote:
    >class B
    >{
    > B(const B&);
    > B& operator=(const B&);
    >public:
    > B(int);
    >};
    >
    >class C : public B
    >{
    >public:
    > C(int);
    >};
    >
    >int main()
    >{
    > C c = C(42); // Comeau: no error
    > B b = B(42); // Comeau: error
    >}
    >
    >Both 'c' and 'b' are copy-constructed, as I understand it.
    >B's copy c-tor is inaccessible, so construction of 'b' is
    >ill-formed. And Comeau (online test drive) flags it such.
    >But it lets the construction of 'c' through. Should it?
    >
    >As I understand it, a temporary can be omitted, but its
    >creation should be possible (12.2/1) as if it weren't omitted.
    >And since C's copy c-tor cannot be created (12.8/7), the code
    >that requires (or would require) it is also ill-formed.
    >Where do I err? Or do I?


    Sorry for the delay in responding. I started mulling it and
    got caught up in other things. I don't think you err:
    The standard seems pretty clear that it needs to be accessible
    in your context, even if it can be sidestepped regarding its "need".

    Kanze seems to have the answer I would have provided (thanks James:)
    It's a more deeper issue internally and as with all reports
    it will be given consideration at some point.
    --
    Greg Comeau / 20 years of Comeauity! Intel Mac Port now in beta!
    Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
    World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
    Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
     
    Greg Comeau, Mar 4, 2007
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    653
    codigo
    May 4, 2005
  2. Ook
    Replies:
    10
    Views:
    558
  3. Replies:
    2
    Views:
    4,082
  4. Stefan Weber
    Replies:
    9
    Views:
    419
    Stefan Weber
    May 29, 2007
  5. Stefan Weber
    Replies:
    2
    Views:
    420
    Howard
    May 22, 2007
Loading...

Share This Page