Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > which of these 3 casts would you prefer?

Reply
Thread Tools

which of these 3 casts would you prefer?

 
 
BGB
Guest
Posts: n/a
 
      08-27-2011
On 8/27/2011 3:06 PM, Ian Collins wrote:
> On 08/28/11 09:37 AM, BGB wrote:
>> On 8/27/2011 11:38 AM, Juha Nieminen wrote:
>>>
>>> The major problem in C is not the lack of dynamic binding. It's the
>>> lack of RAII and templates. (And, to some extent, exceptions.)

>>
>> RAII normally only really deals with cases which can be dealt with
>> manually though (apart from exceptions, which also don't exist in C, and
>> things like longjmp are rarely used).

>
> The beauty of RAII is you don't have to implement it manually! This
> eliminates a whole class of common programming errors.
>


yep, but this is still more of a convenience feature, rather than a
fundamental limitation.


it is not really too much different from using OpenGL and remembering to
always have a matching "glEnd();" for every "glBegin();", or a
"glPopMatrix();" for every "glPushMatrix();".

if one messes up on these sorts of things in OpenGL, things will turn
ugly...



>> also, several other major languages, such as Java and C#, also lack RAII
>> (with exceptions, this behavior is handled by the use of a "finally"
>> clause).

>
> Yet another manual kludge..
>


well, it can be seen this way...

I am not claiming here that C is perfect or equally programmer-friendly
to C++ or anything, but rather there may be other bigger concerns, and
that conveniences are not "essential".


in my own script language, there are value-types / structs, which will
call the destructor any time they go out of scope (internally, in the
VM, classes and structs are more-or-less equivalent, only that some
extra behaviors exist in the struct case, namely that it is copied
rather than passed by reference, and its destructor is called whenever
it goes out of scope).

but, anyways, they could potentially be used to do something analogous
to RAII (albeit more limited due to the present lack of
copy-constructors or similar).


now, why do they exist?... because these sorts of things are actually
sort of useful (personally, I find the "everything is a
pass-by-reference object" mentality of Java to be a little annoying,
among other things...).

 
Reply With Quote
 
 
 
 
Noah Roberts
Guest
Posts: n/a
 
      08-27-2011
On Aug 27, 3:27*pm, BGB <(E-Mail Removed)> wrote:
> On 8/27/2011 3:06 PM, Ian Collins wrote:
>
> > On 08/28/11 09:37 AM, BGB wrote:
> >> On 8/27/2011 11:38 AM, Juha Nieminen wrote:

>
> >>> The major problem in C is not the lack of dynamic binding. It's the
> >>> lack of RAII and templates. (And, to some extent, exceptions.)

>
> >> RAII normally only really deals with cases which can be dealt with
> >> manually though (apart from exceptions, which also don't exist in C, and
> >> things like longjmp are rarely used).

>
> > The beauty of RAII is you don't have to implement it manually! This
> > eliminates a whole class of common programming errors.

>
> yep, but this is still more of a convenience feature, rather than a
> fundamental limitation.


That's getting pretty silly isn't it? Both languages are Turing
complete, either one CAN do anything the other does just as you CAN do
anything in brain**** that you could have done in C or C++. The
difference being of course, how much time do you want to waste writing
something that another language offers to you for free.

>
> it is not really too much different from using OpenGL and remembering to
> always have a matching "glEnd();" for every "glBegin();", or a
> "glPopMatrix();" for every "glPushMatrix();".
>
> if one messes up on these sorts of things in OpenGL, things will turn
> ugly...


In C++ you can use RAII for that sort of thing. With C, again, you
have to manually track it all and do everything the hard way.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      08-27-2011
On 08/28/11 10:27 AM, BGB wrote:
> On 8/27/2011 3:06 PM, Ian Collins wrote:
>> On 08/28/11 09:37 AM, BGB wrote:
>>> On 8/27/2011 11:38 AM, Juha Nieminen wrote:
>>>>
>>>> The major problem in C is not the lack of dynamic binding. It's the
>>>> lack of RAII and templates. (And, to some extent, exceptions.)
>>>
>>> RAII normally only really deals with cases which can be dealt with
>>> manually though (apart from exceptions, which also don't exist in C, and
>>> things like longjmp are rarely used).

