[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] C++ question re. dyn. mem.



On Tue, Aug 05, 2003 at 11:21:04PM -0400, MJM wrote:
> On Monday 04 August 2003 21:40, Sebastian Kapfer wrote:
> > > // change the way it is accessed to prove a point int * p_b = (int *)
> > > p_a;
> >
> > Ouch.
> 
> Try this in /usr/src/linux/kernel
> 
> $ grep *\) *.c

Well, C is not C++, so grepping C source will not really prove anything.

> > One should also note that the C-style casting operator is considered bad
> > style in C++. The "politically correct" way to rewrite your example is
> >
> > int *p_b = reinterpret_cast<int *>(p_a);
> 
> By whom? Your example is nowhere to be found in my C++ books by Bjarne.  So 
> you are saying that Bjarne promotes bad style in his books? Why not tell him: 
> http://www.research.att.com/~bs/homepage.html

Try Meyers' More Effective C++.

> Besides, reinterpret_cast is probably a template function doing this:
> return ((T) x); // type conversion using cast

No, it is an operator, and part of the language. There are four new
casting operators in C++ that were added to be used in place of the
C-style cast syntax. If you're writing it C++, you really should use the
proper casting operators. But, if you only believe things written by
"Bjarne", try

  http://www.research.att.com/~bs/bs_faq2.html#static-cast

> > That way, you're clearly stating the intent of the cast. It is up to your
> > compiler what it makes of this statement; the C++ standard doesn't cover
> > such abuse.
> 
> Language experts sure get their shorts knotted up over simple questions.  

Because your question had to do with undefined and
implementation-dependent behavior.

> I've known some killer programmers and none of them have quoted a language 
> specification in conversation.  That was way over the top.  That stuff is for 
> compiler writers, not application programmers. 

Application programmers should be aware of what aspects of their
language of choice are not portable or implementation-dependent. That
includes portability between different compilers and even different
versions of the same vendor's compiler. That code was not portable, and
could break just by doing something as innocuous as upgrading the C++
library.

-- 
Dave Carrigan
Seattle, WA, USA
dave@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL



Reply to: