Re: Writing bulletproof code

From: James Rogers (jimmaureenrogers_at_att.net)
Date: 01/05/04

  • Next message: gswork: "Re: Academic research aimed at improving programmer productivity?"
    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


  • Next message: gswork: "Re: Academic research aimed at improving programmer productivity?"

    Relevant Pages