On Wed, 2 Oct 2002 17:27:55 +0000 (UTC), gdr@integrable-solutions.net
(Gabriel Dos Reis) wrote:

> jpotter@falcon.lhup.edu (John Potter) writes:

> > > (note-1: a static_cast<> would have checked accessibility and rejects
> > > the code -- but that is not the point here)

> > Then why did you use private?

> Because that was the point I was exercising.

> Accessibility checking seems to be something _new_ in the new style
> casts. Remember that the claim was that no one should be using C style
> casts in new projects.

Ah, two different points.  I don't think this one is important.  Prior
to the new C++ casts, the C style cast ingored accessibility and
adjusted pointers.  After introduction of C++ casts, the C style cast
still does the same thing.  No change, no problem.  Yes, there may be
a reason to use C style casts in new code for this reason, but it
still does what it did before the standard.  No old code was broken.

The other point involves (T const&)x where there is a conversion from
the type of x to T.  Prior to the C++ casts, this was a
reinterpret_cast with the same result as *(T const*)&x.  After adding
the C++ casts, it is a static_cast which creates a temporary T object.
This breaks old code.  The best examples are with built-ins like int
and double.  This is the one we are complaining about.  It is very
bad that (T const&)x is a static_cast and (T&)x is a reinterpret_cast.

Two different points.  No wonder we could not communicate.  If all you
are saying is that there could be C style casts in new code, fine.
The point of the subject is that static_cast does things completely
out of character for traditional casts when a const& is involved.
Non-const reference casts perform like non-const pointer casts;
however, const reference casts may be very different from the const
pointer cast.

John

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Andy Sawyer":
>
> > It's quite possible for a C header to contain something like:
> >
> > static const char szCVSid =3D "$id$";
> > static int funcation() { return 99; }
> >
> > or whatever and by included multiple times.
>=20
> I am more and more embarrased.  First I was a smart-S.  Now the smart i=
s
> gone... :-)

Nobody likes a "smart-S". Especially when I'm right :-)

> Yeah: I have made the mistake of being born too late and the wrong plac=
e.
> :-)

I'm not entirely sure it's possible to be born too late (but I guess
that's due to the fact that I'd rather be much younger that I am
now...)

> Actually programming I have started around 1985(?) with basic and in
> 1986-7 I was already doing some Z80 assembly.

This is where somebody jumps in and claims to have turned the handle
on Babbage's computing engine=B9.

> > No, I actually meant neither the compiler not the linker - I actually
> > meant to write the preprocessor.
>=20
> Yeah.  You are right.  But if we take apart linking from compiling - I
> meant it that way.  At many systems the precompiler is not a separate
> entity (binary/executable).  I mean it wasn't for many.  I guess today =
it
> is in some way.

The existence of a separate binary or executable is irreleveant - It's
perfectly reasonable for a single executable to have more than one
function - especially if those functions are closely
related. Preprocessing is a distinct phase of translation as described
by 2.1 (I don't have a copy of either C standard to hand, so can't
comment on what they say).

> > There are quite a few "pre-C99" compilers which implemented some form
> > of inline as an extention to the language (IIRC, Zortech C/C++ allowe=
d
> > inline functions in C as far back as 1988/9 - possibly even earlier).
>=20
> Sure.  I have used it myself with some of those.  I dunno which was...
> Watcom? Borland? MS?...  Meeemories...

I know Borland introduced inline to C before C99, and I 'm pretty sure
that MS did. I can't be sure about Watcom (I only used it
briefly). Symantec inherited when they bought Zortech (BTW, if anyone
knows what Walter's up to these days please say "Hi" :-). I'd also be
very surprised if someone told me that gcc hadn't done so.

Regards,
 Andy S.

=B9  This happend on Bix (IIRC) many years ago. It turned out that the
claimant actually /did/ turn the handle on Babbage's engine=B2 - he
worked in the Science Museum where they had a replica!
=B2  Actually, I'm not sure if it was the difference engine or the
computing engine. Pretty impressive either way=B3.
=B3  Footnotes to footnotes. I claim today's PTerry award :-).
--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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 <and9s1$8u4$1@phys-news1.kolumbus.fi>,
White Wolf <wolof@freemail.hu> wrote:
>"Andy Sawyer":
>> > Are there existing commercial implementations of it?
>>
>> Yes - Comeau supports C99.
>
>Beta or released?  It may get a bit out of hand - I just think if we've got
>this far it is good to have this info here for the record.

Comeau, and Dinkumware, have provided support for C99 for years now.
--
Greg Comeau/ 4.3.0.1: Only 4.3 days left on special offer!
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?

---
[ 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                       ]

"Greg Comeau":
> Comeau, and Dinkumware, have provided support for C99 for years now.

I guess I was mixed up, because your were mentioning C99 together with the
C++ export ect.

WW


---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Greg Comeau":
> > Comeau, and Dinkumware, have provided support for C99 for years now.
>
> I guess I was mixed up, because your were mentioning C99 together with the
> C++ export ect.

Greg's compiler (in C99 mode) supports C99. In C++ mode it supports
export. "So much language support it hurts" :-)

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

"Chris Waters":
> First of all, what you "K" is wrong: C99 has introduced "inline" to C.

Are there existing commercial implementations of it?  (It is not meant as a
critique of what you have said, just a question - apropos)

> Second of all, I'm not sure what relevance the fact that a macro doesn't
> get compiled till it's expanded has here.  If the macro is used in your
> C++ code, and the macro uses a C-style cast (because it's designed so
> that it can also be used in C), then the meaning of a C-style cast in
> C++ is clearly an issue.

I stand corrected.  You are right.  I am getting used to it. ;-)

> Unless I'm missing something...

No, I guess I was carried away again.

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Chris Waters":
> > First of all, what you "K" is wrong: C99 has introduced "inline" to C.
>
> Are there existing commercial implementations of it?
                     ^^^^^^^^^^

Why commercial?

GCC has an approximation of C99's semantics of inline.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ 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                       ]

""Ron Natalie:
> You can put anything you please in a header.

That is right.  Is it really used like this?  In C if I do that (on many
platforms I used) if the header had been included into more than one impl.
file I have got link errors.

> The language does not distinguish
> between things that are brought in to
> the translation unit via #include versus what
> was in the original input file.

Well, that was pretty clear to me. ;-)  I am just wondering if using a
header to include implementation would make any practical sense.

> C has inline functions, so it is quite
> reasonable to expect to find these in headers.

Well, it has.  The latest standard, so that is true.  Are there any
commercial C99 compilers out there?

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Gabriel Dos Reis" <gdr@soliton.integrable-solutions.net> az al=E1bbiak=
at
> =EDrta a k=F6vetkezo h=EDr=FCzenetben:
> m34rc7ffj3.fsf@soliton.integrable-solutions.net...
> > wolof@freemail.hu ("White Wolf") writes:
> >
> > | "Gabriel Dos Reis" writes:
> > | > I'm not sure of this one.  I think that something like
> > | >
> > | >    class A { /* ... */ };
> > | >    class B : A { /* ... */ };
> > |
> > | I have just realized: when do you plan to have this in a common C a=
nd
> C++
> > | header?
> >
> > I think you lost track.  We were discussing C style cast in general.
>=20
> I don't think so.  You wrote this:
>=20
> >>>I'm not convinced that the only code that will be using a C style is=
 a
> legacy code.  New projects can share headers with C and C++ programs.<<=
<

Well, for the record, I exactly said:

   | > | (IMHO, changing the meaning of a C style
   | > | cast is particularly unjustified, because about the only code wh=
ich
   | > | should be using them anyway is legacy code.)
   | >
   | > I'm not convinced that the only code that will be using a C style =
is a
   | > legacy code.  New projects can share headers with C and C++ progra=
ms.
   |=20
   | The only C style cast which has changed meaning is (T const&).=20

   I'm not sure of this one.  I think that something like [ ... ]

