Paul Meyerholtz <pholtz@ix.netcom.com> wrote:
> Here is an example of resources, how they are loaded and released
> int the Macintosh environment.  [...]
> How does static_cast add anything to this code?

It has added visible evidence of the foolishness of a design where the C
language bindings for the system API use types to distinguish between
different sorts of "handles", but where the actual system API itself treats
the handles as the same type and can operate upon them as generic handles.
(-:

As Jim Cobban has pointed out, this has been forced upon you by the C-centric
design of the language bindings for your system API.

Also: You should, strictly speaking, be using reinterpret_cast<> here, not
static_cast<>.  You are changing a value from one handle type to another
handle type, but without the intention of changing the underlying bit pattern
of the object representation.  reinterpret_cast<> is the correct tool for that
job, not static_cast<>.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$r38btf$jpm$1@firewall.thermoteknix.co.uk>,
K.Hagan@thermoteknix.co.uk says...

[ ... ]

> (Of course, my ability to find this out is a result of their ugliness.)
> I know that there are a handful of C-style casts in there too, and if
> anyone has a regular expression for C-style casts, could they post
> it so that I can root them all out, please?

I'm reasonably certain that there's no such thing as an RE that can
dependably recognize a C-style cast.  In essence, finding a C-style
cast requires verifying that what's between the parentheses specifies
a type, and distinguishing a type takes nearly a full-blown C++
parser, not anything you can squeeze into an RE.

Even after you've figured out that what's in the parens is a type,
you're not entirely home free -- C and C++ both allow you to put in
parentheses in places they're not really accomplishing anything if
you happen to feel like it.  For example, something like:

 int (x);

is a legal definition of x as a variable.  If x had already been
defined, and this was in the middle of an expression, exactly the
same text could/would be a functional-style cast of x's value to an
int.  I haven't tried to verify it for certain, but I believe that at
least:

 (int) x;

is illegal as a definition, so that saves you a _little_ bit of
trouble, but probably not a whole lot; I'm pretty sure it still
leaves you needing nearly a full-blown C++ parser to dependably find
C-style casts.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

TiTi wrote:
>
> Paul Meyerholtz <pholtz@ix.netcom.com> wrote:
>> I agree with the point to make the other casts ugly, but in some...
>
> IMO, they're not.
...

That's your opinion; I agree that they are ugly.  C had no keywords
longer than eight characters, but C++ blew a hole in that.

> ...
> Bad choice. C-style casts may disappear in the following version of
> the standard, and what will you do then? Indeed, use C++-style casts.
> You *will*   have to learn to use them if you're coding C++, whether
> you like it or not.

Kicking and screaming, probably.

And what are you going to do when the next C++ introduces new
keywords, such as 'restrict'?  How immune is your code today from
changes to be made some years from now?

Of course there's nothing to stop you from simplifying those extra
long keywords a little bit:

    // mydefs.hpp

    #define scast        static_cast
    #define ccast        const_cast
    #define dynamic      dynamic_cast
    #define reinterpret  reinterpret_cast

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:
....
> Here is an example of resources, how they are loaded and released int
> the Macintosh environment.  Much code is snipped.
>
>         PicHandle pictureHdl = GetPicture(rPictureResourceID);
>     ...
>         HNoPurge((Handle) pictureHdl);
>         DrawPicture(pictureHdl,&pictureRect);
>         HPurge((Handle) pictureHdl);
>         ReleaseResource((Handle) pictureHdl);
>
>         StringHandle stringHdl = GetString(rStringResourceID);
>         ...
>         DrawString(*stringHdl);
>
>         ReleaseResource((Handle) stringHdl);
>
> This is very Macintosh oriented, but when you load reasources they are
> usually of the type that you load, a picture handle is "PicHandle", a
> string handle is "stringHdl".  When we operate with these handles,
> sometimes we use the native type, and sometimes we need to 'upgrade' the
> handle to a generic "Handle" type.
>
>         HNoPurge(static_cast<Handle>(pictureHdl));
>         DrawPicture(pictureHdl,&pictureRect);
>         HPurge(static_cast<Handle>(pictureHdl));
>         ReleaseResource(static_cast<Handle>(pictureHdl));
>
> How does static_cast add anything to this code?
>
> Paul

By making it easier to locate the cases where the casting is done.
Casting is always risky, requiring special care. When examining code,
casts should stand out, catching your eye, forcing you to think about
whether or not the possible dangers they create have been avoided. It
should be easy to locate all of the casts in a given piece of code, for
quick review. That isn't possible with old-style casts, nor with any of
your suggested replacements. It's inherently not possible without the
use of a reserved keyword, and 's' (your suggestion) is far too short an
identifier to be made a new reserved keyword. 'static_cast' is a bit too
long, 'cast' might have been better, but at this point there's a large
existing code base using static_cast<>, and I wouldn't recommend
changing the name used.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:

> Hyman Rosen wrote:

> > Paul Meyerholtz <pholtz@ix.netcom.com> writes:
> > > When programing for the Mac, lots of casts are needed, mostly of the
> > > static_cast variety.  But I find it difficult to put static_cast<>
> > > everywhere a normal C style cast is

> > The canonical answer is to create C++ functions and classes which
> > encapsulate the code which requires the casts. If you could post an
> > example of the kind of code which is giving you problems, perhaps we
> > could suggest a solution.

> Here is an example of resources, how they are loaded and released int
> the Macintosh environment.  Much code is snipped.

>         PicHandle pictureHdl = GetPicture(rPictureResourceID);
>     ...
>         HNoPurge((Handle) pictureHdl);
>         DrawPicture(pictureHdl,&pictureRect);
>         HPurge((Handle) pictureHdl);
>         ReleaseResource((Handle) pictureHdl);

>         StringHandle stringHdl = GetString(rStringResourceID);
>         ...
>         DrawString(*stringHdl);

>         ReleaseResource((Handle) stringHdl);

> This is very Macintosh oriented, but when you load reasources they are
> usually of the type that you load, a picture handle is "PicHandle", a
> string handle is "stringHdl".  When we operate with these handles,
> sometimes we use the native type, and sometimes we need to 'upgrade' the
> handle to a generic "Handle" type.

>         HNoPurge(static_cast<Handle>(pictureHdl));
>         DrawPicture(pictureHdl,&pictureRect);
>         HPurge(static_cast<Handle>(pictureHdl));
>         ReleaseResource(static_cast<Handle>(pictureHdl));

> How does static_cast add anything to this code?

> Paul

You're right, static_cast doesn't help. However, you provide C-code,
in which C-casts are to be expected.

In C++, you might have

class Resource {
 Handle h;
 // I assume Handle is small, about the size of a pointer
 // Therefore we pass by value.
protected:
 Resource(Handle _h):h(_h);
 /* A derived class must pass a valid resource handle */
public:
 operator Handle() { return h; }
 virtual ~Resource() { ReleaseResource(h); }
}

class Picture : public Resource{
 PicHandle(rPictureResourceID):
  Resource(static_cast<Handle>(GetPicture(rPictureResourceID)))
  { /***/ }
 operator PicHandle() { return static_cast<PicHandle>(h); }
}

The two casts are unavoidable, since C doesn't have inheritance. You must
do a one-time type conversion, to establish the relation between Handle and
PicHandle. But once we're in C++'s domain, we don't have to worry about this:

Picture p(rPictureResourceID);

HNoPurge(p);
DrawPicture(p);
HPurge(p);

A similar wrapper can be added to StringHandle.
Note that ReleaseResource is now handled by the
destructor of Picture, via the base destructor.

Michiel Salters

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Cogen wrote:
>
>
> I think the choice standard names was very poor. I will not clutter my code
> with those monstrosities. Completely out of character with names used
> elsewhere in C++.

Quite the contrary. In C++, every portable and safe conversion can occur
without the use of any casts. If you write a cast, it is an indication
that
you are doing something unportable or dangerous. The names of the casts
were deliberatly chosen to be ugly and highly visible. It also makes
them
easy to find with a text editor. When porting a program to a new
environment,
you probably need to revisit any casts in the program (because they are
unportable or dangerous), and searching for _cast will find them.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <200004182026.QAA18702@ll.mit.edu>,
  David Cogen <cogen@ll.mit.edu> wrote:
> > how about
> >
> > s<int>(x)   or even    <int>(x)
>
> In one of my standard header files I have:
>
>     #define scast static_cast
>     #define ccast const_cast
>     #define dcast dynamic_cast
>     #define rcast reinterpret_cast

Why in the heck would you use a macro for this?  Use a template.

> I think the choice standard names was very poor. I will not clutter
my code
> with those monstrosities. Completely out of character with names used
> elsewhere in C++.

How is it out of character?  The only hint you give here can be found
below, so see what I have to say there.

> Imagine if the designers, not approving of the use of goto, decided
to name it
>
>   change_program_location_unstructured_to

'goto' is perfectly readable and clearly states the intended
action.  'static_cast' is perfectly readable and clearly states the
intended action.  'scast' is only arguably readable, and it definately
doesn't clearly state the intention.  I honestly can think of no way to
rename these casts that would leave in the instant comprehension you
receive from the current names.  So you analogy is flawed from the
beginning.

I don't know why people in this thread are trying to assert that the
names are long to discourage their use.  This might make sense if they
were the only casts available and the designers were trying to
discourage casting all together (even though I don't even buy that,
since casts are obviously necessary evils).  However, since we have C
style casts that will work (even if unsafely) in every case where a C++
style cast could be used then the only thing this would do would be to
encourage the use of C casts instead.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38FC8AAC.52285A10@ix.netcom.com>,
Paul Meyerholtz  <pholtz@ix.netcom.com> wrote:
>When programing for the Mac, lots of casts are needed, mostly of the
>static_cast variety.

Why are all the casts necessary?  NNOT, but inquiring minds want to
know (who've never programmed on Macs).

>1 - alot of typing

So do long variable names, but they make code more readable.  Please,
this is really a dismissible argument.  The time invested in typing
the code the first time is trivial compared to the rest of the time
developing/testing, etc.  Furthermore, many editors can define
abbreviations (I use VIM) so that typing something like "s_c" or
"scast" expands to "static_cast".

>2 - actually makes the program more unreadable
>
>But, if I do C style casts, then I loose the protection of static_cast.
>I may actually be doing another worse kind of cast and not know about it.
>
>So my question is, can we make static_cast's easier.  If it were easier,
>more people would use it, get the extra protection of a static_cast and
>probably use the other types of casts when needed.  So instead of
>
>static_cast<int>(x)
>
>how about
>
>s<int>(x)   or even    <int>(x)

Can you show a real world example of how it is more unreadable?


Also, one thing that others have failed to mention (and that your
shortcuts have eliminated) is the ability to grep for casts in code.
Another person suggested #defining scast for static_cast (which seems
to me to be a more reasonable solution, though I don't think it buys
much--just 6 characters out of a potentially complex expression).
--
The above comments represent my opinion only, and in no way
reflect the opinions or policy of Intel Corp.

Mark Ping     mping@scdt.intel.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article 38FC8AAC.52285A10@ix.netcom.com, Paul Meyerholtz at
pholtz@ix.netcom.com wrote on 4/19/00 6:09 AM:

> I am still pretty new to C++ programing, and also new to Macintosh
> programing both of which I am trying to learn.
>
> Right now I am translating C Mac programs to C++.  Not much translation
> is really necessary as most C programs will run with a C++ compiler with
> very few or no changes.  But I am translating to the correct 'style' of
> C++ also, using the new tools C++ gives me, e.g. overloaded and inline
> fuctions, better const etc.  The programs are too short for any real OOP.
>
> When programing for the Mac, lots of casts are needed, mostly of the
> static_cast variety.

I programmed for the mac for 11 years, and never found this to be the case.
Usually the best thing you can do is to isolate the ugliness of casting
within one or two functions, when it is neccessary to cast at all. Then you
just re-use the functions. The reason casts are ugly is that they are a
likely source of bugs. If you can avoid writing them over and over, you
minimize the number of potential bugs. Try to factor your uses of casting
out.

Good luck,
Dave

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
....
> I don't know why people in this thread are trying to assert that the
> names are long to discourage their use.  This might make sense if they
> were the only casts available and the designers were trying to
> discourage casting all together (even though I don't even buy that,
> since casts are obviously necessary evils).  However, since we have C
> style casts that will work (even if unsafely) in every case where a C++
> style cast could be used then the only thing this would do would be to
> encourage the use of C casts instead.

You're ignoring the historical developement. The C style casts are
supported  for backwards and cross-language compatibility, not because
they're consistent with the goals of C++ design. The actual language
design is a compromise. If compability were not an issue, I'm sure that
the C-style cast would be implemented, if at all, by some syntax such as
total_cast<>, and that its use would be strongly discouraged.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8dknog$sd8$1@nnrp1.deja.com>, sirwillard@my-deja.com says...
> since casts are obviously necessary evils).  However, since we have C
> style casts that will work (even if unsafely) in every case where a C++
> style cast could be used
I don't think there's a C cast equivalent to dynamic_cast.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38FD64F0.2D25BFD2@sun.com>, stephen.clamage@sun.com
says...

[ ... ]

> Quite the contrary. In C++, every portable and safe conversion can occur
> without the use of any casts. If you write a cast, it is an indication
> that you are doing something unportable or dangerous.

I think it's worth mentioning here that this refers only to the USE
of explicit casts.  Especially if taken out of context, the second
sentence above could easily be taken as saying that something like:

class X {
 int x;
public:
 operator int() { return x; }
};

is necessarily dangerous and non-portable, and I'm _quite_ certain
that's not what you meant at all.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sirwillard@my-deja.com wrote:
>
> David Cogen <cogen@ll.mit.edu> wrote:
>> > how about
>> >
>> > s<int>(x)   or even    <int>(x)
>>
>> In one of my standard header files I have:
>>
>>     #define scast static_cast
>>     #define ccast const_cast
>>     #define dcast dynamic_cast
>>     #define rcast reinterpret_cast
>
> Why in the heck would you use a macro for this?  Use a template.

Is this correct?

    template <class L, class R>
    L scast(R e)
    {
        return static_cast<L>(e);
    }

    ... x = scast<Type>(expr);     // ?

Of course, since we really only need to simplify the use of
static_cast (the other three should remain ugly because they indicate
suspicious conversions), we can do this:

    #define static(T,e)  static_cast<T>(e)

    ... x = static(Type, expr);

