Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6102

Re: Here is why C++ and C are bad...

Show key headers only | View raw

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 30/12/15 15:48, Ben Bacarisse wrote:
>
> <snip>
>
>> Since this is comp.programming, you should perhaps have said that mixing
>> signed and unsigned expressions _in C_ is often a bad sign.  It may be
>> in other languages too, but there are others in which it is both common
>> and harmless.
>
> Fair comment. So perhaps we could start by looking at how some other
> languages deal with unsigned integer types (or indeed whether they
> support them at all). I should say at the outset that the information
> I present below is unsatisfactorily sparse.
>
> Ada supports signed and unsigned integer types. I couldn't find any
> rules on how mixed-sign arithmetic is done (but that doesn't mean
> there aren't any).

It won't surprise you to know that there are some.  Exactly what they
are depends of what you mean by unsigned types in Ada.  Do you mean the
standard type Natural, one of the modulo types, or something else?  Ada
is type safe, and tries to be mathematically "safe" as well, hence your
i < j would be either false (if j is 'natural') or a type error if it's
a modulo type.

> BASIC - tricky one. ISO/IEC 10279 defines the language, but I couldn't
> find a freely available draft.

There's an ISO standard BASIC?  Well, gosub 100 and call me structured.
I don't think it has integers, let alone unsigned ones, but I could not
find anything definitive.

> COBOL (according to a rather strangely-formatted draft ISO Standard
> from 2005) seems to support unsigned char, short, long, and even
> double. It isn't clear (from a quick scan) how COBOL deals with
> mixed-sign arithmetic.

One of the few languages I don't care about.

A more interesting letter 'C' for me (and probably for you too) would be
Cryptol.  It has no signed arithmetic at all making -1 < 1 false.

> D's rules are similar to C's. Particularly, if the two types are of
> the same size, then the signed type is converted to unsigned.

Not surprising, but a shame that it did not try to fix this.

> Eiffel supports unsigned integer types, but I found nothing in
> ECMA-367 to show how they interact with signed types.

Pass, but I'd put a substantial bet on it being more like Ada than C.

> Fortran's draft standard (n3501) is rather odd. In Note 15.9 we find
> that "...Fortran does not provide direct support for unsigned kinds of
> integers", and yet in 4.4.1 Integer Type the text reads "The value of
> a signed integer zero is the same as the value of an unsigned integer
> zero", which suggests that there is /some/ kind of support for
> unsigned integers.

I _think_ that's talking about the textual representation.  There's
nothing analogous to C's unsigned in Fortran (or there wasn't the last
time I looked).

> Go supports unsigned integer types, but a brief perusal of the spec
> didn't turn up any rules for mixed-sign arithmetic.

The comparison is a type error in Go (and arithmetic would be too).
Relational operators require "assignable types" and arithmetic requires
identical types (with an exception for shifts).

> I ran out of time to extend this alphabetical list any further,

And just before my favourite -- Haskell.

> but
> one of the first languages I thought of was PHP. I found it surprising
> that PHP doesn't appear to support an unsigned integer type (something
> that it has never before occurred to me to check, which suggests to me
> that I don't use PHP quite as often as I thought I did).

-- 
Ben.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-29 20:31 +0000
  Re: Here is why C++ and C are bad... Kaz Kylheku <kaz@kylheku.com> - 2015-12-29 21:20 +0000
  Re: Here is why C++ and C are bad... David Brown <david.brown@hesbynett.no> - 2015-12-29 23:13 +0100
    Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-29 22:19 +0000
      Re: Here is why C++ and C are bad... David Brown <david.brown@hesbynett.no> - 2015-12-30 09:56 +0100
        Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 13:28 +0000
          Re: Here is why C++ and C are bad... David Brown <david.brown@hesbynett.no> - 2015-12-30 14:55 +0100
            Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 16:32 +0000
              Re: Here is why C++ and C are bad... David Brown <david.brown@hesbynett.no> - 2015-12-30 18:17 +0100
                Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 20:01 +0000
          Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 15:48 +0000
            Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 16:35 +0000
              Re: Here is why C++ and C are bad... David Brown <david.brown@hesbynett.no> - 2015-12-30 18:19 +0100
                Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 17:39 +0000
                Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 20:26 +0000
              Re: Here is why C++ and C are bad... "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-12-30 18:32 +0100
              Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 19:55 +0000
                Re: Here is why C++ and C are bad... Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 20:15 +0000
                Re: Here is why C++ and C are bad... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-30 22:00 +0000
      Re: Here is why C++ and C are bad... Ian Collins <ian-news@hotmail.com> - 2015-12-31 10:16 +1300

csiph-web