>>
>> The beauty of RAII is you don't have to implement it manually! This
>> eliminates a whole class of common programming errors.

>
> yep, but this is still more of a convenience feature, rather than a
> fundamental limitation.


It is a fundamental feature in the sense that it allows automated
resource management. Automated resource management leads to safer,
cleaner, code. It also removes the single, all be it feeble, excuse for
using goto which has to be a good thing!

> it is not really too much different from using OpenGL and remembering to
> always have a matching "glEnd();" for every "glBegin();", or a
> "glPopMatrix();" for every "glPushMatrix();".
>
> if one messes up on these sorts of things in OpenGL, things will turn
> ugly...


Exactly. With RAII, you eliminate the chance of things turning ugly.

>>> also, several other major languages, such as Java and C#, also lack RAII
>>> (with exceptions, this behavior is handled by the use of a "finally"
>>> clause).

>>
>> Yet another manual kludge..
>>

>
> well, it can be seen this way...


How else can you see it? Missing a finally (or leaving a release out of
one) is just as bad as forgetting a free in C.

> I am not claiming here that C is perfect or equally programmer-friendly
> to C++ or anything, but rather there may be other bigger concerns, and
> that conveniences are not "essential".


No language feature is "essential". We can program in machine code if
we choose. Most of us don't write machine code these days (although I
have to admit I did enjoy it back in the day!) because we have
programming languages that directly support safer and more advanced
idioms.

--
Ian Collins
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      08-27-2011
On Aug 27, 2:37*pm, BGB <(E-Mail Removed)> wrote:
> On 8/27/2011 11:38 AM, Juha Nieminen wrote:
>
>
>
>
>
>
>
>
>
> > BGB<(E-Mail Removed)> *wrote:
> >> one can also argue that function overloading and operator overloading
> >> are nifty, but rarely have I found this to be a big issue (one can
> >> typically sort-of make due with using short macro names to redirect to
> >> longer operator function names or similar, and with the convention of
> >> using short suffixes to function names to indicate the argument types or
> >> similar...).

>
> > * *The reason why function and operator overloading is important isnot
> > because it's "handy" or "convenient" or anything like that. It's because
> > it's *necessary* for generic programming. It's what allows you to do
> > things like this:

>
> > * * *template<typename T>
> > * * *T foo(T value)
> > * * *{
> > * * * * *std::cout<< *"The input value was "<< *value<< *std::endl;
> > * * * * *return std::cos(value);
> > * * *}

>
> > * *The above code would be impossible without function and operator
> > overloading. For example in C you have cos(), cosf() and cosl(), and
> > you just can't write a macro that would call the proper function based
> > on the type of the parameter. In C++ you have just different versions
> > of std::cos(), and the proper version will be automatically called
> > depending on the type of parameter.

>
> > * *(You could write *three* macros with different names, but now you have
> > not only triplicated your code, you have made it impossible to call
> > the macro from other macros without triplicating those too, so the
> > triplication becomes contagious. Also, it doesn't allow the user to use
> > a custom user-defined type.)

>
> > * *Likewise it's what allows the std::cout above to work properly.

>
> > * *This is something the most C programmers don't understand. They are
> > not to blame, though, because many C++ programmers don't know this either
> > (or have never thought about it).

>
> yes, fair enough. C does not do this...
>
> however, it could be argued that *not* having to write duplicated code
> in this case is what is nifty/convinient/...


You seem to be saying that function overloading is not necessary for
generic programming because you don't have to use generic
programming. Same can be said of any paradigm.