This doesn't define any new keywords or identifiers.

[Should I expected groans or grins?]

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Am 21.04.00, 12:25:47, schrieb Paul Meyerholtz <pholtz@ix.netcom.com> zum=
=20
Thema Re: static_cast, can we simplify it?:


> Hyman Rosen wrote:
> > The canonical answer is to create C++ functions and classes which
> > encapsulate the code which requires the casts. If you could post an
> > example of the kind of code which is giving you problems, perhaps we
> > could suggest a solution.

I strongly suggest following this advice. Small wrapper classes that add=20
automatic cleanup to resource management tasks (like GetXXX -=20
ReleaseResource below) or other temporary 'scoped' changes (like HNoPurge=
=20
- HPurge) will also encapsulate the casts needed to deal with a C API. In=
=20
such an isolated scope noone should object if the casts' effect (and=20
danger/nonportability) is spelled out by using new style casts.

I'll add one nit below.
=20
> Here is an example of resources, how they are loaded and released int
> the Macintosh environment.  Much code is snipped.

>       PicHandle pictureHdl =3D GetPicture(rPictureResourceID);
>     ...
>       HNoPurge((Handle) pictureHdl);
>       DrawPicture(pictureHdl,&pictureRect);
>       HPurge((Handle) pictureHdl);
>       ReleaseResource((Handle) pictureHdl);

> This is very Macintosh oriented, but when you load reasources they are
> usually of the type that you load, a picture handle is "PicHandle", a
> string handle is "stringHdl".  When we operate with these handles,
> sometimes we use the native type, and sometimes we need to 'upgrade' th=
e
> handle to a generic "Handle" type.

>       HNoPurge(static_cast<Handle>(pictureHdl));
>       DrawPicture(pictureHdl,&pictureRect);
>       HPurge(static_cast<Handle>(pictureHdl));
>       ReleaseResource(static_cast<Handle>(pictureHdl));

> How does static_cast add anything to this code?

IIRC it will show that this code is even more dangerous/non-portable than=
=20
you assume - it should not compile. It's been a while since I did native=20
Mac toolbox work, but I think 'Handle' really is 'void**' (and should=20
have been 'void* volatile const *' for user code), while 'XXXHandle' is=20
'XX**'. By my token you need a reinterpret_cast for that.

-- J=F6rg Barfurth
=20

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Thu, 27 Apr 2000 20:10:28 CST, David R Tribble <david@tribble.com> pisze:

>     #define static(T,e)  static_cast<T>(e)

Try to cast to pair<string,int>  :-)

--
 __("<    Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.137104aa9291d1fd989680@news.erols.com>,
  Eddie Velasquez <evelasqu@bigfoot.com> wrote:
> In article <8dknog$sd8$1@nnrp1.deja.com>, sirwillard@my-deja.com
says...
> > since casts are obviously necessary evils).  However, since we have
C
> > style casts that will work (even if unsafely) in every case where a
C++
> > style cast could be used
> I don't think there's a C cast equivalent to dynamic_cast.

The C cast isn't really equivalent to any of the other casts.  However,
any where you have a C++ cast you can replace it with a C cast.  That's
why I said "even if unsafely".  The original thread stated that
programmers might prefer a C cast over a static_cast because of the
typing, but this is really no safer than using a C cast over a
dynamic_cast.  The functionality is not the same for either case.  If
the names were chosen to discourage their use when a C cast is simple
yet less safe then I see a flaw in the logic for choosing the name.

