From 3213898089349243884 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,3cd3269a4e3cc2e3 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-09-17 05:05:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: Attila.Feher@lmf.ericsson.se (Attila Feher) Newsgroups: comp.std.c++ Subject: Re: in response to "Informal Defect Report: static_cast (5.2.9/2)" by Attila Feher Date: Tue, 17 Sep 2002 12:05:24 +0000 (UTC) Organization: Oy L M Ericsson Ab Lines: 145 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <3D870E94.BFA0D362@lmf.ericsson.se> References: <046a01c25c75$85d234b0$aeb3e540@niklandhntl9f6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1032264324 24276 10.0.0.1 (17 Sep 2002 12:05:24 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 17 Sep 2002 12:05:24 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 17rH6U-0006JP-00 for mail2news@news.news.demon.net; Tue, 17 Sep 2002 12:05:23 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id WAA26701; Tue, 17 Sep 2002 22:04:44 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Tue, 17 Sep 2002 11:14:30 +0000 (UTC) X-Accept-Language: hu, en Xref: archiver1.google.com comp.std.c++:13960 > Nikolai Borissov wrote: > To my opinion, the conversion between related types does not mean > one-step conversion, whatever reasonable meaning to a step we can > assign. That bothers me as well. I mean the T(e) rule does not work - and this rule does not seem to work either. I just wonder that all those language gurus here did not come up with _any_ answer neither on this qestion or my question about what does the "interpreted" mean for C style casts. Kinda frightening that in csc++ there is not one single soul who understands casts... :-( > Here is a set of static casts which is accepted by Comeau C++ > compiler. > (Sorry there is some guessing about conversion steps, but I don't see > any 1-step reasonable explanation at all) > > #include > > struct A {}; > struct DerA: public A {}; > struct OpDerA { operator DerA() const {return DerA();};}; > struct B {}; > struct DerB: public B {}; > struct OpDerB { operator DerB() const {return DerB();};}; > struct Widget > {Widget(); > Widget(int); > Widget(const A&); > Widget(const B); > }; > struct DerWidget: public Widget {}; > struct OpDerWidget { operator DerWidget&() const {return *new > DerWidget;};}; > > int main() > { > static_cast(5.0); > // 1) 5.0 -> temp int > // 2) temp int -> Widget(int) -> taget Widget object 5.0 is a compile time constant... so it can be converted to int at compile time... not that it should mean anything, but it may tell more if the cast would be in a function, taking a double argument... > static_cast(OpDerA()); > // 1) OpDerA operator -> temp DerA object This is a tricky one... This is an implicit type conversion taking place before the "cast" conversion. > // 2) temp DerA -> reference to temp DerA That is an implicit reference binding _before_ the casting happens. And I believe that this and step 3 is the _same_ step, there is no reference to DerA created. And it is already a constant reference - since it is bound to an unnamed temporary. > // 3) reference to temp DerA -> reference to subobject A See at 2. > // 4) reference to subobject A -> reference to const subobject A Nope. The DerA() is temporary, there is immediately a const reference bound to it. Nothing else can be. > // 5) reference to const subobject A -> Widget(const A&) -> target This is the "type conversion" - I mean what was suggested in the only post guessing about the real rules. > Widget object > > static_cast(OpDerB()); > // 1) OpDerB operator -> temp DerB object Der B or Dei B. Das B? ;-) Same as before. Why does this work, when Scott's example does not? > // 2) temp DerB -> reference to temp DerB > // 3) reference to temp DerB -> reference to subobject B > // 4) reference to subobject B -> reference to const subobject B As before, this (2-4) is reference binding, immediately the const one. > // 5) reference to const subobject B -> class B copy constructor > (default) -> temp object B That is already part of the call to the Widget copy constructor, I am afraid it does not count as a type conversion. > // 6) temp object B -> const temp object B That is a "cv qualifier added", this should not count as type conversion. :-( > // 7) const temp object B -> Widget(const B) -> target Widget object That is the type conversion done by the cast. See before what I mean. > static_cast(OpDerWidget()); > // 1) OpDerWidget operator -> reference to DerWidget object DerWidget ist ein unglaubliche (here my German knowledge totally ends) dangerous a beast with that new2ref game. :-) > // 2) reference to DerWidget object -> reference to Widget subobject > // 3) reference to Widget subobject -> reference to const Widget > subobject I wonder if 5.9.2/6 (and its revised form) applies here for you examples. It says that the reverse of _any_ standard conversion can be don eusing static cast (if it does not remove constness) except l2rvalue, arr2ptr, func2ptr and boolean conversions... [SNIP] Well, you have shown a lot of interesting casts - thank you very much for that. Those imply that the "one type conversion only" rule is not a rule. The questions remains: why do your examples work and why doesn't Scott's example work? I wonder how can it be that there is noone reading csc++ who knows the answer to this static_cast question and to my "what is interpreted" question about C style casts. This is quite alarming that noone seems to know how exaclty one of the most dangerous elements of the C++ language work. :-((( I was waiting to see compiler implementors to jump in and protect their compiler by explaining to us why did they decide not to allow Scott's conversion. I was also hoping that someone who has done a compiler will tell the "rules of interpretation" for C style casts. I believe these are no trade secrets, but rather things we have to get a common understanding about... that is the reason why I think that noone knows rather than noone tells. :-( Attila --- [ 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 ]