In article <iPYD8.7558$T_.174285@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>> But here, in the line:
>>     typeid(p) clone(*p);
>> which you want to be equivalent to:
>>     char buf[typeid(p).size()];
>>     new (buf) typeid(p)(*p);
>> don't you get into the question of C99 variable arrays?
...
>My concern was only about the efficiency.
...
>But for the sake of orthogonality
>if we start allowing typeid(p) in some places where typename is expected,
>it is better to allow it in all such places.

I leave to the experts on C99 variable arrays to decide whether this is
useful, cause problems in a C++ implementation etc.

The discussion with alloca(), revealed that it was difficult to put it
into the C++ paradigm, wrapping it up in some classes. -- I have no good
intuition about your suggestion: It could well be that it should serve as
the alloca() replacement in C++, if investigated properly. Or it might not
turn out to be useful. -- I cannot tell which extreme might be right.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <abpvr2$2lj$1@mulga.cs.mu.OZ.AU>, fjh@cs.mu.OZ.AU (Fergus
Henderson) wrote:
>>-- For C++, those C99 variable arrays is whole another issue: The reason
>>it was added to C is that C does not have the high-level language
>>constructs that C++ has.
>
>I think you are vastly oversimplifying here.
>That may have been one factor in the decision,
>but it was certainly not the only one and
>IMHO it was not the most important one.

See reply to Leo in the same thread:

I leave it to experts on C99 variables arrays to consider. One idea that
comes to my mind is that his suggestion might serve as a replacement for
alloca in C++ (assuming the arrays get their allocation on the parameter
stack).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <xgZC8.7494$T_.170421@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>> In the runtime picture I work with, one just has various objects of which
>> some are clonable and others are not. They are polymorphic, meaning that
>> any object can be referenced by any variable. There is an interesting
>> feature where one, by optimization squeezes an object into an old
>> allocation, but that is handed transparently by the polymorphy system, and
>> not related to the current question.
>
>Ok, here is an example:
>
>void foo(Base * p) {
>
>        // This is what we're discussing and agree on usefulness
>        Base * clone = new typeid(p)(*p);
>
>        // This is what I propose to add as well
>        typeid(p) clone(*p);
>
>        // Which is equivalent (modulo alignment) to
>        char buf[typeid(p).size()];
>        new (buf) typeid(p)(*p);
>
>        ...
>
>        delete (buf) (Base*)buf;
>}
>
>which is *supposed to be* more efficient than using heap allocation.

But here, in the line:
    typeid(p) clone(*p);
which you want to be equivalent to:
    char buf[typeid(p).size()];
    new (buf) typeid(p)(*p);
don't you get into the question of C99 variable arrays?

-- For C++, those C99 variable arrays is whole another issue: The reason
it was added to C is that C does not have the high-level language
constructs that C++ has. The reason one might want to add it to C++ is not
efficiency, but compatibility with C.

As for my own use, I built a user class (call it say Data) which maintains
a pointer to objects in the polymorphic class hierarchy. Actually, I ended
up with a set of different pointers in a union (plus a type enum), where
the pointer can be to various function pointers or a handle
(pointer-to-a-pointer). Then an evaluator runs through this stuff and
determines the correct evaluation. As a primitive GC (garbage collector),
I use a reference count system.

To the user, both using the class Data, and those implementing new classes
in the polymorphic hierarchy, ideally, the exact details of how this is
set up is irrelevant. C++ cannot go fully on this now (which is why I
switched to a Flex/Bison system generating a parser writing C++ classes).
But the ideal is that those programmer users should not need to know
anything about that particular setup.

Thus, your ideas will be hidden away anyway in a properly setup C++
polymorphic system.

So therefore, I would not myself be interested in it (I have your
suggestion correctly), as I have no need of it, even though I do not
object to if others have a use of it (and if compiler writers do not find
it difficult to implement, it does not cause overheads when this rarely
needed feature is not usable, etc.).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

>>Ok, here is an example:
>>
>>void foo(Base * p) {
>>
>>        // This is what we're discussing and agree on usefulness
>>        Base * clone = new typeid(p)(*p);
>>
>>        // This is what I propose to add as well
>>        typeid(p) clone(*p);
>>
>>        // Which is equivalent (modulo alignment) to
>>        char buf[typeid(p).size()];
>>        new (buf) typeid(p)(*p);
>>
>>        ...
>>
>>        delete (buf) (Base*)buf;
>>}
>>
>>which is *supposed to be* more efficient than using heap allocation.