Someone else mentioned that I didn't consider historical facts when I
stated this.  That's only partially true.  I was not aware that Mr.
Stroustrup was quoted as saying this was why they chose the names they
did, so in this respect I did miss some historical facts.  However,
what the poster was trying to say was that I was forgetting that the C
style casts must exist for historical reasons.  This was not my
mistake.  Given that the C style casts must exist it makes no sense to
choose ugly names for the safer C++ casts to discourage their use,
since that would only lead to people preferring C style casts.
Personally, I don't think the names for the C++ casts are unwieldy like
others are claiming, but if the intent was to make them so then I think
the intent was severely flawed.  Just MHO.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8eadd1$v8e$1@nnrp1.deja.com>, sirwillard@my-deja.com writes
>The C cast isn't really equivalent to any of the other casts.  However,
>any where you have a C++ cast you can replace it with a C cast.

But definitely not to do the same thing. In a context of multiple
inheritance c-casts do not hack it even for purely static_casts.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marcin 'Qrczak' Kowalczyk wrote:
>
> Thu, 27 Apr 2000 20:10:28 CST, David R Tribble <david@tribble.com> pisze:
>
> >     #define static(T,e)  static_cast<T>(e)
>
> Try to cast to pair<string,int>  :-)

That should not be a problem.

Remember that you can't create merge tokens accidently via macro
substitution.  The adjacent ">" and ">" that occur due to macro
substitution cannot be interpreted as ">>" (right shift).

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <v0ceBcC9RXC5Ewav@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <8eadd1$v8e$1@nnrp1.deja.com>, sirwillard@my-deja.com
writes
> >The C cast isn't really equivalent to any of the other casts.
However,
> >any where you have a C++ cast you can replace it with a C cast.
>
> But definitely not to do the same thing. In a context of multiple
> inheritance c-casts do not hack it even for purely static_casts.

No, they don't do the same thing.  Again, I never claimed they did.
I'd not recommend using a C style cast in modern code _ever_.  This
doesn't change anything I've said.  If the newer casts are so ugly that
they discourage use then programmers will look for alternatives, and
the less safe C style casts are an easy alternative (even if the full
functionality isn't the same).  There are very few actual idioms that
use the newer casts that couldn't be done with C style casts that are
actually in prevelant use (there are a few with dynamic_cast, but
they're discouraged in efficient and robust designs).  Yes, it's less
safe.  No, it doesn't pay any attention to static or dynamic type
information.  These are the reasons why the newer casts should be
preferred.  But only rarely will the C style cast not work at all.  So
the logic of choosing ugly names for the new casts still seems like
poor logic to me, since most of the time users would just revert back
to the C cast which is often much less safe.

*shrugs*  I still don't think the new casts are really that bad
though.  This complaint seems as flawed as the logic of choosing to use
an unsavory name to discourage use.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Thu, 27 Apr 2000 20:07:48 CST, Jerry Coffin <jcoffin@taeus.com>
wrote:

>In article <38FD64F0.2D25BFD2@sun.com>, stephen.clamage@sun.com
>says...
>
>> Quite the contrary. In C++, every portable and safe conversion can occur
>> without the use of any casts. If you write a cast, it is an indication
>> that you are doing something unportable or dangerous.
>
>I think it's worth mentioning here that this refers only to the USE
>of explicit casts.  Especially if taken out of context, the second
>sentence above could easily be taken as saying that something like:
>
>class X {
> int x;
>public:
> operator int() { return x; }
>};
>
>is necessarily dangerous and non-portable, and I'm _quite_ certain
>that's not what you meant at all.

Assuming you meant your example as a fragment of a complete class
definition, I don't see anything unportable. (If this is the whole
class definition, you can return an uninitialized value via the
conversion operator.)

Type conversion operators are often considered dangerous in the sense
that they can be applied when you don't intend a conversion to occur.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sun, 30 Apr 2000 02:21:04 CST, Steve Clamage <stephen.clamage@sun.com> pisze:

> > >     #define static(T,e)  static_cast<T>(e)
> >
> > Try to cast to pair<string,int>  :-)
>
> That should not be a problem.

The comma is the problem.

One could do
    #define psi pair<string,int>
    static(psi,e)
but this scheme breaks if a macro like static needs to pass its
argument to another macro. This has beaten me in practice.

--
 __("<    Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8ectss$och$1@nnrp1.deja.com>, sirwillard@my-deja.com writes
>But only rarely will the C style cast not work at all.

Well that depends on your definition of 'work'. Yes they will compile
and usually do something. But too often C-style casts applied to complex
C++ objects will not do what you expect/want.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <stephen.clamage@sun.com> writes:

>Marcin 'Qrczak' Kowalczyk wrote:
>>
>> Thu, 27 Apr 2000 20:10:28 CST, David R Tribble <david@tribble.com> pisze:
>>
>> >     #define static(T,e)  static_cast<T>(e)
>>
>> Try to cast to pair<string,int>  :-)
>
>That should not be a problem.

You obviously didn't try it, did you? ;-)

>Remember that you can't create merge tokens accidently via macro
>substitution.  The adjacent ">" and ">" that occur due to macro
>substitution cannot be interpreted as ">>" (right shift).

That's not the problem.  The problem is that

 static(pair<string,int>,e)

has *three* arguments, `pair<string', `int>', and `e'.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"TiTi" <cenTipod@anTi.com> writes:

|>  > defeats the purpose of the different casts.  Leave the other three
|>  > alone, but make static casts easier so people will use it instead o=
f
|>  > C-style casts.

|>  Bad choice. C-style casts may disappear in the following version of
|>  the standard, and what will you do then? Indeed, use C++-style
|>  casts. You *will*=A8have to learn to use them if you're coding C++,
|>  whether you like it or not.

I wouldn't bet on it.  They're not even deprecated in the current
standard.

In Fortran, EQUIVALENCE has been deprecated ever since I can remember
(and that is a long time), but it's still there.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:

> [many snips]

> I see this is going to be a hard sell, so let me make my case a point at
> a time.

OK, then I'll tackle them a point at a time.

