Re: Writing bulletproof code
From: James Rogers (jimmaureenrogers_at_att.net)
Date: 01/05/04
- Previous message: Richard Heathfield: "Re: Dean on H-1b/L-1 Visas"
- In reply to: Gerry Quinn: "Re: Writing bulletproof code"
- Next in thread: Gerry Quinn: "Re: Writing bulletproof code"
- Reply: Gerry Quinn: "Re: Writing bulletproof code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 05 Jan 2004 13:44:44 GMT
gerryq@indigo.ie (Gerry Quinn) wrote in
news:gvdKb.3290$HR.7436@news.indigo.ie:
> In article <Xns9466817D79CA5jimmaureenrogers@204.127.36.1>, James
> Rogers <jimmaureenrogers@att.net> wrote:
>>Not when you are talking about C, C++, or Java. Implicit conversion
>>between primitive numeric types in those languages blurs the
>>differences between types. The implicit conversions make the language
>>behave as though there were no significant difference between the
>>types. Having distinct data representations is insufficient for
>>providing strong typing.
>
> I disagree that this 'blurring' amounts to anything significant.
> After all, casting operators can be defined for user-defined types
> that have a nearly identical effect.
>
Ok. I accept that.
>>In C++ you can create a restricted range floating point class.
>>You can also create a restricted range integer class. You will not
>>get implicit conversion between the two classes. This means that
>>the user-defined classes have a more strict separation than their
>>corresponding language-defined primitive types.
>
> In c++ there is no primitive type corresponding to a restricted range
> floating point class, so the above paragraph has null content.
> However you can define a class similar to double, like my 'fubble' and
> then the implicit conversion doesn't exist. But why should that
> matter at all? Apart from the tiny differences in implementation, the
> only distinction of implicit conversions is that somebody has already
> written them, and that person was writing a compiler rather than a
> class library. There is no point erecting a philosophical distinction
> between code that has already been written and code that is to be
> written now. When the latter is completed, it will be the same as the
> former.
I disagree here. C++ has char, short, int, long, float, and double.
A long is expected to have a larger range of values than a char.
A double is expected to have greater precision and a larger range
than a float. In this sense, a char has a restricted range where a
long (or a long_long) has the maximum range directly supported by
hardware.
Implicit conversion in C++ is only safe when converting from a
smaller representation to a larger, such as from a char to a long.
It is not safe to convert from a long to a char. All these issues
are indicative of char having a restricted range compared to long.
>>I do not consider such a difference in programming effort to be
>>practically no difference.
>
> The point is that once it is done, it IS practically no difference.
> Most of the classes I use are not written by me. What do I care
> whether the object is language-defined or not? All it means is that I
> have to look up the conversions in a different manual.
Are you saying that reuse reduces all effort to a minimum level?
That seems to denegrate the value of the effort required to create
resusable code.
>
>>> Range-restricted types may be a famous feature of Ada, but they have
>>> no particular relevance to any discussion of C++, a language which
>>> does not include this feature. Differences that would apply to a
>>> non-existent language feature, if it existed, are not differences!
>>
>>The original discussion was about writing bulletproof code. One factor
>>in such code is the ability of the programmer to control behavior of
>>data abstractions. Strongly typed languages provide facilities for
>>such control.
>>
>>You have somehow assumed this discussion was about writing bulletproof
>>C++ code.
>
> I have made no such assumptions. I took exception to a particular
> assertion you made, which was "languages like C++ and Java make a
> clear distinction between primitives and user-defined types". It is
> my argument that while the statement is true for Java, in fact one of
> the advantages of C++ is that in practice there is very little
> distinction. fubble is as good as double.
I agree, if you discount the effort needed to make fubble convertible
to a double. Java prevents you from achieving the same level of
compatibility.
Jim Rogers
- Previous message: Richard Heathfield: "Re: Dean on H-1b/L-1 Visas"
- In reply to: Gerry Quinn: "Re: Writing bulletproof code"
- Next in thread: Gerry Quinn: "Re: Writing bulletproof code"
- Reply: Gerry Quinn: "Re: Writing bulletproof code"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|