> But here, in the line:
>     typeid(p) clone(*p);
> which you want to be equivalent to:
>     char buf[typeid(p).size()];
>     new (buf) typeid(p)(*p);
> don't you get into the question of C99 variable arrays?

> -- For C++, those C99 variable arrays is whole another issue: The reason
> it was added to C is that C does not have the high-level language
> constructs that C++ has. The reason one might want to add it to C++ is not
> efficiency, but compatibility with C.

My concern was only about the efficiency. If the implementation of
variable-sized arrays in C99, when incorporated into C++0x, allows
heap-based, as opposed to stack-based, allocation for such arrays,
then the point is moot and auto_ptr<Base*> clone = new typeid(p)(*p)
would do, because clone will point to the heap one way or another.

But for the sake of orthogonality
if we start allowing typeid(p) in some places where typename is expected,
it is better to allow it in all such places.

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In reply to xleobx@qmailcomq.com,
remove.haberg@matematik.su.se (Hans Aberg) writes:

>But here, in the line:
>    typeid(p) clone(*p);
>which you want to be equivalent to:
>    char buf[typeid(p).size()];
>    new (buf) typeid(p)(*p);
>don't you get into the question of C99 variable arrays?
>
>-- For C++, those C99 variable arrays is whole another issue: The reason
>it was added to C is that C does not have the high-level language
>constructs that C++ has.

I think you are vastly oversimplifying here.
That may have been one factor in the decision,
but it was certainly not the only one and
IMHO it was not the most important one.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

>>> I am not sure what you mean here: When cloning, differently derived
>>> objects will have different size, so the will not fit into the automatic
>>> variables. So one has to work with references or pointer. (Usually one
>>
>>Is the art of computing the stack frame size before grabbing the frame
>>lost completely? And what are we going to do with placement new?

> In the runtime picture I work with, one just has various objects of which
> some are clonable and others are not. They are polymorphic, meaning that
> any object can be referenced by any variable. There is an interesting
> feature where one, by optimization squeezes an object into an old
> allocation, but that is handed transparently by the polymorphy system, and
> not related to the current question.

Ok, here is an example:

void foo(Base * p) {

 // This is what we're discussing and agree on usefulness
 Base * clone = new typeid(p)(*p);

 // This is what I propose to add as well
 typeid(p) clone(*p);

 // Which is equivalent (modulo alignment) to
 char buf[typeid(p).size()];
 new (buf) typeid(p)(*p);

 ...

 delete (buf) (Base*)buf;
}

which is *supposed to be* more efficient than using heap allocation.

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Fq_z8.7301$T_.163019@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>There may be cloning into an automatic variable as well; no need to
>tie memory allocation and construction together:

I am not sure what you mean here: When cloning, differently derived
objects will have different size, so the will not fit into the automatic
variables. So one has to work with references or pointer. (Usually one
creates an automatic variable that maintains a pointer to the polymorphic
hierarchy that is doing the cloning.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Alexander Terekhov <terekhov@web.de> wrote:

>> > Actually, one can go one step beyond to say that
>> >     new typeid(*this)(*this)
>> > is the C++ name of the clone operator. -- It leads to essentially the same
>> > implementation as adding the clone operator separately.
>>
>> There may be cloning into an automatic variable as well; no need to
>> tie memory allocation and construction together:
>>
>> void foo(const root & r) {
>>         typeid(root) temp(root);
>>         ...
>> }
>>
>> Or, with simpler syntax
>>
>> void foo(const root & r) {
>>         // Why isn't type_info::size() in the standard?
>>         char _buf[typeid(root).size()]; // C99
>>         new (_buf) typeid(root)(root);
>>         ...
>> }

> How about alignment (in the "simpler syntax" piece, I mean)?

Oops. Which leads to a question: where are alignof(T) and type_info::align()?
(Oh boy, isn't C++ _severely_ lacking? :-) )

double _buf[(typeid(root).size() + sizeof(double) - 1) / sizeof(double)];

AFAIR, there cannot be a type with "stricter than double"
alignment requirements (no standard at hand).

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
> In article <Fq_z8.7301$T_.163019@iad-read.news.verio.net>,
> xleobx@qmailcomq.com wrote:
>>There may be cloning into an automatic variable as well; no need to
>>tie memory allocation and construction together:

> I am not sure what you mean here: When cloning, differently derived
> objects will have different size, so the will not fit into the automatic
> variables. So one has to work with references or pointer. (Usually one

Is the art of computing the stack frame size before grabbing the frame
lost completely? And what are we going to do with placement new?

> creates an automatic variable that maintains a pointer to the polymorphic
> hierarchy that is doing the cloning.

How do variable-sized arrays work in C99/will work in C++0x?

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 3 May 2002 xleobx@qmailcomq.com wrote:

> How do variable-sized arrays work in C99/will work in C++0x?

In C90 and in C++, the size of an auto array must be an
integral-constant-expression (basically, a compile-time
constant).

In C99, the restiction is removed. The size of an auto array
can be dynamically determined:

extern int j;
void g(int k)
{
 int x[j][k]; // ok in C99
}

Nobody can predict what will be in C++0X, because the C++
Committee is only now starting to decide on the criteria
to be used to select new or changed features in C++0X.
No features have been decided, and won't be for some years.

The Committee wants to make C++0X as compatible as possible
with C99, however, so it's a pretty good bet that C99
features that don't conflict with C++ will be introduced
in a compatible way.

---
Steve Clamage, stephen.clamage@sun.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
> In article <iR1z8.7218$T_.160317@iad-read.news.verio.net>,
> xleobx@qmailcomq.com wrote:
>>>>class root {
>>>>        public:
>>>>        // does not need to be virtual
>>>>        root* clone() const {
>>>>                return new typeid(*this)(*this); // future_std
>>>>        }
>>>>};

> Actually, one can go one step beyond to say that
>     new typeid(*this)(*this)
> is the C++ name of the clone operator. -- It leads to essentially the same
> implementation as adding the clone operator separately.

There may be cloning into an automatic variable as well; no need to
tie memory allocation and construction together:

void foo(const root & r) {
 typeid(root) temp(root);
 ...
}

Or, with simpler syntax

void foo(const root & r) {
 // Why isn't type_info::size() in the standard?
 char _buf[typeid(root).size()]; // C99
 new (_buf) typeid(root)(root);
 ...
}

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
>
> Hans Aberg <remove.haberg@matematik.su.se> wrote:
> > In article <iR1z8.7218$T_.160317@iad-read.news.verio.net>,
> > xleobx@qmailcomq.com wrote:
> >>>>class root {
> >>>>        public:
> >>>>        // does not need to be virtual
> >>>>        root* clone() const {
> >>>>                return new typeid(*this)(*this); // future_std
> >>>>        }
> >>>>};
>
> > Actually, one can go one step beyond to say that
> >     new typeid(*this)(*this)
> > is the C++ name of the clone operator. -- It leads to essentially the same
> > implementation as adding the clone operator separately.
>
> There may be cloning into an automatic variable as well; no need to
> tie memory allocation and construction together:
>
> void foo(const root & r) {
>         typeid(root) temp(root);
>         ...
> }
>
> Or, with simpler syntax
>
> void foo(const root & r) {
>         // Why isn't type_info::size() in the standard?
>         char _buf[typeid(root).size()]; // C99
>         new (_buf) typeid(root)(root);
>         ...
> }

How about alignment (in the "simpler syntax" piece, I mean)?

regards,
alexander.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <gPiA8.7322$T_.163875@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>> I am not sure what you mean here: When cloning, differently derived
>> objects will have different size, so the will not fit into the automatic
>> variables. So one has to work with references or pointer. (Usually one
>
>Is the art of computing the stack frame size before grabbing the frame
>lost completely? And what are we going to do with placement new?

In the runtime picture I work with, one just has various objects of which
some are clonable and others are not. They are polymorphic, meaning that
any object can be referenced by any variable. There is an interesting
feature where one, by optimization squeezes an object into an old
allocation, but that is handed transparently by the polymorphy system, and
not related to the current question.

>> creates an automatic variable that maintains a pointer to the polymorphic
>> hierarchy that is doing the cloning.
>
>How do variable-sized arrays work in C99/will work in C++0x?

This does not seem to be related to the question at hand: Under C++, for
polymorphy, use a class like std::vector, which can be given the needed
structure in order to handle runtime questions.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <iR1z8.7218$T_.160317@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>>>class root {
>>>        public:
>>>        // does not need to be virtual
>>>        root* clone() const {
>>>                return new typeid(*this)(*this); // future_std
>>>        }
>>>};
>>>
>>>I do not see unsurmountable implementation problems.
>
>> My guess is that it does not work: The runtime system needs to make a
>
>NB: typeid, not typeof.

I misread: This is a suggestion for extension of the C++ standard of
yours, right? -- I thought you said it would work in the current C++
standard.

>Exactly, and the type_info object can be made to provide all necessary info.

Then one needs to think of what is needed in the implementation of a C++
compiler in order for this to work:

The function "new X(x)" is currently not on the virtual lookup table (or
so I recall). So it needs to be put there.

Then your idea will work. Seems simple enough.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey <daniel.frey@aixigo.de> wrote:
>>
>> > In the context of template macros, one might implement for example the
>> > clone function by the use of such a this_type:
>> >   class root {
>> >   public
>> >     virtual this_type* clone() const { return new this_type(*this); }
>> >   };
>>
>> How about this:
>>
>> #include <typeinfo>
>>
>> class root {
>>         public:
>>         // does not need to be virtual
>>         root* clone() const {
>>                 return new typeid(*this)(*this); // future_std
>>         }
>> };

> I'd call this class 'cloneable' instead of 'root', but still a nice
> idea. One thing I don't like about the second solution is that typeid(
> *this ) will be runtime-code, not compile-time-code, therefore I'd

It has to be a runtime code, ehtier in a form of a virtual
function call, or in a form of RTTI access.

> prefer Hans solution. Also, I can't fully understand how typeid( *this
> )( *this ) should work. The second *this is of type root, therefore I

Suppose that type_info has the size information, and
that the constructors are "virtualized". Basically, what you ask for
is a virtual copy constructor, isn't it? operator new has what it needs
to know, and the proper constructor is called.

> think there needs to be a cast of some kind. Or will typeid( *this )
> accept a void*? The return type is also not the best solution I could

No, typeid(*this) returns the proper magic type std::type_info,
whose operator() evaluates as the constructor for the denoted type.
The copy ctors for the derived types will have to accept a reference to root
and static_cast (or dynamic_cast, if paranoid) that reference to
the proper type. So the compiler will have to provide the very basic
generic support, finally making copy-style constructors virtualizeable,
as they should have been from the beginning.

> think of. Anyway, it would be nice to have a clone() available :)

clone(), transform(), transmogrify() and many more will be possible.

Another way to express the same would be

root* clone() const {
 return new virtual root(*this);
}

And, as you stated, returning root * is not good. With virtual
functions you can have covariant return types; covariance is
specified by declaring derived class members; it should also be
possible to declare a covariant non-virtual function:

class root {
public:
 future_std_covariant root * clone() const { ... }
};
class trunk : public root;
....
trunk t;

Now t.clone() will be compiled as static_cast<trunk*>(t.clone());
( or, in paranoia debug mode, as dynamic_cast<trunk*>(t.clone()); )

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <iR1z8.7218$T_.160317@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>>>class root {
>>>        public:
>>>        // does not need to be virtual
>>>        root* clone() const {
>>>                return new typeid(*this)(*this); // future_std
>>>        }
>>>};

Actually, one can go one step beyond to say that
    new typeid(*this)(*this)
is the C++ name of the clone operator. -- It leads to essentially the same
implementation as adding the clone operator separately.

The C++ standard then needs to be augmented with a statement to the effect
that each polymorphic C++ class X should have the functions
    new X(const X&)
    new X(X&)
added to the runtime virtual lookup table, so that these functions can be
accessed via the type_info class (which typeid() returns reference to).

Classes X that do not have one of the constructors X(const X&), X(X&)
should cause the corresponding "new" function to throw an exception.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

> In the context of template macros, one might implement for example the
> clone function by the use of such a this_type:
>   class root {
>   public
>     virtual this_type* clone() const { return new this_type(*this); }
>   };

> The idea is here that clone() should behave not as a single function
> instantiation, but also that derived classes should get one, i.e., the
> class
>   class my_class : public virtual root {
>     ...
>   };
> should get an instantiation of
>   virtual my_class* clone() const { return new my_class(*this); }

How about this:

#include <typeinfo>

class root {
 public:
 // does not need to be virtual
 root* clone() const {
  return new typeid(*this)(*this); // future_std
 }
};

I do not see unsurmountable implementation problems.

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:
>=20
> Daniel Frey wrote:
> > Ken Alverson wrote:
> >
> >>"Daniel Frey" <daniel.frey@aixigo.de> wrote in message
> >>news:3CC6A5C0.6B1FD30D@aixigo.de...
> >>
> >>>Just a quick question: Will C++0x contain something like a this_t? I
> >>>mean:
> >>>
> >>>class X
> >>>{
> >>>   typedef X this_t; // Like this, but automatically?
> >>>};
> >>
> >>Assuming typeof becomes reality, would this provide anything over
> >>typeof(this)?
> >
> >
> > Yes, as 'this' is only available inside member functions. Both exampl=
es
> > I gave can't access 'this' at the location where I need 'this_t'.
>=20
> Can you given any examples to show how "this_t" could be
> used?  I don't see what it buys you, if you need to know
> the type X in order to access it, and I don't see how you
> could use it without knowing that type.

I gave two examples in the original post. Don't they count or aren't
they clear enough? How to you think of them? I thought it should be
obvious that inside a macro-definition in a header (e.g. for an operator
library) I need to specify the type, but I don't know how if there is no
'this_t'. And the example for 'final' is the most generic and
easy-to-use I could come up with (currently illegal because of 'friend
T', but anyway :), but it also requires the preprocessor and thus needs
'this_t'. If I missed something, please let me know.

Another example (and probably a far better one than mine) is the one
Hans gave, see his post.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
>=20
> Hans Aberg <remove.haberg@matematik.su.se> wrote:
>=20
> > In the context of template macros, one might implement for example th=
e
> > clone function by the use of such a this_type:
> >   class root {
> >   public
> >     virtual this_type* clone() const { return new this_type(*this); }
> >   };
>=20
> > The idea is here that clone() should behave not as a single function
> > instantiation, but also that derived classes should get one, i.e., th=
e
> > class
> >   class my_class : public virtual root {
> >     ...
> >   };
> > should get an instantiation of
> >   virtual my_class* clone() const { return new my_class(*this); }
>=20
> How about this:
>=20
> #include <typeinfo>
>=20
> class root {
>         public:
>         // does not need to be virtual
>         root* clone() const {
>                 return new typeid(*this)(*this); // future_std
>         }
> };

I'd call this class 'cloneable' instead of 'root', but still a nice
idea. One thing I don't like about the second solution is that typeid(
*this ) will be runtime-code, not compile-time-code, therefore I'd
prefer Hans solution. Also, I can't fully understand how typeid( *this
)( *this ) should work. The second *this is of type root, therefore I
think there needs to be a cast of some kind. Or will typeid( *this )
accept a void*? The return type is also not the best solution I could
think of. Anyway, it would be nice to have a clone() available :)

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <YEZx8.7153$T_.158036@iad-read.news.verio.net>,
xleobx@qmailcomq.com wrote:
>How about this:
>
>#include <typeinfo>
>
>class root {
>        public:
>        // does not need to be virtual
>        root* clone() const {
>                return new typeid(*this)(*this); // future_std
>        }
>};
>
>I do not see unsurmountable implementation problems.