Notice how I was _constantly_ "targetting" the "the C style cast ..." par=
t.=20

In replying to John's query, I was careful in identifying two issues

  (1) C-style casts in new projects (my statement)
  (2) cast in common(C, C++)

Note how my reply was structured:

 #  | The only C style cast which has changed meaning is (T const&).=20
 #
 #  I'm not sure of this one.   [...]
 #
 #  | It
 #  | will not be used in common headers.
 #
 #  That is a different statement -- which I can happen to agree with.

which makes it obvious that I was seperating two issues.

Given my last sentence in the reply to John's remark, your

  I have just realized: when do you plan to have this in a common C
  and C++ header?

sounds to me unnecessarily inflammatory, since it was obvious that I
was distinguishing purely C++ contructs from C ones.

--=20
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ 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 Tue, 1 Oct 2002 17:22:37 +0000 (UTC),
gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:

> jpotter@falcon.lhup.edu (John Potter) writes:

> | On Mon, 30 Sep 2002 12:40:29 +0000 (UTC),
> | gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:

> | > jpotter@falcon.lhup.edu (John Potter) writes:

> | > | The only C style cast which has changed meaning is (T const&).

> | > I'm not sure of this one.  I think that something like

> | >    class A { /* ... */ };
> | >    class B : A { /* ... */ };
> |
> | >    // ...
> | >    A* p = new B;
> | >    // ...
> | >   do_something_with((B*)p);

> | > were doing something more than a reinterpret_cast<> (I would say close
> | > to dynamic_cast<> modulo accessibility).

> | I don't follow you.  We are in 5.4/7 never-never-land.  A C style cast
> | never does a dynamic_cast.

> Yes, I do know that this is what the standard says.  I'm talking of what
> used to be done in pre-standard era -- note my use of "were" in my
> previous message.

Ok, lets see what happens with this.

#include <iostream.h>
class B1 { char c; };
class B2 { char c; };
class D : B1, B2 { char c; };
int main () {
    B1 b1;
    B2 b2;
    D d;
    cout << "B1 to D " << &b1 << " " << (D*)&b1 << endl;
    cout << "B2 to D " << &b2 << " " << (D*)&b2 << endl;
    cout << "D to B1 " << &d << " " << (B1*)&d << endl;
    cout << "D to B2 " << &d << " " << (B2*)&d << endl;
    }

With pre-standard xlC, I get:

B1 to D 0x2ff22ce8 0x2ff22ce8
B2 to D 0x2ff22ce9 0x2ff22ce8
D to B1 0x2ff22cea 0x2ff22cea
D to B2 0x2ff22cea 0x2ff22ceb

Clearly static_cast.

With post-standard g++, I get:

B1 to D 0x2ff22ce0 0x2ff22ce0
B2 to D 0x2ff22ce1 0x2ff22ce0
D to B1 0x2ff22ce8 0x2ff22ce8
D to B2 0x2ff22ce8 0x2ff22ce9

Clearly static_cast.

I still don't see your point.  Can you post some code to show it?

John

---
[ 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                       ]

"Gabriel Dos Reis":
> wolof@freemail.hu ("White Wolf") writes:
>
> > "Chris Waters":
> > > First of all, what you "K" is wrong: C99 has introduced "inline" to
C.
> >
> > Are there existing commercial implementations of it?
>                      ^^^^^^^^^^
>
> Why commercial?
>
> GCC has an approximation of C99's semantics of inline.

I consider that commercial.  What I have meant is that not beta versions.

WW


---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> ""Ron Natalie:
> > You can put anything you please in a header.
>
> That is right.  Is it really used like this?

My system C headers contain plenty "static inline" functions.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Chris Waters":
> > First of all, what you "K" is wrong: C99 has introduced "inline" to C.
>
> Are there existing commercial implementations of it?

Yes - Comeau supports C99.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) writes:

[...]

> > | The only C style cast which has changed meaning is (T const&).
>
> > I'm not sure of this one.  I think that something like
>
> >    class A { /* ... */ };
> >    class B : A { /* ... */ };
>
> >    // ...
> >    A* p = new B;
> >    // ...
> >   do_something_with((B*)p);
>
> > were doing something more than a reinterpret_cast<>
>
> We should be doing a static_cast.  And this has not changed its meaning.

Without accessibility enforcement, OK, agreed.

> In C, grosso modo, pointer casts corresponded to reinterpret_cast, and
> non pointer casts to static_cast. Simple, clear and easy to understand.

Well, even in C you want the following to be a static_cast<>

  int* p = (int*) malloc(n * sizeof (int));

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> ""Ron Natalie:
> > You can put anything you please in a header.
>
> That is right.  Is it really used like this?  In C if I do that (on many
> platforms I used) if the header had been included into more than one impl.
> file I have got link errors.

That depends on exactly what you put in the header, and where you
include it - but as Ron says:

> > The language does not distinguish
> > between things that are brought in to
> > the translation unit via #include versus what
> > was in the original input file.

The compile/link phase in reality only cares about translation units -
the concept of headers is only of interest to the linker (modulo the
C++ standard's latitude to allow compilers to do "magic" when seeing
an include directive for a standard library header).

> Well, that was pretty clear to me. ;-)  I am just wondering if using a
> header to include implementation would make any practical sense.

In C, often not - unless it's inline.

> > C has inline functions, so it is quite
> > reasonable to expect to find these in headers.
>
> Well, it has.  The latest standard, so that is true.  Are there any
> commercial C99 compilers out there?

There seems to be an echo in here :-), but Comeau
(http://www.comeaucomputing.com) supports C99 on a large number of
platforms.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

"Gabriel Dos Reis":
> wolof@freemail.hu ("White Wolf") writes:
>
> > ""Ron Natalie:
> > > You can put anything you please in a header.
> >
> > That is right.  Is it really used like this?
>
> My system C headers contain plenty "static inline" functions.

Which OS is it?  I think my target OS doesn't have :-(  I wish it did.

WW


---
[ 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                       ]

"Andy Sawyer":
> > That is right.  Is it really used like this?  In C if I do that (on
many
> > platforms I used) if the header had been included into more than one
impl.
> > file I have got link errors.
>
> That depends on exactly what you put in the header, and where you
> include it - but as Ron says:

I know.  We were talking about implementation :-)  I was talking about
non-inline implementation. :-)

> > > The language does not distinguish
> > > between things that are brought in to
> > > the translation unit via #include versus what
> > > was in the original input file.
>
> The compile/link phase in reality only cares about translation units -

I know eggzaktlee.  My questions may seem idiotic but I work with C from
about 1990 and with C++ from about 1992. :-)

> the concept of headers is only of interest to the linker

You mean to the compiler?  I would be alarmed to see my linker to deal with
#includes...

> > Well, that was pretty clear to me. ;-)  I am just wondering if using a
> > header to include implementation would make any practical sense.
>
> In C, often not - unless it's inline.

Yep.  And it seems some form of inline was (as I also have seen it) pretty
common in C compilers.  I did not think it was - since I have seen only a
very limited amount of C compilers, so I could not guess for all...

BR, WW


---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Gabriel Dos Reis":
> > wolof@freemail.hu ("White Wolf") writes:
> >
> > > ""Ron Natalie:
> > > > You can put anything you please in a header.
> > >
> > > That is right.  Is it really used like this?
> >
> > My system C headers contain plenty "static inline" functions.
>
> Which OS is it?

GNU/Linux -- I thought you would have guessed that from the previous
message header :-)

Well, to make this message on-topic, I don't see how you arrive at the
conclusion that it doesn't make sense for a header file shared by C and
C++ to contain function definitions.

--
Gabriel Dos Reis,       gdr@integrable-solutions.net

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) writes:

> On Tue, 1 Oct 2002 17:22:37 +0000 (UTC),
> gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:
>
> > jpotter@falcon.lhup.edu (John Potter) writes:
>
> > | On Mon, 30 Sep 2002 12:40:29 +0000 (UTC),
> > | gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:
>
> > | > jpotter@falcon.lhup.edu (John Potter) writes:
>
> > | > | The only C style cast which has changed meaning is (T const&).
>
> > | > I'm not sure of this one.  I think that something like
>
> > | >    class A { /* ... */ };
> > | >    class B : A { /* ... */ };
> > |
> > | >    // ...
> > | >    A* p = new B;
> > | >    // ...
> > | >   do_something_with((B*)p);
>
> > | > were doing something more than a reinterpret_cast<> (I would say close
> > | > to dynamic_cast<> modulo accessibility).
>
> > | I don't follow you.  We are in 5.4/7 never-never-land.  A C style cast
> > | never does a dynamic_cast.
>
> > Yes, I do know that this is what the standard says.  I'm talking of what
> > used to be done in pre-standard era -- note my use of "were" in my
> > previous message.

[...]

> With pre-standard xlC, I get:

[...]

> Clearly static_cast.
>
> With post-standard g++, I get:

[...]

> Clearly static_cast.
>

How would have you noticed that the compilers were doing something that is
-not- a static_cast<> ?

(note-1: a static_cast<> would have checked accessibility and rejects
the code -- but that is not the point here)

(note-2: I just read a message from James which reminds me that a
dynamic_cast<> with not runtime checks is morally a static_cast<>
Agreed on that.)

--
Gabriel Dos Reis,       gdr@intgerable-solutions.net

---
[ 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                       ]

"Gabriel Dos Reis":
>Given my last sentence in the reply to John's remark, your
>
> > I have just realized: when do you plan to have this in a common C
> > and C++ header?

> sounds to me unnecessarily inflammatory, since it was obvious that I
> was distinguishing purely C++ contructs from C ones.

I did not mean it to be.  I was confused reading the thread.  Of course as
you have cut those parts out it makes much more sense.  Thanks for the
clarification.

WW


---
[ 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                       ]

White Wolf wrote:
....
> until it gets expanded in the code.  AFAIK C headers contain no code - only
> macros, types and prototypes.

That's just common usage, and good practice. Well, actually, I'd add
comments, preprocessing directives, and  'extern' declarations of global
objects to your list. Of course, good practice also calls for avoiding
the use of globals.

In any event, there's no requirement to that effect. For instance, a
header file can include a function definition, though it's a pretty bad
idea if the function has external linkage, and it's inefficient if the
function is of any significant size. However, it's not an uncommon idea
to do this for short static functions.

A header could consist entirely of code that is meant to be inserted by
a #include into the middle of a function definition - though I can't say
this is a particularly common practice, nor a particularly good idea. A
more common technique would #defining macros whose expansion involves
actual code.

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Andy Sawyer":
> > > That is right.  Is it really used like this?  In C if I do that (on
> many
> > > platforms I used) if the header had been included into more than one
> impl.
> > > file I have got link errors.
> >
> > That depends on exactly what you put in the header, and where you
> > include it - but as Ron says:
>
> I know.  We were talking about implementation :-)  I was talking about
> non-inline implementation. :-)

That wasn't clear to me from the context. You said:

> In C header?  Do you mean in a macro?  But the macro will not be compiled
> until it gets expanded in the code.  AFAIK C headers contain no code - only
> macros, types and prototypes.

It's quite possible for a C header to contain something like:

static const char szCVSid = "$id$";
static int funcation() { return 99; }

or whatever and by included multiple times.

> I know eggzaktlee.  My questions may seem idiotic but I work with C from
> about 1990 and with C++ from about 1992. :-)

I have a few years on you then, newbie :-) :-)

> > the concept of headers is only of interest to the linker
>
> You mean to the compiler?  I would be alarmed to see my linker to deal with
> #includes...

No, I actually meant neither the compiler not the linker - I actually
meant to write the preprocessor.

> > In C, often not - unless it's inline.
>
> Yep.  And it seems some form of inline was (as I also have seen it) pretty
> common in C compilers.  I did not think it was - since I have seen only a
> very limited amount of C compilers, so I could not guess for all...

There are quite a few "pre-C99" compilers which implemented some form
of inline as an extention to the language (IIRC, Zortech C/C++ allowed
inline functions in C as far back as 1988/9 - possibly even earlier).

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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 Wed, 2 Oct 2002 00:18:03 +0000 (UTC), gdr@integrable-solutions.net
(Gabriel Dos Reis) wrote:

> How would have you noticed that the compilers were doing something that is
> -not- a static_cast<> ?

Since reinterpret_cast is expected to not be surprising to one who
knows the memory model, it can usually be expected to do nothing.  The
fact that pointers were adjusted indicates static_cast.  Some proof:

    cout << "B1 to D " << &b1 << " " << (D*)&b1 << endl;
    cout << "B2 to D " << &b2 << " " << (D*)&b2 << endl;
    cout << "with re " << &b2 << " " << reinterpret_cast<D*>(&b2)
            << endl;
    cout << "D to B1 " << &d << " " << (B1*)&d << endl;
    cout << "D to B2 " << &d << " " << (B2*)&d << endl;
    cout << "with re " << &b2 << " " << reinterpret_cast<B2*>(&d)
            << endl;

B1 to D 0x22fedf 0x22fedf
B2 to D 0x22fede 0x22fedd
with re 0x22fede 0x22fede
D to B1 0x22fedc 0x22fedc
D to B2 0x22fedc 0x22fedd
with re 0x22fede 0x22fedc

> (note-1: a static_cast<> would have checked accessibility and rejects
> the code -- but that is not the point here)

Then why did you use private?  The cast done by the C style cast is
what static_cast does not what reinterpret_cast does.  The C style
ignores accessibility and does the static_cast thing.  Make it public
and add static_cast to the code to see.

I thought maybe you had a point, but I still fail to see one.  Do you
have one?  If so, what is it?  Any proof?

John

---
[ 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                       ]

"Andy Sawyer":
> > Are there existing commercial implementations of it?
>
> Yes - Comeau supports C99.

Beta or released?  It may get a bit out of hand - I just think if we've got
this far it is good to have this info here for the record.

WW


---
[ 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                       ]

gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
news:<m3vg4lx276.fsf@uniton.integrable-solutions.net>...
> kanze@gabi-soft.de (James Kanze) writes:

> [...]

> > > | The only C style cast which has changed meaning is (T const&).

> > > I'm not sure of this one.  I think that something like

> > >    class A { /* ... */ };
> > >    class B : A { /* ... */ };

> > >    // ...
> > >    A* p = new B;
> > >    // ...
> > >   do_something_with((B*)p);

> > > were doing something more than a reinterpret_cast<>

> > We should be doing a static_cast. And this has not changed its
> > meaning.

> Without accessibility enforcement, OK, agreed.

> > In C, grosso modo, pointer casts corresponded to reinterpret_cast,
> > and non pointer casts to static_cast. Simple, clear and easy to
> > understand.

> Well, even in C you want the following to be a static_cast<>

>   int* p = (int*) malloc(n * sizeof (int));

What is the difference in the semantics between static_cast and
reinterpret_cast here?

C doesn't have the new style casts, so I'm not sure how to say what you
want this to be in C.  If you mean that you don't want it to be flagged
as particularly dangerous and system dependant (which is what
reinterpret_cast also does in practice), then yes, I agree.  And if for
some reason I wanted to use malloc in a C++ program, in a similar
context, then, yes, I would use a static_cast, and not a
reinterpret_cast.

But C doesn't make these distinctions.  What I was talking about wasn't
how the cast would be perceived, and I didn't mean to imply that none of
C's pointer casts could be done with static_cast.  (That's why I said
"grosso modo".)  What I was concerned with was the basic semantics: a
pointer cast, in C, gives you a pointer pointing to the same location in
memory (or as near as possible) as the original, which is the intended
semantics for reinterpret_cast in C++.  A non-pointer cast, in C, gives
you a true conversion -- a conversion which, given the right context,
could also be implicit.  This is a static_cast in C++.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