> 1 - in some environments static_casts are necessary and frequently used.
>  There is no way around it, it is not flawed or bad coding, it is a fact
> of life.

I doubt if there are cases in which more than a few percent (say 10%) of
the expressions need to be cast.

> 2 - because of the ugliness and hard to read code it creates,
> programmers who have to do many static casts often just use the c-style cast

The code it creates is for many other programmers quite clear. After all,
the token clearly states what happens.

> 3 - yes, I agree that the casts as now defined are good.  Unfortunately
> you can create a perfect tool, but if no one uses it, it doesn't do any good.

That's what coding standards are for. New code should adhere to new
coding standards, and they should forbid old-style casts.

> 4 - the use of c-style cast is so prevalent that if they take it out of
> the standard in the future, I am sure that there will be some option box
> I will be able to check to allow c-style casts.  Programmers will demand
> it, it will be provided.

Yes? I'm missing the point here. C++, in the '98 standard allows them,
and future (Cpp08?) standards might not. However, compilers probably
will offer a single switch to toggle between thw two standards.

> 5 - if the use of static_casts was made easier, more programmers would
> use it, and then gain the benifit of the other casts, because if they
> used the simpler static_cast and tried the other types of casts, the
> compiler would give an error.

This is probably untrue. Making static_casts easier is close to
impossible. It's of course possible to shorten the name, but if
they really are used that often, a programmer can add a macro.

> 6 - since static casts are the least dangerous of the types of casts,
> not much is lost in making the static_cast easier to use

I think dynamic_cast is safer, in that it will throw an exception, or
return a NULL pointer if the cast is wrong.

> 7 - if static_casts were easier, fewer programmers would use C-style
> casts and the level of programming would be raised.

If the standard is changed, fewer programmers would take it seriously
and the level of programming would be decreased.

> 8 - I am NOT promoting the changing of the other three casts, only static_casts

The fact the you don't want to change the other cast will make static_cast
less like the other casts, creating confusion.

> That's it, if this doesn't convince more people, nothing will
> Paul

Finally, a point with which I agree :)

Michiel Salters

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul Meyerholtz" <pholtz@ix.netcom.com> wrote in message
news:38FD07E9.2D39DD87@ix.netcom.com...
>
> I agree with the point to make the other casts ugly, but in some
> environments static_casts MUST be used, and frequently.  The way it is
> designed now, programmers are opting for C-style casts instead.  This
> defeats the purpose of the different casts.  Leave the other three
> alone, but make static casts easier so people will use it instead of
> C-style casts.

I think your people are misguided. I've been consciously promoting
the new-style casts in our code for several years and I haven't found
myself tempted to use the C-style. Perhaps some statistics would be
of interest.

I've just searched a convenient lump of code, and found...

    77025 semi-colons (to give you an idea of size)
    386 static_casts
    44  const_casts
    197 dynamic_casts
    300 reinterpret_casts

(Of course, my ability to find this out is a result of their ugliness.)
I know that there are a handful of C-style casts in there too, and if
anyone has a regular expression for C-style casts, could they post
it so that I can root them all out, please?

There are also a large number of "constructor-style" casts, which
I prefer in the following situation.

    double g=0.0;
    int i = int(g); // tolerable
    int i = static_cast<int>(g); // Ugh

More judicious use of these might alleviate the problem you're
having with your environment. I think this style of cast is an
acceptable alternative to static_cast in this case where we are
fiddling with the built-in types.

Actually, in the particular case above, I would probably write...

    int i = fround(g);

...which echoes Hyman Rosen's advice of hiding a cast in a function
or class. (My fround is a class that constructs from a floating point
value and exposes conversion operators to all the integral types. The
conversions also "round to nearest", but I still think of them as tidy
casts.)

The remaining static_casts are probably casting pointers from base
to derived classes. In these cases, I am frequently comparing...

    ((Type*)p)->Operation();
// ...with...
    static_cast<Type*>(p)->Operation();

...and I prefer the new form, particularly if "p" is an expression.

The reinterpret_casts are much more common than I would like, but
Win32's GUI messages pass pointers and handles as integer message
parameters, and many APIs specify BYTE* when they mean void*.
Perhaps this is the sort of environmental constraint you had in mind,
but I wouldn't want to see *reinterpret_cast* made any easier to type!

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------190ACE2F5802C29499751B38
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michiel Salters wrote:

> Paul Meyerholtz wrote:
>
> > [many snips]
>
> > I see this is going to be a hard sell, so let me make my case a point at
> > a time.
>
> OK, then I'll tackle them a point at a time.

I strongly back Michael's comments.

> > 1 - in some environments static_casts are necessary and frequently used.
> >  There is no way around it, it is not flawed or bad coding, it is a fact
> > of life.
>
> I doubt if there are cases in which more than a few percent (say 10%) of
> the expressions need to be cast.

This discussion would probably be more fruitful if it were based upon specific
examples, rather than upon anecdotal claims of necessity.  With specific real cases
presented then we could either identify why those specific situations require the use
of static_cast, or point out alternative programming constructs within the existing
language.

In my experience static_cast is generally the path of least resistance when dealing
with pre-existing interfaces to products which were designed to interface with C,
with its more tolerant attitude toward type safety.  An example of this would be the
MS-Windows Win32 API.  As C++ becomes a more significant portion of the application
development market the suppliers of these interfaces will start to deliver pure C++
interfaces, such as MFC, which eliminate the need for casts by supporting virtual
functions and polymorphism, for example.

> > 2 - because of the ugliness and hard to read code it creates,
> > programmers who have to do many static casts often just use the c-style cast
>
> The code it creates is for many other programmers quite clear. After all,
> the token clearly states what happens.

Stroustrup has addressed the rationale behind the names but if I might summarize:

 1) casts generally increase the difficulty of ensuring bug-free code.  In essence
they are commands to the language to turn off a particular warning message.
 2) the new names clearly distinguish different types of cast, which were obscured in
the past.
 3) in introducing the new names into the language it was important to minimize
conflict with any existing name, either reserved or in significant use by
programmers.  Some times that is unavoidable, making the word class reserved broke a
lot of programs for example, but by using an unlikely name, like static_cast, this is
minimized.