Tell me, why are you not writing all your code in assembler?
Certainly it is possible to do so.

>
> as well, there is another partial way around this problem:
> one can implement a dynamic type-system, and then use wrapping and
> run-time type-checking for a lot of this. it is a tradeoff (performance
> is worse, ...), but it works.
>


In C++ we call this polymorphism and it is another built in feature we
don't have to develop on our own.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      08-28-2011
On Sat, 27 Aug 2011 15:27:46 -0700, BGB wrote:

>> The beauty of RAII is you don't have to implement it manually! This
>> eliminates a whole class of common programming errors.

>
> yep, but this is still more of a convenience feature, rather than a
> fundamental limitation.


You can't take this argument much further before you start arguing that
everything about high-level languages is a convenience, because you could
do the same thing in assembler.

> it is not really too much different from using OpenGL and remembering to
> always have a matching "glEnd();" for every "glBegin();", or a
> "glPopMatrix();" for every "glPushMatrix();".


That's slightly different, as you normally care about the precise location
of the glEnd/glPopMatrix/etc. With destruction, you normally only care
that the object gets destroyed "soon" after its last use. You can force
destruction by using an extra block, but this is seldom considered
necessary.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      08-28-2011
On 8/27/2011 3:52 PM, Noah Roberts wrote:
> On Aug 27, 2:37 pm, BGB<(E-Mail Removed)> wrote:
>> On 8/27/2011 11:38 AM, Juha Nieminen wrote:
>>
>>
>>> BGB<(E-Mail Removed)> wrote:
>>>> one can also argue that function overloading and operator overloading
>>>> are nifty, but rarely have I found this to be a big issue (one can
>>>> typically sort-of make due with using short macro names to redirect to
>>>> longer operator function names or similar, and with the convention of
>>>> using short suffixes to function names to indicate the argument types or
>>>> similar...).

>>
>>> The reason why function and operator overloading is important is not
>>> because it's "handy" or "convenient" or anything like that. It's because
>>> it's *necessary* for generic programming. It's what allows you to do
>>> things like this:

>>
>>> template<typename T>
>>> T foo(T value)
>>> {
>>> std::cout<< "The input value was "<< value<< std::endl;
>>> return std::cos(value);
>>> }

>>
>>> The above code would be impossible without function and operator
>>> overloading. For example in C you have cos(), cosf() and cosl(), and
>>> you just can't write a macro that would call the proper function based
>>> on the type of the parameter. In C++ you have just different versions
>>> of std::cos(), and the proper version will be automatically called
>>> depending on the type of parameter.

>>
>>> (You could write *three* macros with different names, but now you have
>>> not only triplicated your code, you have made it impossible to call
>>> the macro from other macros without triplicating those too, so the
>>> triplication becomes contagious. Also, it doesn't allow the user to use
>>> a custom user-defined type.)

>>
>>> Likewise it's what allows the std::cout above to work properly.

>>
>>> This is something the most C programmers don't understand. They are
>>> not to blame, though, because many C++ programmers don't know this either
>>> (or have never thought about it).

>>
>> yes, fair enough. C does not do this...
>>
>> however, it could be argued that *not* having to write duplicated code
>> in this case is what is nifty/convinient/...

>
> You seem to be saying that function overloading is not necessary for
> generic programming because you don't have to use generic
> programming. Same can be said of any paradigm.
>


potentially, then one can find the minimum core of a language which can
still express the desired set of functionality.


> Tell me, why are you not writing all your code in assembler?
> Certainly it is possible to do so.
>


because then I would have to port all that assembler between the various
targets platforms...

I have enough assembler in the project already, much of it mirrored
between different CPU/OS configurations.

so, ASM is generally used sparingly, such as when a given feature can't
be readily implemented directly in a higher-level form.

granted, many nifty parts of the codebase are written in ASM (mostly x86
and x86-64, but there is some ARM related stuff around as well).

technically, the program involves self-modifying code as well.