> "Andy Sawyer":
> > > Are there existing commercial implementations of it?
> >
> > Yes - Comeau supports C99.
>
> Beta or released?  It may get a bit out of hand - I just think if we've got
> this far it is good to have this info here for the record.

Release (I have it here, although I don't personally use the C99
support). See http://www.comeaucomputing.com for more information.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]

"Gabriel Dos Reis":

> Well, to make this message on-topic, I don't see how you arrive at the
> conclusion that it doesn't make sense for a header file shared by C and
> C++ to contain function definitions.

>From the headers I have seen so far.  I have to admit, that I haven't spent
much time looking at the Linux system ones, since I remembered that Linux
was quite heavily using gcc extensions around the kernel... so I thought
that it may be that the headers are also way too gcc specific.

WW


---
[ 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 Russell Kuyper Jr.":
> White Wolf wrote:
> ....
> > until it gets expanded in the code.  AFAIK C headers contain no code -
only
> > macros, types and prototypes.
>
> That's just common usage, and good practice. Well, actually, I'd add
> comments, preprocessing directives, and  'extern' declarations of global
> objects to your list. Of course, good practice also calls for avoiding
> the use of globals.

I was trying to concentrate on those things, which may contain C style
casts.  I guess I have mentioned macros.

> In any event, there's no requirement to that effect. For instance, a
> header file can include a function definition, though it's a pretty bad
> idea if the function has external linkage, and it's inefficient if the
> function is of any significant size. However, it's not an uncommon idea
> to do this for short static functions.

Yep.  I used it myself in some twilight-zone code.  I am embarrased.  I
think I should stop reading USENET and especially posting after 1am. :-)

> A header could consist entirely of code that is meant to be inserted by
> a #include into the middle of a function definition - though I can't say
> this is a particularly common practice, nor a particularly good idea. A
> more common technique would #defining macros whose expansion involves
> actual code.

I have also seen this #include in the middle of a function trick.  I was
shocked.  The "rationale" was that "the code cannot be a function, because
of the calling overhead".  Then I have asked for proof.  There was none.
Using a function had no observable effect on speed. :-)  Most of the code
written was IO bound, even if it was serial port.  So I am yet to see a
situation when it can be justified, but I also can believe that there is
such case.

WW


---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) writes:

[...]

> > (note-1: a static_cast<> would have checked accessibility and rejects
> > the code -- but that is not the point here)
>
> Then why did you use private?

Because that was the point I was exercising.

Accessibility checking seems to be something _new_ in the new style
casts. Remember that the claim was that no one should be using C style
casts in new projects.

[...]

> I thought maybe you had a point, but I still fail to see one.  Do you
> have one?  If so, what is it?

Well, I think I have one (see above) but after 6 messages, it still
seems to be unclear to you so I would just drop the entire thread
hoping for better days.

--
Gabriel Dos Reis,       gdr@inetgrable-solutions.net

---
[ 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                       ]

"Andy Sawyer":
> > I know.  We were talking about implementation :-)  I was talking about
> > non-inline implementation. :-)
>
> That wasn't clear to me from the context. You said:
>
> > In C header?  Do you mean in a macro?  But the macro will not be
compiled
> > until it gets expanded in the code.  AFAIK C headers contain no code -
only
> > macros, types and prototypes.
>
> It's quite possible for a C header to contain something like:
>
> static const char szCVSid = "$id$";
> static int funcation() { return 99; }
>
> or whatever and by included multiple times.

I am more and more embarrased.  First I was a smart-S.  Now the smart is
gone... :-)

I have completely forgotten about statics.  It is even more embarrasing,
because I have actually used this possibility few times for obscure
purposes.  Back in the previous 1000 years. (Millenium?)

> > I know eggzaktlee.  My questions may seem idiotic but I work with C
from
> > about 1990 and with C++ from about 1992. :-)
>
> I have a few years on you then, newbie :-) :-)

Yeah: I have made the mistake of being born too late and the wrong place.
:-)  Actually programming I have started around 1985(?) with basic and in
1986-7 I was already doing some Z80 assembly.

But I start to feel that I have quite a few years left to go as a newbie
with C++... and systems programming.

> > > the concept of headers is only of interest to the linker
> >
> > You mean to the compiler?  I would be alarmed to see my linker to deal
with
> > #includes...
>
> No, I actually meant neither the compiler not the linker - I actually
> meant to write the preprocessor.

Yeah.  You are right.  But if we take apart linking from compiling - I
meant it that way.  At many systems the precompiler is not a separate
entity (binary/executable).  I mean it wasn't for many.  I guess today it
is in some way.

> There are quite a few "pre-C99" compilers which implemented some form
> of inline as an extention to the language (IIRC, Zortech C/C++ allowed
> inline functions in C as far back as 1988/9 - possibly even earlier).

Sure.  I have used it myself with some of those.  I dunno which was...
Watcom? Borland? MS?...  Meeemories...

WW



---
[ 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                       ]

""White Wolf"" <wolof@freemail.hu> wrote in message news:and0qd$qfg$1@phys-news1.kolumbus.fi...
> "Chris Waters":
> > First of all, what you "K" is wrong: C99 has introduced "inline" to C.
>
> Are there existing commercial implementations of it?  (It is not meant as a
> critique of what you have said, just a question - apropos)

Yes, and a lot of implementations supported it before C99 came out.  It was a quite
common language extension.



---
[ 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                       ]

""White Wolf"" <wolof@freemail.hu> wrote in message news:and14n$qvr$1@phys-news1.kolumbus.fi...
>
> ""Ron Natalie:
> > You can put anything you please in a header.
>
> That is right.  Is it really used like this?  In C if I do that (on many
> platforms I used) if the header had been included into more than one impl.
> file I have got link errors.

Only because you  put multiple (non inline) declarations in it.
Yes, it's not generally the way things are done, but it is not unheard of
to stick code in .h files espeically when trying to implement template-like
constructs in C.

> Well, that was pretty clear to me. ;-)  I am just wondering if using a
> header to include implementation would make any practical sense.


---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis) wrote in message
| news:<m3vg4lx276.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.de (James Kanze) writes:
|
| > [...]
|
| > > > | The only C style cast which has changed meaning is (T const&).
|
| > > > I'm not sure of this one.  I think that something like
|
| > > >    class A { /* ... */ };
| > > >    class B : A { /* ... */ };
|
| > > >    // ...
| > > >    A* p = new B;
| > > >    // ...
| > > >   do_something_with((B*)p);
|
| > > > were doing something more than a reinterpret_cast<>
|
| > > We should be doing a static_cast. And this has not changed its
| > > meaning.
|
| > Without accessibility enforcement, OK, agreed.
|
| > > In C, grosso modo, pointer casts corresponded to reinterpret_cast,
| > > and non pointer casts to static_cast. Simple, clear and easy to
| > > understand.
|
| > Well, even in C you want the following to be a static_cast<>
|
| >   int* p = (int*) malloc(n * sizeof (int));
|
| What is the difference in the semantics between static_cast and
| reinterpret_cast here?

Some think of reinterpret_cast<> as not doing any "adjustment" on
the expression; if the "natural" conversion of void* to int* needs an
adjustment (on the given plateform) then clearly reinterpret_cast<>
isn't good.

| C doesn't have the new style casts,

Certainly C doesn't have the new style casts _syntax_, but that
doesn't mean C doesn't have the *notion* of static_cast<> or
reinterpre_cast<>.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) writes:

[...]

| (IMHO, changing the meaning of a C style
| cast is particularly unjustified, because about the only code which
| should be using them anyway is legacy code.)

I'm not convinced that the only code that will be using a C style is a
legacy code.  New projects can share headers with C and C++ programs.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ 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 Sun, 29 Sep 2002 18:25:32 +0000 (UTC), gdr@integrable-solutions.net
(Gabriel Dos Reis) wrote:

> kanze@gabi-soft.de (James Kanze) writes:

> | (IMHO, changing the meaning of a C style
> | cast is particularly unjustified, because about the only code which
> | should be using them anyway is legacy code.)

> I'm not convinced that the only code that will be using a C style is a
> legacy code.  New projects can share headers with C and C++ programs.

The only C style cast which has changed meaning is (T const&).  It
will not be used in common headers.

John

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) writes:

| On Sun, 29 Sep 2002 18:25:32 +0000 (UTC), gdr@integrable-solutions.net
| (Gabriel Dos Reis) wrote:
|
| > kanze@gabi-soft.de (James Kanze) writes:
|
| > | (IMHO, changing the meaning of a C style
| > | cast is particularly unjustified, because about the only code which
| > | should be using them anyway is legacy code.)
|
| > I'm not convinced that the only code that will be using a C style is a
| > legacy code.  New projects can share headers with C and C++ programs.
|
| The only C style cast which has changed meaning is (T const&).

I'm not sure of this one.  I think that something like

   class A { /* ... */ };
   class B : A { /* ... */ };

   // ...
   A* p = new B;
   // ...
  do_something_with((B*)p);

were doing something more than a reinterpret_cast<> (I would say close
to dynamic_cast<> modulo accessibility).

| It
| will not be used in common headers.

That is a different statement -- which I can happen to agree with.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) wrote in message
news:<3d8ae9df.4096000@207.217.77.21>...

> > I am convinced of what the standard says now, but I wonder if it is
> > what was intended.  I suspect that this behavior represents a change
> > with regards to pre-standard C++, and I am not convinced that this
> > incompatibility was really intended.

> Steve says that he wrote it and intended it, even if he didn't
> implement it.  Why would you doubt?

I don't doubt that 1) Steve wrote it, and 2) he probably meant it.  What
I wonder about is whether he really realized the implications,
particularly with regards to the change of semantics of the old style
cast, and whether the people who voted the change were aware of what the
implications were in the case of casts within hierarchies.  (The promis
of the new style casts was safety.  One aspect of that safety is that if
I write a static_cast within a hierarchy, if it isn't actually up or
down within the hierarchy, the cast is illegal.)

Consider the following:

    struct L { int l ; } ;
    struct R { R(L const&) ; int r ; } ;
    struct D : L, R { int d ; } ;

    int
    main()
    {
        D*          pd = new D ;
        L*          pl = pd ;

        //  Pointers:

        //  Up or down the hierarchy: change pointer to point to correct
        //  sub-object...
        static_cast< R* >( pd ) ;
        (R*)pd ;
        static_cast< R const* >( pd ) ;
        (R const*)pd ;

        //  Laterally, new style cast illegal, old style is reference
        //  cast...
        static_cast< R* >( pl ) ;
        (R*)pl ;
        static_cast< R const* >( pl ) ;
        (R const*)pl ;

        //  References:

        //  Up or down the hierarchy: change reference to refer to correct
        //  sub-object...
        static_cast< R& >( *pd ) ;
        (R&)*pd ;
        static_cast< R const& >( *pd ) ;
        (R const&)*pd ;

        //  Laterally ...
        static_cast< R& >( *pl ) ;          //  illegal
        (R&)*pl ;                           //  reference_cast
        static_cast< R const& >( *pl ) ;    //  create new instance of sub-object
        (R const&)*pl ;                     //  static_cast, new semantics !!

        return 0 ;
    }

I'm bothered about the last two casts for severaly reasons.

I'm especially bothered about the last cast, because it could
potentially break existing code, which *wanted* the reinterpret_cast.  I
also don't like the fact that adding or removing the constructor in R
changes the meaning of this cast.  (Of course, one of the things that I
really liked about the new style casts is that even changing the
hierarchy cannot change the meaning of a static_cast -- it could only
make it illegal.  Or so I thought, until this thread.)

I also don't like the fact that the next to the last cast works
differently than the example for pointers.

Globally, while I would have preferred that the next to the last cast be
illegal, it isn't a big thing.  In practice, the case where there is
just the converting constructor needed doesn't come up enough for this
to be a problem.  On the other hand, I am very bothered by the last cast
silently changing semantics; the whole purpose of continuing to support
the C style casts is, so I thought, legacy code.  And according to the
ARM, the last cast has the semantics of a reinterpret_cast, regardless
of the existance of a conversion constructor or not.

I think that the easiest (and best) solution is to change the definition
of static_cast: the current paragraph 2 should be amended to state that
it only holds if T is not a reference type, and text added to say that
if T is a reference type, the cast is legal *if* the corresponding
pointer cast is legal.  Alternatively, we have to change the description
of a C style cast in 5.4, in order to exclude this possibility.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

"Gabriel Dos Reis":
> kanze@gabi-soft.de (James Kanze) writes:
>
> [...]
>
> | (IMHO, changing the meaning of a C style
> | cast is particularly unjustified, because about the only code which
> | should be using them anyway is legacy code.)
>
> I'm not convinced that the only code that will be using a C style is a
> legacy code.  New projects can share headers with C and C++ programs.

And for what reason would we need a cast in a C header?

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

"Gabriel Dos Reis" writes:
> I'm not sure of this one.  I think that something like
>
>    class A { /* ... */ };
>    class B : A { /* ... */ };

I have just realized: when do you plan to have this in a common C and C++
header?  I don't think any C will compile it.

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

 "Gabriel Dos Reis"writes:
>    A* p = new B;
>    // ...
>   do_something_with((B*)p);
>
> were doing something more than a reinterpret_cast<> (I would say close
> to dynamic_cast<> modulo accessibility).

AFAIK this is a static_cast.  According to my understanding of the
standard.

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

wolof@freemail.hu ("White Wolf") writes:

| "Gabriel Dos Reis" writes:
| > I'm not sure of this one.  I think that something like
| >
| >    class A { /* ... */ };
| >    class B : A { /* ... */ };
|
| I have just realized: when do you plan to have this in a common C and C++
| header?

I think you lost track.  We were discussing C style cast in general.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ 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                       ]

wolof@freemail.hu ("White Wolf") wrote
> For what reason would we need a cast in a C header?

How about:
    You just used fread() to read a variable-length record into
    an array of chars. Your logic determines that a float is
    located at offset 16 in that record, and furthermore it knows
    that 16 is a multiple of the alignment requirement for floats
    on the current hardware.

---
[ 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 Mon, 30 Sep 2002 12:40:29 +0000 (UTC),
gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:

> jpotter@falcon.lhup.edu (John Potter) writes:

> | The only C style cast which has changed meaning is (T const&).

> I'm not sure of this one.  I think that something like

>    class A { /* ... */ };
>    class B : A { /* ... */ };

>    // ...
>    A* p = new B;
>    // ...
>   do_something_with((B*)p);

> were doing something more than a reinterpret_cast<> (I would say close
> to dynamic_cast<> modulo accessibility).

I don't follow you.  We are in 5.4/7 never-never-land.  A C style cast
never does a dynamic_cast.  The first bullet is a derived to base
conversion which is a static_cast to private.  The second bullet is a
derived member to base member which is a static_cast to private.  The
third bullet is base to derived.  Is this a static_cast from private?
It would seem so.  Then, where is the reinterpret_cast?

I think that your example is just an unsafe static_cast which would do
the same thing if you had used new A.

Are you saying that under the ARM rules, all of these including your
example were reinterpret_casts?  No pointer adjustments with MI?
Using reinterpret_cast in your example would be valid.

John

---
[ 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                       ]

gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote in message
news:<m37kh47b07.fsf@soliton.integrable-solutions.net>...
> jpotter@falcon.lhup.edu (John Potter) writes:

> | On Sun, 29 Sep 2002 18:25:32 +0000 (UTC),
> | gdr@integrable-solutions.net (Gabriel Dos Reis) wrote:

> | > kanze@gabi-soft.de (James Kanze) writes:

> | > | (IMHO, changing the meaning of a C style cast is particularly
> | > | unjustified, because about the only code which should be using
> | > | them anyway is legacy code.)

> | > I'm not convinced that the only code that will be using a C style
> | > is a legacy code. New projects can share headers with C and C++
> | > programs.

> | The only C style cast which has changed meaning is (T const&).

> I'm not sure of this one.  I think that something like

>    class A { /* ... */ };
>    class B : A { /* ... */ };

>    // ...
>    A* p = new B;
>    // ...
>   do_something_with((B*)p);

> were doing something more than a reinterpret_cast<>

We should be doing a static_cast.  And this has not changed its meaning.

In C, grosso modo, pointer casts corresponded to reinterpret_cast, and
non pointer casts to static_cast. Simple, clear and easy to understand.
In C++, a C style pointer cast up or down in an inheritance hierarchy
corresponded (and still corresponds) to a static_cast -- leave the
hierarchy, or even go sideways an instant, and it becomes a
reinterpret_cast.  Which is horribly fragile, and makes it difficult to
know what the cast actually does when reading the code.

It was my understanding that this difficulty was one of the major
justifications for introducing the new style syntax (along with avoiding
accidentally changing the type when you just wanted to cast away const).

> (I would say close to dynamic_cast<> modulo accessibility).

And no dynamic verification.  A dynamic_cast without verification is a
static_cast.  (There are limits when multiple inheritance is involved,
but they don't enter into consideration here.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) writes:

| On Mon, 30 Sep 2002 12:40:29 +0000 (UTC),
| gdr@soliton.integrable-solutions.net (Gabriel Dos Reis) wrote:
|
| > jpotter@falcon.lhup.edu (John Potter) writes:
|
| > | The only C style cast which has changed meaning is (T const&).
|
| > I'm not sure of this one.  I think that something like
|
| >    class A { /* ... */ };
| >    class B : A { /* ... */ };
|
| >    // ...
| >    A* p = new B;
| >    // ...
| >   do_something_with((B*)p);
|
| > were doing something more than a reinterpret_cast<> (I would say close
| > to dynamic_cast<> modulo accessibility).
|
| I don't follow you.  We are in 5.4/7 never-never-land.  A C style cast
| never does a dynamic_cast.

Yes, I do know that this is what the standard says.  I'm talking of what
used to be done in pre-standard era -- note my use of "were" in my
previous message.

--
Gabriel Dos Reis                    gdr@integrable-solutions.net

---
[ 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                       ]

 "Allan W":
> wolof@freemail.hu ("White Wolf") wrote
> > For what reason would we need a cast in a C header?
>
> How about:
>     You just used fread() to read a variable-length record into
>     an array of chars. Your logic determines that a float is
>     located at offset 16 in that record, and furthermore it knows
>     that 16 is a multiple of the alignment requirement for floats
>     on the current hardware.

In C header?  Do you mean in a macro?  But the macro will not be compiled
until it gets expanded in the code.  AFAIK C headers contain no code - only
macros, types and prototypes.

--
White Wolf aka Attila @ LMF
ICQ#: 26070936
More ways to contact me:
http://wwp.icq.com/26070936



---
[ 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                       ]

"Gabriel Dos Reis" <gdr@soliton.integrable-solutions.net> az al   bbiakat
   rta a k   vetkezo h   r   zenetben:
m34rc7ffj3.fsf@soliton.integrable-solutions.net...
> wolof@freemail.hu ("White Wolf") writes:
>
> | "Gabriel Dos Reis" writes:
> | > I'm not sure of this one.  I think that something like
> | >
> | >    class A { /* ... */ };
> | >    class B : A { /* ... */ };
> |
> | I have just realized: when do you plan to have this in a common C and
C++
> | header?
>
> I think you lost track.  We were discussing C style cast in general.

I don't think so.  You wrote this:

>>>I'm not convinced that the only code that will be using a C style is a
legacy code.  New projects can share headers with C and C++ programs.<<<

You have been challenged on it and then you have answered with a full C++
example.

WW


---
[ 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                       ]

White Wolf wrote:
>  "Allan W":
>
>>wolof@freemail.hu ("White Wolf") wrote
>>
>>>For what reason would we need a cast in a C header?
>>
>>How about:
>>    You just used fread() to read a variable-length record into
>>    an array of chars. Your logic determines that a float is
>>    located at offset 16 in that record, and furthermore it knows
>>    that 16 is a multiple of the alignment requirement for floats
>>    on the current hardware.

> In C header?  Do you mean in a macro?  But the macro will not be compiled
> until it gets expanded in the code.  AFAIK C headers contain no code - only
> macros, types and prototypes.

First of all, what you "K" is wrong: C99 has introduced "inline" to C.
Second of all, I'm not sure what relevance the fact that a macro doesn't
get compiled till it's expanded has here.  If the macro is used in your
C++ code, and the macro uses a C-style cast (because it's designed so
that it can also be used in C), then the meaning of a C-style cast in
C++ is clearly an issue.

Unless I'm missing something...

---
[ 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                       ]

""White Wolf"" <wolof@freemail.hu> wrote in message news:ancmok$9k7$1@phys-news1.kolumbus.fi...

> In C header?  Do you mean in a macro?  But the macro will not be compiled
> until it gets expanded in the code.  AFAIK C headers contain no code - only
> macros, types and prototypes.

You can put anything you please in a header.   The language does not distinguish
between things that are brought in to the translation unit via #include versus what
was in the original input file.

C has inline functions, so it is quite reasonable to expect to find these in headers.



---
[ 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 19 Sep 2002 23:20:01 GMT, nobody <nobody@localhost.ucar.edu> wrote:

> James Kanze wrote:

> > Just out of curiousity: what did the ARM say about this (C style) cast?

> On page 69 (section 5.4) of the 5th printing (May 1991) it says:

>   An object may be explicitly converted to a reference type X& if
>   a pointer to that object may be explicitly converted to an X*.
>   Constructors or conversion functions are not called as the result
>   of a cast to a reference.

> My reading of the last sentence is that it is treated as
> a reinterpret_cast.

11th printing (Apr 1994).  The next paragraph says it clearly.

   Operations performed on the result of a pointer or reference cast
   refer to the same object as the original (uncast) expression.

Pointer/reference casts do not create new objects.

> 10
> 1092616192
>
> which are the same as Mr. Potter's [I'd bet he's on an x86 platform,
> too].  Clearly, the C-style cast is treated by this ARM compiler as
> a reinterpret_cast.

Any platform with the same 32 bit float standard and a 32 bit int will
do.  Same result on a big endian powerpc.

John

---
[ 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 Tue, 17 Sep 2002 23:07:31 +0000 (UTC),
loewis@informatik.hu-berlin.de (Martin v. =?iso-8859-1?q?L=F6wis?=)
wrote:

> jpotter@falcon.lhup.edu (John Potter) writes:

> > Add line 3 with (Widget const&)x and sufficient other code to see what
> > is happening and you may find that it is interpreted as
> > reinterpret_cast.  That is true for 3.1 and earlier.  How does that
> > compute?

> Given

You missed the point.  The C-style cast (Widget const&)x should be
interpreted as static_cast since that is a valid static_cast.  You
have not tested it.

#include <iostream>
struct Widget {
    int v;
    Widget (int i) : v(i) { }
    };
ostream& operator<< (ostream& os, Widget const& w) {
    return os << w.v;
    }
int main () {
   float x(10);
   const Widget& rw = x;                           // Line 1
   cout << rw << "\n";
   cout << static_cast<const Widget&>(x) << "\n";  // Line 2
   cout << (Widget const&)x << "\n";               // Line 3
   }

My results on a platform are:
10
10
1092616192

The static_cast is right, but the C-style cast is correspondingly
wrong because it is treated as reinterpret_cast.

John

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) wrote in message
news:<3d8ae9df.4096000@207.217.77.21>...
> On Thu, 19 Sep 2002 21:57:48 +0000 (UTC), kanze@gabi-soft.de (James
> Kanze) wrote:
> > Just out of curiousity: what did the ARM say about this (C style) cast?
> > And what did earlier compilers say?

> I suspect that your curiousity is false.  I bet you know full well
> that the ARM says, "Operations performed on the result of a pointer or
> reference cast refer to the same object as the original (uncast)
> expression."

Yes and no.  I don't have a copy of the ARM handy, and it has been some
years since I looked at it.  I generally remember that earlier compilers
treated it as a reinterpret_cast, but my memory has been known to play
tricks on me before.  (Age is getting to me:-).)

> Yes, we all know that the static_cast<T const&> which creates a new
> object is an absolute violation of all prior knowledge about casts.

> > I am convinced of what the standard says now, but I wonder if it is
> > what was intended.  I suspect that this behavior represents a change
> > with regards to pre-standard C++, and I am not convinced that this
> > incompatibility was really intended.

> Steve says that he wrote it and intended it, even if he didn't
> implement it.  Why would you doubt?

What I wrote above was before I read the Steve's posting.  If he says
that that is what he meant, then I suppose that that is what he meant.
I'm still not sure that many of us who voted for it realized the
implications with regards to backwards compatibility.  Had it been
explicitly pointed out to me at the time, I would have voted against it.

IMHO, there are a few too many things that were broken by the standard.
In some cases, we got some major functionality in return.  But the
changes in template name lookup, for example, just lead to confusion,
and now we've subtly changed the meaning of a C style cast in a few
limited situations -- how much code it might really affect, we don't
know, because from the tenor of this thread, I gather that most compiler
implementors didn't know of the change, and most, if not all, compilers
still implement the old rules.  (IMHO, changing the meaning of a C style
cast is particularly unjustified, because about the only code which
should be using them anyway is legacy code.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

jpotter@falcon.lhup.edu (John Potter) wrote in message
news:<3d88da73.3721156@news.earthlink.net>...
> On Tue, 17 Sep 2002 23:07:31 +0000 (UTC),
> loewis@informatik.hu-berlin.de (Martin v. =?iso-8859-1?q?L=F6wis?=)
> wrote:

> > jpotter@falcon.lhup.edu (John Potter) writes:

> > > Add line 3 with (Widget const&)x and sufficient other code to see
> > > what is happening and you may find that it is interpreted as
> > > reinterpret_cast.  That is true for 3.1 and earlier.  How does
> > > that compute?

> > Given

> You missed the point.  The C-style cast (Widget const&)x should be
> interpreted as static_cast since that is a valid static_cast.  You
> have not tested it.

> #include <iostream>
> struct Widget {
>     int v;
>     Widget (int i) : v(i) { }
>     };
> ostream& operator<< (ostream& os, Widget const& w) {
>     return os << w.v;
>     }
> int main () {
>    float x(10);
>    const Widget& rw = x;                           // Line 1
>    cout << rw << "\n";
>    cout << static_cast<const Widget&>(x) << "\n";  // Line 2
>    cout << (Widget const&)x << "\n";               // Line 3
>    }

> My results on a platform are:
> 10
> 10
> 1092616192

> The static_cast is right, but the C-style cast is correspondingly
> wrong because it is treated as reinterpret_cast.

Just out of curiousity: what did the ARM say about this (C style) cast?
And what did earlier compilers say?

I am convinced of what the standard says now, but I wonder if it is what
was intended.  I suspect that this behavior represents a change with
regards to pre-standard C++, and I am not convinced that this
incompatibility was really intended.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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 Kanze wrote:
> [ John Potter wrote: ]
> > You missed the point.  The C-style cast (Widget const&)x should be
> > interpreted as static_cast since that is a valid static_cast.  You
> > have not tested it.
>
> > #include <iostream>
> > struct Widget {
> >     int v;
> >     Widget (int i) : v(i) { }
> >     };
> > ostream& operator<< (ostream& os, Widget const& w) {
> >     return os << w.v;
> >     }
> > int main () {
> >    float x(10);
> >    const Widget& rw = x;                           // Line 1
> >    cout << rw << "\n";
> >    cout << static_cast<const Widget&>(x) << "\n";  // Line 2
> >    cout << (Widget const&)x << "\n";               // Line 3
> >    }
>
> > My results on a platform are:
> > 10
> > 10
> > 1092616192
>
> > The static_cast is right, but the C-style cast is correspondingly
> > wrong because it is treated as reinterpret_cast.
>
> Just out of curiousity: what did the ARM say about this (C style) cast?

On page 69 (section 5.4) of the 5th printing (May 1991) it says:

  An object may be explicitly converted to a reference type X& if
  a pointer to that object may be explicitly converted to an X*.
  Constructors or conversion functions are not called as the result
  of a cast to a reference.

My reading of the last sentence is that it is treated as
a reinterpret_cast.

> And what did earlier compilers say?

It so happens that I keep an ARM-era cfront-based C++ compiler
operational: Sun's C++ 3.0.2, which is part of ProCompiler 2.0.1
for Solaris x86 (released 30 April 1993, updated 22 Jan 1996 with
patch 101205-11).  I have to change <iostream> to <iostream.h> and
comment out line 2 to get the test program to compile, but when I
do so the results are as follows:

10
1092616192

which are the same as Mr. Potter's [I'd bet he's on an x86 platform,
too].  Clearly, the C-style cast is treated by this ARM compiler as
a reinterpret_cast.

nobody

---
[ 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 Thu, 19 Sep 2002 21:57:48 +0000 (UTC), kanze@gabi-soft.de (James
Kanze) wrote:

> Just out of curiousity: what did the ARM say about this (C style) cast?
> And what did earlier compilers say?

I suspect that your curiousity is false.  I bet you know full well
that the ARM says, "Operations performed on the result of a pointer or
reference cast refer to the same object as the original (uncast)
expression."

Yes, we all know that the static_cast<T const&> which creates a new
object is an absolute violation of all prior knowledge about casts.

> I am convinced of what the standard says now, but I wonder if it is what
> was intended.  I suspect that this behavior represents a change with
> regards to pre-standard C++, and I am not convinced that this
> incompatibility was really intended.

Steve says that he wrote it and intended it, even if he didn't
implement it.  Why would you doubt?

John

---
[ 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 19 Sep 2002 23:20:01 GMT, nobody <nobody@localhost.ucar.edu> wrote:

> James Kanze wrote:

> > Just out of curiousity: what did the ARM say about this (C style) cast?

> On page 69 (section 5.4) of the 5th printing (May 1991) it says:

>   An object may be explicitly converted to a reference type X& if
>   a pointer to that object may be explicitly converted to an X*.
>   Constructors or conversion functions are not called as the result
>   of a cast to a reference.

> My reading of the last sentence is that it is treated as
> a reinterpret_cast.

11th printing (Apr 1994).  The next paragraph says it clearly.

   Operations performed on the result of a pointer or reference cast
   refer to the same object as the original (uncast) expression.

Pointer/reference casts do not create new objects.

> 10
> 1092616192
>
> which are the same as Mr. Potter's [I'd bet he's on an x86 platform,
> too].  Clearly, the C-style cast is treated by this ARM compiler as
> a reinterpret_cast.

Any platform with the same 32 bit float standard and a 32 bit int will
do.  Same result on a big endian powerpc.

John

---
[ 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 Tue, 17 Sep 2002 23:07:31 +0000 (UTC),
loewis@informatik.hu-berlin.de (Martin v. =?iso-8859-1?q?L=F6wis?=)
wrote:

> jpotter@falcon.lhup.edu (John Potter) writes:

> > Add line 3 with (Widget const&)x and sufficient other code to see what
> > is happening and you may find that it is interpreted as
> > reinterpret_cast.  That is true for 3.1 and earlier.  How does that
> > compute?

> Given

You missed the point.  The C-style cast (Widget const&)x should be
interpreted as static_cast since that is a valid static_cast.  You
have not tested it.

#include <iostream>
struct Widget {
    int v;
    Widget (int i) : v(i) { }
    };
ostream& operator<< (ostream& os, Widget const& w) {
    return os << w.v;
    }
int main () {
   float x(10);
   const Widget& rw = x;                           // Line 1
   cout << rw << "\n";
   cout << static_cast<const Widget&>(x) << "\n";  // Line 2
   cout << (Widget const&)x << "\n";               // Line 3
   }

My results on a platform are:
10
10
1092616192

The static_cast is right, but the C-style cast is correspondingly
wrong because it is treated as reinterpret_cast.

John

---
[ 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 Russell Kuyper Jr." wrote:
>
> Attila Feher wrote:
> >
> > Informal, because I have no idea how to do a formal one properly and
>
> Follow the links that appear at the bottom of every message on this
> newsgroup. Eventually you'll end up at
> <http://www.jamesd.demon.co.uk/csc/faq.html#B15>.

My post was rather a "bait" to start a de-bait (lame pun intended) so
that's why I did not look for formal rules.  I thought that if I move to
change the standard someone (who knows how things work) will come and
put my mind on the right track. :-)  Am I a stinker? ;-)  Thanx for the
link, I am reading it.

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                       ]

jpotter@falcon.lhup.edu (John Potter) writes:

> Add line 3 with (Widget const&)x and sufficient other code to see what
> is happening and you may find that it is interpreted as
> reinterpret_cast.  That is true for 3.1 and earlier.  How does that
> compute?

Given

#include <stdio.h>
struct Widget {
    int y;
    Widget(int);
};

Widget::Widget(int x){
  y = 2*x;
  printf("ctor\n");
}

int main() {
  int x = 10;
  printf("%d\n", static_cast<Widget const &>(x).y);
}

I get, with g++ 3.1 on Sola

ctor
20

so it seems to me that it implements it correctly.

Regards,
Martin

---
[ 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                       ]

Informal, because I have no idea how to do a formal one properly and
because my suggested solution may not be adequate - I am no language
lawyer - only a wannabie. ;-)