> > 3 - yes, I agree that the casts as now defined are good.  Unfortunately
> > you can create a perfect tool, but if no one uses it, it doesn't do any good.
>
> That's what coding standards are for. New code should adhere to new
> coding standards, and they should forbid old-style casts.

You can do whatever you want on your own code, but if you are working for someone
else, you had better abide by THEIR coding standards, and any serious installation
will forbid the old-style casts, because they increase the testing and debugging
costs for applications.

> > 4 - the use of c-style cast is so prevalent that if they take it out of
> > the standard in the future, I am sure that there will be some option box
> > I will be able to check to allow c-style casts.  Programmers will demand
> > it, it will be provided.
>
> Yes? I'm missing the point here. C++, in the '98 standard allows them,
> and future (Cpp08?) standards might not. However, compilers probably
> will offer a single switch to toggle between thw two standards.

And employers will insist that the switch be toggled to forbid the old-style casts.

> > 6 - since static casts are the least dangerous of the types of casts,
> > not much is lost in making the static_cast easier to use
>
> I think dynamic_cast is safer, in that it will throw an exception, or
> return a NULL pointer if the cast is wrong.

Definitely, although this really only applies to cast applied to pointers.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------190ACE2F5802C29499751B38
Content-Type: text/x-vcard; charset=us-ascii;
 name="jcobban.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="jcobban.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------190ACE2F5802C29499751B38--

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>
> There are also a large number of "constructor-style" casts, which
> I prefer in the following situation.
>
>     double g=0.0;
>     int i = int(g); // tolerable
>     int i = static_cast<int>(g); // Ugh
>
> More judicious use of these might alleviate the problem you're
> having with your environment. I think this style of cast is an
> acceptable alternative to static_cast in this case where we are
> fiddling with the built-in types.
>

If C-style casts are outlawed in the future, wouldn't int i = int(g)
fail to compile?

or is

int i = int(g);

acceptable while

int i = (int)g;

not acceptable?



Paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------2A27E8C33E29B23DE8264E39
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Meyerholtz wrote:

>
>
> If C-style casts are outlawed in the future, wouldn't int i = int(g)
> fail to compile?
>
> or is
>
> int i = int(g);

This is not a C style cast.  The code will not even compile under C.  It is a
function style, or constructor style cast.  For user defined types you can
even explicitly specify what this function will do, by declaring an operator
int() method.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------2A27E8C33E29B23DE8264E39
Content-Type: text/x-vcard; charset=us-ascii;
 name="jcobban.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="jcobban.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------2A27E8C33E29B23DE8264E39--

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Cobban wrote:
>
> Paul Meyerholtz wrote:
>
> >
> >
> > If C-style casts are outlawed in the future, wouldn't int i = int(g)
> > fail to compile?
> >
> > or is
> >
> > int i = int(g);
>
> This is not a C style cast.  The code will not even compile under C.  It is a
> function style, or constructor style cast.  For user defined types you can
> even explicitly specify what this function will do, by declaring an operator
> int() method.

And that operator will be used by the C style cast as well.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article 38FE6B6B.F66A597A@ix.netcom.com, Paul Meyerholtz at
pholtz@ix.netcom.com wrote on 4/21/00 11:25 AM:

> This is very Macintosh oriented, but when you load reasources they are
> usually of the type that you load, a picture handle is "PicHandle", a
> string handle is "stringHdl".  When we operate with these handles,
> sometimes we use the native type, and sometimes we need to 'upgrade' the
> handle to a generic "Handle" type.
>
> HNoPurge(static_cast<Handle>(pictureHdl));
> DrawPicture(pictureHdl,&pictureRect);
> HPurge(static_cast<Handle>(pictureHdl));
> ReleaseResource(static_cast<Handle>(pictureHdl));

My solution for this was to build a "smart handle" class (think
auto_resource<T> or reference_counted_resource<T>) which handled all of the
casting under the covers of its no_purge(), purge(), lock(), and unlock()
member functions (and called ReleaseResource in its destructor of course).
Then you get smart resource management *and* you those casts only show up
where you touch the OS calls directly, in your smart handle class - once for
each unique OS call, not once for each use.

It worked out very nicely, and was definitely worth the effort.

-Dave

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38FFFD3A.5A84EEFF@lucent.com>, Michiel Salters
<salters@lucent.com> writes
>This is probably untrue. Making static_casts easier is close to
>impossible. It's of course possible to shorten the name, but if
>they really are used that often, a programmer can add a macro.

Or use a decent programmer's editor that you can hot-key to produce the
keyword.


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This is a multi-part message in MIME format.
--------------593F3EA6AB993AE0B52A2579
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ken Hagan wrote:

> I've just searched a convenient lump of code, and found...
>
>     77025 semi-colons (to give you an idea of size)
>     386 static_casts
>     44  const_casts
>     197 dynamic_casts
>     300 reinterpret_casts
>
> (Of course, my ability to find this out is a result of their ugliness.)
> I know that there are a handful of C-style casts in there too, and if
> anyone has a regular expression for C-style casts, could they post
> it so that I can root them all out, please?

Since C-style casts are deprecated, and since many installations, like yours,
would like to forbid them, all commercial C++ compilers should have an option
to flag C-style casts.  If yours does not then bug your supplier, or better
yet have your management make support for flagging C-style casts one of the
mandatory check-off items for the next time you license a C++ compiler.

--
Jim Cobban   jcobban@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438


--------------593F3EA6AB993AE0B52A2579
Content-Type: text/x-vcard; charset=us-ascii;
 name="jcobban.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Cobban
Content-Disposition: attachment;
 filename="jcobban.vcf"

begin:vcard
n:Cobban;James
tel;fax:+1-613-592-9438
tel;home:+1-613-592-9438
x-mozilla-html:FALSE
url:http://www.magma.ca/~jcobban
version:2.1
email;internet:thesnaguy@hotmail.com
title:Consultant
adr;quoted-printable:;;34 Palomino Dr.=0D=0A;Kanata;ON;K2M 1M1;Canada
fn:Jim Cobban
end:vcard

--------------593F3EA6AB993AE0B52A2579--

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com> writes:
> Hyman Rosen wrote:
> > The canonical answer is to create C++ functions and classes which
> > encapsulate the code which requires the casts.
>
> Here is an example of resources, how they are loaded and released int
> the Macintosh environment.  Much code is snipped.
>  PicHandle pictureHdl = GetPicture(rPictureResourceID);
>  HNoPurge((Handle) pictureHdl);
>  DrawPicture(pictureHdl,&pictureRect);
>  HPurge((Handle) pictureHdl);
>  ReleaseResource((Handle) pictureHdl);
>  StringHandle stringHdl = GetString(rStringResourceID);
>  DrawString(*stringHdl);
>  ReleaseResource((Handle) stringHdl);

This is a textbook illustration of my suggestion. Clearly, when you
are doing resource handling such as Get/Release and NoPurge/Purge, you
should have RAII classes that do the work for you, instead of
scattering the calls all over your code.

You certainly should not go through your existing code and change the
casts to C++ style. That will be a waste of time, since the result
would not be C++ in any sense that an expert C++ programmer would
approve.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38FE6B6B.F66A597A@ix.netcom.com>, pholtz@ix.netcom.com
wrote:

> Here is an example of resources, how they are loaded and released int
> the Macintosh environment.  Much code is snipped.
>
>  PicHandle pictureHdl = GetPicture(rPictureResourceID);
>     ...
>  HNoPurge((Handle) pictureHdl);
>  DrawPicture(pictureHdl,&pictureRect);
>  HPurge((Handle) pictureHdl);
>  ReleaseResource((Handle) pictureHdl);
>
>  StringHandle stringHdl = GetString(rStringResourceID);
>  ...
>  DrawString(*stringHdl);
>
>  ReleaseResource((Handle) stringHdl);
>
> This is very Macintosh oriented, but when you load reasources they are
> usually of the type that you load, a picture handle is "PicHandle", a
> string handle is "stringHdl".  When we operate with these handles,
> sometimes we use the native type, and sometimes we need to 'upgrade' the
> handle to a generic "Handle" type.
>
>  HNoPurge(static_cast<Handle>(pictureHdl));
>  DrawPicture(pictureHdl,&pictureRect);
>  HPurge(static_cast<Handle>(pictureHdl));
>  ReleaseResource(static_cast<Handle>(pictureHdl));
>
> How does static_cast add anything to this code?

It makes it easy to search for such casts, which are common hiding
places for errors, since you could accidentally have said "*pictureHdl"
instead of "pictureHdl", for example. It would then compile and fail at
runtime.

In my Macintosh code, I make inline functions like:

   inline Handle AsHandle(PicHandle h)
      { return static_cast<Handle>(h); }
   inline PicHandle AsPicHandle(Handle h)
      { return static_cast<AsPicHandle>(h); }

I overload for various handle types. Then write the code like this:

   HNoPurge(AsHandle(pictureHdl));
   DrawPicture(pictureHdl,&pictureRect);
   HPurge(AsHandle(pictureHdl));
   ReleaseResource(AsHandle(pictureHdl));

This is safer than any kind of cast. If I accidentally pass an
expression of the wrong type, I get a compile time error.

Of course, in most of my programs I have even higher level abstractions,
but all the styles avoid casts as much as possible. The few casts I have
are usually in inline functions.

Converting from casts to inline functions like this in existing code for
projects I've taken on as a consultant typically results in finding and
fixing a significant number of previously undetected errors in the code
base that I'm about to work on.

    -- Darin

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I am still pretty new to C++ programing, and also new to Macintosh
programing both of which I am trying to learn.

Right now I am translating C Mac programs to C++.  Not much translation
is really necessary as most C programs will run with a C++ compiler with
very few or no changes.  But I am translating to the correct 'style' of
C++ also, using the new tools C++ gives me, e.g. overloaded and inline
fuctions, better const etc.  The programs are too short for any real OOP.

When programing for the Mac, lots of casts are needed, mostly of the
static_cast variety.  But I find it difficult to put static_cast<>
everywhere a normal C style cast is as it is

1 - alot of typing

2 - actually makes the program more unreadable

But, if I do C style casts, then I loose the protection of static_cast.
I may actually be doing another worse kind of cast and not know about it.

So my question is, can we make static_cast's easier.  If it were easier,
more people would use it, get the extra protection of a static_cast and
probably use the other types of casts when needed.  So instead of

static_cast<int>(x)

how about

s<int>(x)   or even    <int>(x)

Paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> how about
>
> s<int>(x)   or even    <int>(x)

In one of my standard header files I have:

    #define scast static_cast
    #define ccast const_cast
    #define dcast dynamic_cast
    #define rcast reinterpret_cast

I think the choice standard names was very poor. I will not clutter my code
with those monstrosities. Completely out of character with names used
elsewhere in C++.

Imagine if the designers, not approving of the use of goto, decided to name it

  change_program_location_unstructured_to

--DavidC

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com>:
[snip]
| static_cast<int>(x)
|
| how about
|
| s<int>(x)   or even    <int>(x)
|
| Paul

The xxx_cast family was designed to be ugly.

--
Sebastian Moleski
----
The Borland C++ Builder bug lists:
http://www.crosswinds.net/~bcbbugs/



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:
>
> Right now I am translating C Mac programs to C++.  Not much translation
> is really necessary as most C programs will run with a C++ compiler with
> very few or no changes.  But I am translating to the correct 'style' of
> C++ also, using the new tools C++ gives me, e.g. overloaded and inline
> fuctions, better const etc.  The programs are too short for any real OOP.
>
> When programing for the Mac, lots of casts are needed, mostly of the
> static_cast variety.  But I find it difficult to put static_cast<>
> everywhere a normal C style cast is as it is
>
> 1 - alot of typing
>
> 2 - actually makes the program more unreadable
>
> But, if I do C style casts, then I loose the protection of static_cast.
> I may actually be doing another worse kind of cast and not know about it.
>
> So my question is, can we make static_cast's easier.