a nifty use of ASM is to be able to implement reflection mechanisms such
as a generic apply, and also to implement features such as closures
which mimic ordinary function pointers, ...


however, ASM can also be a little verbose at times.


>>
>> as well, there is another partial way around this problem:
>> one can implement a dynamic type-system, and then use wrapping and
>> run-time type-checking for a lot of this. it is a tradeoff (performance
>> is worse, ...), but it works.
>>

>
> In C++ we call this polymorphism and it is another built in feature we
> don't have to develop on our own.


yes, people so much commenting "well I don't have to do X manually", but
what really is the big deal?...


but, anyways, about as soon as one wants to write an interpreter they
will have to implement a lot of this stuff anyways regardless of the
choice of language.

then one may also find themselves faced with such issues as to how to
effectively integrate the interpreter with the host language, ...

having a simpler host language, with a simpler ABI, ... can have its
advantages here.

 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      08-28-2011
Op 27-Aug-11 21:19, Noah Roberts schreef:

> C-style casts are horrible because they can do anything at any time
> without any warning. One minor code change can turn a static cast
> into a reinterpret cast. You can't hunt these things down because
> regular expressions are useless. The undefined behavior they cause
> may or may not turn up at some time in the near future....it may be 2
> decades before your code starts crashing in some place utterly
> unrelated to the cast in an object that has nothing to do with what is
> actually in the memory its using. NOBODY can keep track of every
> place that needs to cast, especially within complex desktop
> applications that use casting quite regularly. Stuff gets lost and
> bad things happen. The new style casts provide a much better method
> because they turn up more errors, you'll get a compiler error instead
> of successful compile when your static_cast is no longer appropriate,
> and can be searched for quite easily. They should be used for all
> cases in which they can be, which is all cases in most projects.


Though I agree with most of what you say here (and your story is all to
familiar to me), personally I prefer to avoid to having to use casts in
the first place. When I see code with a lot of casts I tend to get
nervous. Though C++ style casts are much more precise, I still get
worried when I see many of them. If casts cannot be avoided (which
sometimes is the case) the C++ style casts are to be preferred for the
reasons stated in this thread.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      08-28-2011
On Sat, 2011-08-27, Juha Nieminen wrote:
> BGB <(E-Mail Removed)> wrote:
>> one can also argue that function overloading and operator overloading
>> are nifty, but rarely have I found this to be a big issue (one can
>> typically sort-of make due with using short macro names to redirect to
>> longer operator function names or similar, and with the convention of
>> using short suffixes to function names to indicate the argument types or
>> similar...).

>
> The reason why function and operator overloading is important is not
> because it's "handy" or "convenient" or anything like that. It's because
> it's *necessary* for generic programming.


Well, I think the handiness and convenience are important, too.

When I use C, one of the things I hate the most is coming up with
different names for (for example) is_empty(const Foo*) and
is_empty(Bar*). It really hurts readability.

For example, a C application I work on contains half a dozen linked
list types. They're implemented as just one List_t type, with void* as
values, and we have to write down /as comments/ what type the List_t
is supposed to contain.

I could easily write half a dozen type-safe wrapper structs with
associated next/prev/clear etc operations ... but the operation names
would be too long to be manageable. They would be

Subsystem_List_of_FooBar_next()
Subsystem_List_of_FooBar_prev()
Subsystem_List_of_FooBar_clear()

and my coworkers would find using those /more/ painful than
the current lack of typing. And they would probably be right.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      08-28-2011
On Sat, 2011-08-27, Noah Roberts wrote:
> On Aug 26, 5:40*am, "A" <(E-Mail Removed)> wrote:
>> I do not understand though reluctance to use C style casts.
>>
>> They can cast to reinterpret_cast but they also try out the weaker cast
>> before. It is just automatic way to do what you would do manually - first
>> try const_cast, then static_cast and finally reinterpret_cast... yes, it can
>> use reinterpret_cast but you would have to use it anyway in a particular
>> case where you really need it.
>>
>> So what's wrong with little automation, providing that you know what you are
>> doing with casts?