==================
Problem statement:

Simon says (5.2.9/2):

An expression e can be explicitly converted to a type T using a
static_cast of the form static_cast<T>(e) if the declaration "T (e);"
is well formed, for some invented temporary variable t (8.5).

Now according to this, Scott Meyers example should work:

struct Widget {
  Widget(int);
};

int main() {
  int x = 10;
  Widget const &rw = x;              // Line 1
  static_cast<Widget const &>(x);     // Line 2
}

But most of the compilers refuse compiling Line 2.  (Most interestingly
having Widget changed to double works with the Sun 6.1 compiler.)

There is clearly a confusion here and the standard seems to be too
liberal - according to the (very few) explanations I have seen here.


=====================
Possible explanation:

Stroustrup says (TCPL Spec. Ed.; 6.2.7; pg. 130):

The static_cast operator converts between related types such as one
pointer type to another in the same class hierarchy, an enumeration type
to an integral type, or a floating point type to an integral type.

Looking into this sentence, especially this part:

"The static_cast operator converts between related types"

it suggests that a static_cast will not convert in more than one step!
The examples support this understanding.  The above Widget code requires
two step conversion: convert int to Widget, then binding the reference.
This is clearly two steps.  (What is confusing is that the same happens
in case of int to a reference to a constant double, and that works.)


