Is the following code legal?

Discussion in 'C++' started by Kiuhnm, Mar 18, 2006.

  1. Kiuhnm

    Kiuhnm Guest

    #include <new>

    class T
    {
    };

    int main()
    {
    T t = t;
    T u(u);
    T v;
    new (&v) T(v);
    }

    Kiuhnm
    Kiuhnm, Mar 18, 2006
    #1
    1. Advertising

  2. Kiuhnm

    Ben Pope Guest

    Kiuhnm wrote:
    > #include <new>
    >
    > class T
    > {
    > };
    >
    > int main()
    > {
    > T t = t;
    > T u(u);
    > T v;
    > new (&v) T(v);
    > }
    >
    > Kiuhnm


    Have you tried compiling this?

    Does you compiler give you errors?

    Why do you think that is?

    What do you expect each line to do?

    Ben Pope
    --
    I'm not just a number. To many, I'm known as a string...
    Ben Pope, Mar 18, 2006
    #2
    1. Advertising

  3. Kiuhnm

    Kiuhnm Guest

    Ben Pope ha scritto:
    > Have you tried compiling this?


    Yes, but it is irrelevant. How can I be sure that my compiler is
    completely standard-compliant?

    > What do you expect each line to do?


    It is irrelevant.
    All I would like to know is whether the code, according to the standard,
    produces a defined behavior or not.

    Kiuhnm
    Kiuhnm, Mar 18, 2006
    #3
  4. Kiuhnm

    Rolf Magnus Guest

    Kiuhnm wrote:

    > Ben Pope ha scritto:
    >> Have you tried compiling this?

    >
    > Yes, but it is irrelevant. How can I be sure that my compiler is
    > completely standard-compliant?


    You can't.

    >> What do you expect each line to do?

    >
    > It is irrelevant.
    > All I would like to know is whether the code, according to the standard,
    > produces a defined behavior or not.


    Not.
    Rolf Magnus, Mar 18, 2006
    #4
  5. Kiuhnm

    Daniel T. Guest

    In article <441c7580$0$18296$>,
    Kiuhnm <"kiuhnm03["@]yahoo.it> wrote:

    > Ben Pope ha scritto:
    > > Have you tried compiling this?

    >
    > Yes, but it is irrelevant. How can I be sure that my compiler is
    > completely standard-compliant?
    >
    > > What do you expect each line to do?

    >
    > It is irrelevant.
    > All I would like to know is whether the code, according to the standard,
    > produces a defined behavior or not.


    T t = t;
    T u(u);

    The above two lines will compile but the behavior is undefined.


    T v;
    new (&v) T(v);

    The above two lines produce defined behavior.

    Please, why do you ask?


    --
    Magic depends on tradition and belief. It does not welcome observation,
    nor does it profit by experiment. On the other hand, science is based
    on experience; it is open to correction by observation and experiment.
    Daniel T., Mar 18, 2006
    #5
  6. Kiuhnm

    Kiuhnm Guest

    Rolf Magnus ha scritto:
    > Not.


    Why?
    I read 3.3.1 and 3.8 in the c++ iso, but that did not clarify my doubts.

    Kiuhnm
    Kiuhnm, Mar 18, 2006
    #6
  7. Kiuhnm

    Kiuhnm Guest

    Daniel T. ha scritto:
    > T t = t;
    > T u(u);
    >
    > The above two lines will compile but the behavior is undefined.


    And what about
    int x = x;
    ?

    > Please, why do you ask?


    I am just curious.

    Kiuhnm
    Kiuhnm, Mar 18, 2006
    #7
  8. Kiuhnm" <"kiuhnm03[ wrote:
    > Daniel T. ha scritto:
    >> T t = t;
    >> T u(u);
    >>
    >> The above two lines will compile but the behavior is undefined.

    >
    > And what about
    > int x = x;
    > ?


    What's the difference from

    T t = t;

    do you see here?

    V
    --
    Please remove capital As from my address when replying by mail
    Victor Bazarov, Mar 19, 2006
    #8
  9. Kiuhnm wrote:
    > #include <new>
    >
    > class T
    > {
    > };
    >
    > int main()
    > {
    > T t = t;
    > T u(u);
    > T v;
    > new (&v) T(v);
    > }


    What is your particular question anyway? What do you suspect to be
    illegal and why? The obvious violation is double construction of an
    object which is illegal. However, you put other stuff into the
    article, too, which might indicate that you are actually looking for
    other sources of "illegal code".
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.eai-systems.com> - Efficient Artificial Intelligence
    Dietmar Kuehl, Mar 19, 2006
    #9
  10. Kiuhnm

    AnalogFile Guest

    Dietmar Kuehl wrote:
    > Kiuhnm wrote:
    >> #include <new>
    >>
    >> class T
    >> {
    >> };
    >>
    >> int main()
    >> {
    >> T t = t;
    >> T u(u);
    >> T v;
    >> new (&v) T(v);
    >> }

    >
    > What is your particular question anyway?


    He is asking because we have been discussing that in our national C++
    newsgroup but did not come to a definitive conclusion.

    There are more variations on the same theme and they may or may not
    change the validity of those constructs.

    > What do you suspect to be
    > illegal and why?


    It depends who you ask to. If we had any consensus we would not even ask.

    For as much as we can say the placement new construct is perfectly defined.

    That is:

    void foo()
    {
    class T {} v;
    new (&v) T(v);
    }

    is perfectly legal.

    > The obvious violation is double construction of an
    > object which is illegal.


    Not. The standard does not say you cannot construct twice. And does not
    guarantee that the number of constructions matches the number of
    destructions. If you reuse the memory of a live object, that object
    lifetime ends without the construction being called and it is explicitly
    legal to do so. See 3.8#4

    > However, you put other stuff into the
    > article, too, which might indicate that you are actually looking for
    > other sources of "illegal code".


    In fact 3.8 is no help in the other cases.

    We know that

    struct T {
    void *p;
    T(){}
    T(T*pp){ p=pp; if (pp==this) cout << "wow!\n"; }
    };

    void foo()
    {
    T t=&t;
    T u(&u);
    }

    is perfectly defined (see 3.3.1#1 and 3.8#5)

    But the wording in 3.8, specifically the first item of the list in
    3.8#5, together with 3.8#1 seem to imply that

    struct T {
    int i;
    T(){}
    T(const T&r){i=r.i;}
    };

    void foo()
    {
    T t=t;
    T u(u);
    }

    is undefined behavior (cannot access r.i until the lifetime has begun,
    and that happens at the end of the constructor).

    And this is apparently incongruous with the fact that

    void foo()
    {
    int i=i;
    int j(j);
    }

    is perfectly valid as in 3.3.1#1
    AnalogFile, Mar 19, 2006
    #10
  11. Kiuhnm

    Kiuhnm Guest

    Victor Bazarov ha scritto:
    > What's the difference from
    >
    > T t = t;
    >
    > do you see here?


    T may not be a built-in type.

    Anyway, my question was subtler than you think:
    excerpt from c++ iso/iec 14882:
    >>>

    3.3.1 Point of declaration

    The /point of declaration/ for a name is immediately after its complete
    declarator (clause 8) and before its /initializer/ (if any), except as
    noted below.
    [Example:

    int x = 12;
    { int x = x; }

    Here the second x is initialized with its own (indeterminate) value.]
    <<<

    Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
    cannot format your hard disk).

    Kiuhnm
    Kiuhnm, Mar 19, 2006
    #11
  12. * Kiuhnm:
    > Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
    > cannot format your hard disk).


    Using an indeterminate value, for anything, is formally UB.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 19, 2006
    #12
  13. Kiuhnm

    Rolf Magnus Guest

    Kiuhnm wrote:

    > Victor Bazarov ha scritto:
    >> What's the difference from
    >>
    >> T t = t;
    >>
    >> do you see here?

    >
    > T may not be a built-in type.
    >
    > Anyway, my question was subtler than you think:
    > excerpt from c++ iso/iec 14882:
    > >>>

    > 3.3.1 Point of declaration
    >
    > The /point of declaration/ for a name is immediately after its complete
    > declarator (clause 8) and before its /initializer/ (if any), except as
    > noted below.
    > [Example:
    >
    > int x = 12;
    > { int x = x; }
    >
    > Here the second x is initialized with its own (indeterminate) value.]
    > <<<
    >
    > Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
    > cannot format your hard disk).


    It doesn't say that. It just says that, when the right hand side is
    evaluated, the name 'x' already exists. It doesn't say anything about the
    behavior of initializing x with an indeterminate value.
    Rolf Magnus, Mar 19, 2006
    #13
  14. Kiuhnm

    Kiuhnm Guest

    Rolf Magnus ha scritto:
    > It doesn't say that. It just says that, when the right hand side is
    > evaluated, the name 'x' already exists. It doesn't say anything about the
    > behavior of initializing x with an indeterminate value.


    3.3.1#1:
    "[...]Here the second x is initialized with its own (indeterminate) value."

    Kiuhnm
    Kiuhnm, Mar 19, 2006
    #14
  15. Kiuhnm

    Kiuhnm Guest

    Alf P. Steinbach ha scritto:
    > * Kiuhnm:
    >
    >> Then "int x = x;" is /not/ undefined (e.g. a standard-compliant
    >> compiler cannot format your hard disk).

    >
    >
    > Using an indeterminate value, for anything, is formally UB.


    I am just copying it (we cannot overload operator= for built-in types).

    Kiuhnm
    Kiuhnm, Mar 19, 2006
    #15
  16. Kiuhnm

    Kiuhnm Guest

    Kiuhnm ha scritto:
    > I am just copying it (we cannot overload operator= for built-in types).


    Please, forget "overload". I meant "provide a user-defined".

    Kiuhnm
    Kiuhnm, Mar 19, 2006
    #16
  17. * Kiuhnm:
    > Alf P. Steinbach ha scritto:
    >> * Kiuhnm:
    >>
    >>> Then "int x = x;" is /not/ undefined (e.g. a standard-compliant
    >>> compiler cannot format your hard disk).

    >>
    >>
    >> Using an indeterminate value, for anything, is formally UB.

    >
    > I am just copying it (we cannot overload operator= for built-in types).


    Formally, that's using it.


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Mar 19, 2006
    #17
  18. Kiuhnm

    Kai-Uwe Bux Guest

    Alf P. Steinbach wrote:

    > * Kiuhnm:
    >> Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
    >> cannot format your hard disk).

    >
    > Using an indeterminate value, for anything, is formally UB.


    I did a search for "indeterminate" in my electronic version of the standard,
    and I did not find a statement to that extend. I would be grateful for
    chapter and verse.

    It appears that almost all uses (and most definitely all interesting uses)
    of indeterminate values lead to undefined behavior per the catch all clause
    in [1.3.12]: "Undefined behavior may also be expected when this
    International Standard omits the description of any explicit definition of
    behavior." However, one could argue that in the case of

    int x = x;

    the standard actually provides an explicit definition of behavior, namely
    that the variable x is initialized in such a way that its value after
    initialization is undefined.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 19, 2006
    #18
  19. Kiuhnm

    Rolf Magnus Guest

    Kiuhnm wrote:

    > Rolf Magnus ha scritto:
    >> It doesn't say that. It just says that, when the right hand side is
    >> evaluated, the name 'x' already exists. It doesn't say anything about the
    >> behavior of initializing x with an indeterminate value.

    >
    > 3.3.1#1:
    > "[...]Here the second x is initialized with its own (indeterminate)
    > value."


    And again, it doesn't say that initializing it with an indeterminate value
    is legal, just that it is done here, because x is known before it is
    initializied, so the name can be used for the initializer.
    Rolf Magnus, Mar 19, 2006
    #19
  20. Kiuhnm

    AnalogFile Guest

    Alf P. Steinbach wrote:
    > * Kiuhnm:
    >> Then "int x = x;" is /not/ undefined (e.g. a standard-compliant
    >> compiler cannot format your hard disk).

    >
    > Using an indeterminate value, for anything, is formally UB.
    >


    Can you point me to where in the standard it says so?

    AFAIK it is defined behavior (with indeterminate result) for every POD
    type except when dereferencing a pointer.
    AnalogFile, Mar 19, 2006
    #20
    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. bluke

    Is the following legal?

    bluke, May 17, 2004, in forum: Java
    Replies:
    5
    Views:
    414
    John C. Bollinger
    May 18, 2004
  2. Chris Johnson
    Replies:
    3
    Views:
    433
    C Johnson
    Aug 14, 2003
  3. SenderX
    Replies:
    7
    Views:
    366
    Greg Comeau
    Aug 29, 2003
  4. Ed J

    Is this legal code?

    Ed J, Jun 16, 2004, in forum: C++
    Replies:
    3
    Views:
    543
  5. DavidNorep
    Replies:
    0
    Views:
    101
    DavidNorep
    May 6, 2007
Loading...

Share This Page