My guess is that it does not work: The runtime system needs to make a
dynamic selection between the different new X(*this) functions in the
polymorphy hierarchy, and your suggestion does not provide it: The only
way C++ can do such a thing is via virtual functions.

So I think that when instantiated, you will get:
  class root {
          public:
          root* clone() const {
                  return new root(*this); // future_std
          }
  };
which is not what one wants.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:
>>#include <typeinfo>
>>
>>class root {
>>        public:
>>        // does not need to be virtual
>>        root* clone() const {
>>                return new typeid(*this)(*this); // future_std
>>        }
>>};
>>
>>I do not see unsurmountable implementation problems.

> My guess is that it does not work: The runtime system needs to make a

NB: typeid, not typeof.

> dynamic selection between the different new X(*this) functions in the
> polymorphy hierarchy, and your suggestion does not provide it: The only
> way C++ can do such a thing is via virtual functions.

Exactly, and the type_info object can be made to provide all necessary info.

[ The rest is based on "typeof" assumption; skipped ]

 Leo

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello, world!

Just a quick question: Will C++0x contain something like a this_t? I
mean:

class X
{
   typedef X this_t; // Like this, but automatically?
};

This may look a bit weird as I know the type's name already and a
typedef can easily be added, but there are some things that could make
it a useful feature anyway. It comes into play when you use MACROs (yes,
they are ugly, but still they have some advantages). Consider:

namespace std
{
   template< typename T > class final
   {
      // I know, currently this is not allowed,
      // but it may be allowed in C++0x and it
      // already works for some compilers :)
      friend T;
      final() {}
   };
}
#define STD_FINALIZE public virtual std::final< this_t >

class A : STD_FINALIZE
{
   ...
};

A typedef isn't possible, as it would be too late.

Another example:

#define OPERATOR_NOT_EQUAL \
inline bool operator!=3D( const this_t& rhs ) const \
{ return !( *this =3D=3D rhs ); }

With a this_t from the language, the user isn't forced to add it by hand
if using the above macro and thus my operators macro library would be
easier and safer to use.

Any chance that C++0x might contain a this_t or something similar? I
think it would be really useful and no code should be broken (as any
function/variable that is called this_t will hide the implicit typedef
and thus it will continue to work). Or do you see any problems when
adding it to the language?

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Daniel Frey" <daniel.frey@aixigo.de> wrote in message
news:3CC6A5C0.6B1FD30D@aixigo.de...
>
> Just a quick question: Will C++0x contain something like a this_t? I
> mean:
>
> class X
> {
>    typedef X this_t; // Like this, but automatically?
> };

Assuming typeof becomes reality, would this provide anything over
typeof(this)?

Ken


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson wrote:
>=20
> "Daniel Frey" <daniel.frey@aixigo.de> wrote in message
> news:3CC6A5C0.6B1FD30D@aixigo.de...
> >
> > Just a quick question: Will C++0x contain something like a this_t? I
> > mean:
> >
> > class X
> > {
> >    typedef X this_t; // Like this, but automatically?
> > };
>=20
> Assuming typeof becomes reality, would this provide anything over
> typeof(this)?