I believe that it was a deliberate decision to make the new casts highly
visible,
to indicate that evil is being done.  More typing is no bad thing, if it
reminds
us that we are either (a) doing low-level things, and ought to be jolly
careful
about exactly what's being done, or (b) in need of a better design.

I do agree that it's a pain trying to convert old C code to use the
new-style
casts, but I approve of their visibility.  Sometimes the best solution
is to leave
the old casts in place, and use the effort elsewhere.

The best way to make people use sensible casts would be to use a
compiler which
could disallow C-style casts under control of a compile-time setting,
maybe.


-- James Dennett <jdennett@acm.org>
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> | static_cast<int>(x)
> |
> | how about
> |
> | s<int>(x)   or even    <int>(x)
> |
> | Paul
>
> The xxx_cast family was designed to be ugly.
>
I agree with the point to make the other casts ugly, but in some
environments static_casts MUST be used, and frequently.  The way it is
designed now, programmers are opting for C-style casts instead.  This
defeats the purpose of the different casts.  Leave the other three
alone, but make static casts easier so people will use it instead of
C-style casts.

Paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz wrote:
> Right now I am translating C Mac programs to C++.  Not much translation
> is really necessary as most C programs will run with a C++ compiler with
> very few or no changes.  But I am translating to the correct 'style' of
> C++ also, using the new tools C++ gives me, e.g. overloaded and inline
> fuctions, better const etc.  The programs are too short for any real OOP.
>
> When programing for the Mac, lots of casts are needed, mostly of the
> static_cast variety.  But I find it difficult to put static_cast<>
> everywhere a normal C style cast is as it is
>
> 1 - alot of typing

Some famous programmer [I forget who :( ] once posed the following
rhetorical question:  If your fairy godmother appeared and offered
to remove all the bugs in your code, on the condition that you had
to type the code three times over, would you hesitate?  I think not...


> 2 - actually makes the program more unreadable

That the new-style casts are more *prominent*, is deliberate: We
*want* casts to stand out in our code!  Fancy editors might plausibly
even put Knuth-style "dangerous-bend" signs next to casts.  [ 1/2 :) ]

As to whether new-style casts are more/less readable than old-style
ones, this is a matter of personal taste.  As Stroustrup points out in
"The Design and Evolution of C++", the new-style cast syntax grows on
one over time, particularly if one is also using templates.

Certainly new-style casts convey more information to the reader, i.e.
if I'm reading some code and I encounter

 for (int i = 0 ; i < N ; ++i)
 {
 ((double *)(p))[i] = 0.0;
 }

it's not immediately apparent what the cast is doing.  But if I encounter

 for (int i = 0 ; i < N ; ++i)
 {
 (const_cast<double *>(p))[i] = 0.0;
 }

then it's immediately apparent that we're initializing an array which
will hereafter be  const .

Personally, I now use new-style casts exclusively, except for the
special case of generally--value-preserving numeric casts
(e.g.  float --> double), where I use the more concise and unobtrusive
  type(value)  syntax.

--
-- Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   Q: Which countries [only 5 of them] have the death penalty for children?
   A: Iran, Nigeria, Pakistan, Saudi Arabia, and United States

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com> wrote in message
news:38FD07E9.2D39DD87@ix.netcom.com...
> I agree with the point to make the other casts ugly, but in some


IMO, they're not. It's a functional way of writing it + it is clear what
you're doing (static_cast vs const_cast vs reinterpret_cast). You can
scratch that when using C-style casts.


> environments static_casts MUST be used, and frequently.  The way it is


Agreed.


> designed now, programmers are opting for C-style casts instead.  This


Very bad choice indeed. If they don't know why they should take the
C++-style casts, it is very clear that they don't know what they're
actrually doing with casts.


> defeats the purpose of the different casts.  Leave the other three
> alone, but make static casts easier so people will use it instead of
> C-style casts.


Bad choice. C-style casts may disappear in the following version of the
standard, and what will you do then? Indeed, use C++-style casts. You
*will*   have to learn to use them if you're coding C++, whether you like it
or not.


TiTi
--
"Damn you Murphy!" - TiTi
For comp.lang.c++:
  * Read Shiva's "Welcome to comp.lang.c++" before posting to that
newsgroup:
   http://www.slack.net/~shiva/welcome.txt
  * FAQ (frequently asked questions) :
http://marshall-cline.home.att.net/cpp-faq-lite/


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Cogen wrote:
>
> > how about
> >
> > s<int>(x)   or even    <int>(x)
>
> In one of my standard header files I have:
>
>     #define scast static_cast
>     #define ccast const_cast
>     #define dcast dynamic_cast
>     #define rcast reinterpret_cast
>
> I think the choice standard names was very poor. I will not clutter my code
> with those monstrosities. Completely out of character with names used
> elsewhere in C++.

Stroustrup states in 'The C++ Programming Language' that these casts
were designed to be ugly, because they often indicate a major flaw in
your code.

Your code should be written in such a way that casting is not necessary.

> Imagine if the designers, not approving of the use of goto, decided to name it
>
>   change_program_location_unstructured_to

I guess that would have been a good idea, since using 'goto' is --
except for some very particular situations -- considered 'bad style' as
well. The name you propose would've definitely prevented its use *many*
times <g>.

--
Regards,

Jeremy M. Jancsary
jancsary@gmx.net

/***************************Quote of the Day************************
*                                                                  *
*  Love is composed of a single soul inhabiting two bodies.        *
*                                                                  *
*                                                    -- Aristotle  *
*                                                                  *
*******************************************************************/

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Meyerholtz <pholtz@ix.netcom.com> writes:
> When programing for the Mac, lots of casts are needed, mostly of the
> static_cast variety.  But I find it difficult to put static_cast<>
> everywhere a normal C style cast is

The canonical answer is to create C++ functions and classes which
encapsulate the code which requires the casts. If you could post an
example of the kind of code which is giving you problems, perhaps we
could suggest a solution.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]