============
Proposal #1:

The first sentence of 5.2.9/2 should be changed to include the above
mentioned restriction.  I find my wording (one step conversion) to
vague, so I believe a better one should be presented.  The above example
(and the one with the int to const ref double?) could be given as an
explanation of what was meant.

Consequences of this changes has to be thoroughly examined so that it
will not forbid static_casts, which were intended to be valid.


============
Proposal #2:

_If_ the 5.9.2/2 is really intended to mean what it says, The Comitee
should anyways create some sort of defect report - saying that majority
of implementation are failing to obey 5.2.9/2, and a clarification
action is needed.  Then the appropriate explanation with examples can be
oficially be in the documentation provided by the working group, so
compiler implementors would be warned to follow the standard: probably
with the above code as an example given. (Telling it should work.)


============

Please give your thoughts and hints about the issue!  I am especially
eager to see the words of EDG people and other experienced compiler
implementors.  Please do not give guesses in this thread, I would like
to collect here the bare facts of how implementors understand the
situation and what is behind the reason of the decision to non-conform
(or what did I miss if they think it does conform).  (If you have
guesses please post answer them to the old thread I have made - and
which is completely empty: cast of mind, or to Scott's thread:
static_cast to ref-to-const.)

TIA, 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                       ]

Attila Feher wrote:
>
> Informal, because I have no idea how to do a formal one properly and

Follow the links that appear at the bottom of every message on this
newsgroup. Eventually you'll end up at
<http://www.jamesd.demon.co.uk/csc/faq.html#B15>.

---
[ 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                       ]

Attila.Feher@lmf.ericsson.se (Attila Feher) writes:

> Informal, because I have no idea how to do a formal one properly and
> because my suggested solution may not be adequate - I am no language
> lawyer - only a wannabie. ;-)

There are guidelines for posting defect reports, at

http://groups.google.com/groups?selm=7j48m1%2440b%241%40engnews1.eng.sun.com&output=gplain

They explain that a defect must be one of "error", "inconsistency",
"ambiguity", "omission", "impossible to implement". My favourite
example is
[The standard
- says objects are red in one place, blue in another (inconsistency)

Your report seems to fall in none of these categories. Your problem
statement is

> But most of the compilers refuse compiling Line 2.  (Most interestingly
> having Widget changed to double works with the Sun 6.1 compiler.)
>
> There is clearly a confusion here and the standard seems to be too
> liberal - according to the (very few) explanations I have seen here.

That suggest that you consider this either:
- unimplementable (most compilers refuse compiling line 2). Notice
  that g++ 3.2 does compile your example, so it cannot be
  unimplementable.

- ambiguous (there is clearly confusion), i.e. the standard does
  not say how to deal with this example. As you elaborate, the standard
  clearly says how to deal with that example, so it can't be ambiguous.

- inconsistent (there is clearly confusion). However, that would
  require that there is a different place in the standard that
  suggests that this example should be ill-formed. You have not given
  any other reference to the standard. You have given references to
  the literature, which are irrelevant in determining whether this is
  a defect.

I think it would be best if the standard is not changed. Compilers can
then feel obliged to implement it correctly, and sooner-or-later,
users will see consistent behaviour across implementations.

Regards,
Martin

---
[ 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 Sun, 15 Sep 2002 22:59:58 +0000 (UTC),
loewis@informatik.hu-berlin.de (Martin v. =?iso-8859-1?q?L=F6wis?=)
wrote:

> - unimplementable (most compilers refuse compiling line 2). Notice
>   that g++ 3.2 does compile your example, so it cannot be
>   unimplementable.

Add line 3 with (Widget const&)x and sufficient other code to see what
is happening and you may find that it is interpreted as
reinterpret_cast.  That is true for 3.1 and earlier.  How does that
compute?

John

---
[ 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 Sun, 15 Sep 2002 22:52:29 +0000 (UTC), jsa@edg.com (J. Stephen
Adamczyk) wrote:

> In article <3D81FD9B.6F2E3B@lmf.ericsson.se> Attila.Feher@lmf.ericsson.se (Attila Feher) writes:

> >struct Widget {
> >  Widget(int);
> >};
> >
> >int main() {
> >  int x = 10;
> >  Widget const &rw = x;              // Line 1
> >  static_cast<Widget const &>(x);     // Line 2
> >}

> In the opinion of this EDG person, who also happens to be the one who
> came up with the formulation for static_cast in the standard, the
> standard means what it says (and EDG's front end has a bug on this
> example).

Ok, and thanks.  Now what is this?

   (Widget const&)x;

It seems that it can be interpreted as static_cast.  At least one
compiler that accepts line 2 interprets this as reinterpret_cast.

John

---
[ 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                       ]