Yes, as 'this' is only available inside member functions. Both examples
I gave can't access 'this' at the location where I need 'this_t'.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <aa6s3f$q0k$1@eeyore.INS.cwru.edu>, "Ken Alverson"
<Ken@Alverson.com> wrote:
>>... Will C++0x contain something like a this_t? I
>> mean:
>>
>> class X
>> {
>>    typedef X this_t; // Like this, but automatically?
>> };
>
>Assuming typeof becomes reality, would this provide anything over
>typeof(this)?

In the context of template macros, one might implement for example the
clone function by the use of such a this_type:
  class root {
  public
    virtual this_type* clone() const { return new this_type(*this); }
  };

The idea is here that clone() should behave not as a single function
instantiation, but also that derived classes should get one, i.e., the
class
  class my_class : public virtual root {
    ...
  };
should get an instantiation of
  virtual my_class* clone() const { return new my_class(*this); }

This turns out to be practical when one writes a polymorphic hierarchy
with several tens of classes: It is easy to forget to add the cloning
function, and if that is not done, one will get runtime errors when
copying.

This is one suggestion of how to implement clone(), so that one can ensure
that also derived classes have it. Another is to add it via the C++
standard: I do not know of any other good examples where such a template
instantiation of this_type is useful.

-- I go around the clone() problem by starting to write my own OOPL, using
Flex and Bison, that outputs C++ classes. This way the automated system
can add whatever is needed to the C++ classes.

But I think that my solution is extreme: It would be helpful if instead
the C++ standard added such things.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey wrote:
> Ken Alverson wrote:
>
>>"Daniel Frey" <daniel.frey@aixigo.de> wrote in message
>>news:3CC6A5C0.6B1FD30D@aixigo.de...
>>
>>>Just a quick question: Will C++0x contain something like a this_t? I
>>>mean:
>>>
>>>class X
>>>{
>>>   typedef X this_t; // Like this, but automatically?
>>>};
>>
>>Assuming typeof becomes reality, would this provide anything over
>>typeof(this)?
>
>
> Yes, as 'this' is only available inside member functions. Both examples
> I gave can't access 'this' at the location where I need 'this_t'.

Can you given any examples to show how "this_t" could be
used?  I don't see what it buys you, if you need to know
the type X in order to access it, and I don't see how you
could use it without knowing that type.

--
James Dennett <jdennett@acm.org>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]