>
> Perhaps a story would help you understand.
>
> A while back I worked under a guy who used C++ but basically feared
> everything about it. Boy did he love inheritance though. He used
> inheritance as his only method of code reuse. He created these
> gigantic higherarchies


[snip excellent thedailywtf.com material]

Sometimes I wonder if the critics aren't right after all -- that C++
is too complicated for its users to understand. But then so is any
other language, damn it!

/Jorgen

PS. Interesting spelling of "hierarchy". Still unsure if its
intentional

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      08-28-2011
On Aug 28, 12:44*pm, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Sat, 2011-08-27, Noah Roberts wrote:
> > On Aug 26, 5:40*am, "A" <(E-Mail Removed)> wrote:
> >> I do not understand though reluctance to use C style casts.

>
> >> They can cast to reinterpret_cast but they also try out the weaker cast
> >> before. It is just automatic way to do what you would do manually - first
> >> try const_cast, then static_cast and finally reinterpret_cast... yes, it can
> >> use reinterpret_cast but you would have to use it anyway in a particular
> >> case where you really need it.

>
> >> So what's wrong with little automation, providing that you know what you are
> >> doing with casts?

>
> > Perhaps a story would help you understand.

>
> > A while back I worked under a guy who used C++ but basically feared
> > everything about it. *Boy did he love inheritance though. *He used
> > inheritance as his only method of code reuse. *He created these
> > gigantic higherarchies

>
> [snip excellent thedailywtf.com material]
>
> Sometimes I wonder if the critics aren't right after all -- that C++
> is too complicated for its users to understand. But then so is any
> other language, damn it!


Perhaps C++ puts too much power in the hands of people who can't use
it responsibly, but I think also that there are many people who will
just write crap code no matter what language they're using. I mean,
the person in question actually told me that, "The document/view
architecture is considered outdated," when I suggested we NOT mix
business and UI code into the same classes. Using Java or C# or some
other supposedly "easy" language would not have made his code any
better, it only perhaps would have lessened some of the consequences
regarding poor casting. Even then though, I seriously doubt it would
have made any difference.

I'm currently working with someone who seems to think globals are the
best thing since sliced bread and is actually AGAINST factoring them
out of functions that could easily work with parameters instead. This
time the language is C, which is supposedly "simpler" than C++ (which
again seems to be hated). Put such a developer in "simple", weakly-
typed language or something and he'll do the same thing...it just
doesn't matter. In fact in many cases it may get much worse because
now they're not limited to multiple uses of the same type when multi-
purposing a global variable...they can use it as a string here and a
double over there.

The casts that C++ offers introduce a small safety against some of
what can happen when people do bad things, which EVERYONE does. The C
style casts just are not equipped for the introduction of things that C
++ adds to C, like multiple-inheritance and stronger typing. They
won't fix broken coders though and I really don't think that C++ is to
blame for the kinds of poor approaches I've seen in the industry, with
surprising frequency and at surprisingly high levels of authority. A
good language might protect you from making basic mistakes in grammar
or semantics, but if your statements are nonsense to begin with then
no amount of simplicity is going to create sense of them.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
2011: Which Ruby books have you read? And which would you recommend? Aston J. Ruby 13 03-16-2011 07:36 AM
Which of these features would you give up in a travel camera RPS Digital Photography 7 08-19-2007 11:07 PM
Which of these features would you give up in a travel camera RPS Digital Photography 14 08-14-2007 10:43 AM
which of these two lense would you get sigma 70-300mm f/4-5.6 Macro or Canon 75-300mm f/4-5.6 III -dad Digital Photography 19 11-09-2006 01:40 AM
Which of these players would you choose? Tony Olmstead DVD Video 3 06-28-2004 07:49 AM



Advertisments