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

Groups > comp.lang.c++ > #8516 > unrolled thread

Why use C++?

Back to article view | Back to comp.lang.c++

Contents

  Why use C++? Miro <nickbergeronsemail@gmail.com> - 2011-08-06 14:00 -0700
    Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-06 22:09 +0100
      Re: Why use C++? Stuart Redmann <DerTopper@web.de> - 2011-08-10 00:39 -0700
        Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-10 09:59 +0100
          Re: Why use C++? Stuart Redmann <DerTopper@web.de> - 2011-08-10 07:09 -0700
            Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-10 17:22 +0100
            Re: Why use C++? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-08-10 22:05 +0300
              Re: Why use C++? "Randy Brukardt" <randy@rrsoftware.com> - 2011-08-10 17:37 -0500
                Re: Why use C++? Ludovic Brenta <ludovic@ludovic-brenta.org> - 2011-08-11 00:49 +0200
                  Re: Why use C++? "Randy Brukardt" <randy@rrsoftware.com> - 2011-08-11 23:54 -0500
                Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-11 09:54 +0200
                  Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-11 11:13 +0200
                    Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-11 13:43 +0200
                    Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-11 17:09 +0200
                      Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-12 10:32 +0200
                        Re: Why use C++? Hyman Rosen <hyrosen@mail.com> - 2011-08-12 09:15 -0400
                          Re: Why use C++? "Randy Brukardt" <randy@rrsoftware.com> - 2011-08-12 17:09 -0500
                        Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-12 19:20 +0200
                          Re: Why use C++? Ludovic Brenta <ludovic@ludovic-brenta.org> - 2011-08-12 23:22 +0200
                            Re: Why use C++? Ludovic Brenta <ludovic@ludovic-brenta.org> - 2011-08-16 06:06 -0700
                          Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-13 11:37 +0200
                          Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-13 12:27 +0200
                            Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-15 13:38 +0200
                          Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-13 13:02 +0200
                      Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-12 11:21 +0200
                        Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-12 16:30 +0200
                          Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-12 22:05 +0200
                            Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-13 11:15 +0200
                              Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-13 21:29 +1200
                                Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-13 11:52 +0200
                                  Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-13 23:10 +1200
                                    Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-13 13:46 +0200
                                      Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-14 08:30 +1200
                                    Re: Why use C++? Brian Drummond <brian@shapes.demon.co.uk> - 2011-08-13 11:54 +0000
                                      Re: Why use C++? Simon Wright <simon@pushface.org> - 2011-08-13 14:12 +0100
                                        Re: Why use C++? Brian Drummond <brian@shapes.demon.co.uk> - 2011-08-14 11:01 +0000
                                  Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-14 08:46 +0200
                                  Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-14 08:51 +0200
                              Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-14 09:29 +0200
                              Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-16 01:18 -0700
                                Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-16 10:47 +0200
                                  Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-16 02:52 -0700
                                    Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-16 12:39 +0200
                                  Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-16 12:23 +0200
                                    Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-16 12:58 +0200
                                      Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-16 13:44 +0200
                                      Re: Why use C++? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-08-16 15:51 +0100
                                        Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-16 21:13 +0200
                                          Re: Why use C++? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-08-16 20:23 +0100
                  Re: Why use C++? "Randy Brukardt" <randy@rrsoftware.com> - 2011-08-12 00:02 -0500
                    Re: Why use C++? Robert Wessel <robertwessel2@yahoo.com> - 2011-08-12 00:16 -0500
                      Re: Why use C++? Adam Beneschan <adam@irvine.com> - 2011-08-12 09:39 -0700
                    Re: Why use C++? Paavo Helde <myfirstname@osa.pri.ee> - 2011-08-12 01:51 -0500
                      Re: Why use C++? Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2011-08-12 09:41 +0200
                    Re: Why use C++? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-08-12 11:40 +0200
                  Re: Why use C++? Stuart Redmann <DerTopper@web.de> - 2011-08-12 04:48 -0700
                    Re: Why use C++? "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> - 2011-08-12 15:12 +0200
                      Re: Why use C++? Stuart Redmann <DerTopper@web.de> - 2011-08-12 08:50 -0700
                        Re: Why use C++? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-08-12 18:02 +0100
                        Re: Why use C++? "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> - 2011-08-15 14:59 +0200
                  Re: Why use C++? Louisa <louisa.hutch@gmail.com> - 2011-08-18 06:39 -0700
            Re: Why use C++? Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> - 2011-08-11 10:02 +0000
        Re: Why use C++? Dombo <dombo@disposable.invalid> - 2011-08-11 20:20 +0200
          Re: Why use C++? Lynn McGuire <lmc@winsim.com> - 2011-08-11 14:50 -0500
          Re: Why use C++? Dombo <dombo@disposable.invalid> - 2011-08-12 19:22 +0200
      Re: Why use C++? Miro <nickbergeronsemail@gmail.com> - 2011-08-13 08:37 -0700
        Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-14 08:38 +1200
          Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-14 10:41 +1200
            Re: Why use C++? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-14 07:26 +0000
              Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-14 20:18 +1200
                Re: Why use C++? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-14 09:00 +0000
          Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-16 02:10 -0700
            Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-16 21:25 +1200
              Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-16 02:54 -0700
                Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-16 22:04 +1200
    Re: Why use C++? Ian Collins <ian-news@hotmail.com> - 2011-08-07 09:10 +1200
      Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-06 22:13 +0100
        Re: Why use C++? Juha Nieminen <nospam@thanks.invalid> - 2011-08-07 09:09 +0000
          Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-07 12:37 +0100
            Re: Why use C++? Juha Nieminen <nospam@thanks.invalid> - 2011-08-07 14:52 +0000
              Re: Why use C++? "Paul" <pchristor@yahoo.co.uk> - 2011-08-07 20:21 +0100
    Re: Why use C++? Lynn McGuire <lmc@winsim.com> - 2011-08-06 16:29 -0500
    Re: Why use C++? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-07 09:35 +0000
      Re: Why use C++? "crea" <no@invalid.com> - 2011-08-07 13:40 +0100
    Re: Why use C++? Dombo <dombo@disposable.invalid> - 2011-08-07 15:12 +0200
      Re: Why use C++? Juha Nieminen <nospam@thanks.invalid> - 2011-08-07 14:55 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#8773

On 12.08.11 21:51, Jed wrote:

>> The general idea is that you start from the problem
>> without giving thought to representation.  Typically,
>> without loss of efficiency.  Compiler makers know a fair
>> bit about good choice of representation.  This means:
>> Describe precisely what matters to your program, on
>> any machine, without reference to any representation.
>> Then, and only then, and only if necessary, throw in your
>> knowledge of representation.
>
> That doesn't work when you do IO.


Specifying representation when needed, and separate  from
the type declaration, works perfectly well for I/O.
For I/O in particular!

Short summary:

Declaring a type for computation does *not* require specification
of representation.  However, should it become necessary to
specify a representation of objects of a type, the programmer
should be able to do so, but *not* by forcing the representation
into every existing type.


(Incidentally, bit-oriented, abstracting types (bit fields
in C, std::bitset in C++, bit arrays in D, or packed arrays of
Booleans in a host of Pascalish languages) don't make a
language 4GL.)

Examples of how omitting (implied) representation from type
declaration works well with I/O.

1. (I/O As-is) Suppose I/O means writing to a particular address.
There is an output port to write to.  It has CHAR_BIT bits,
and CHAR_BIT == 8.  You want to write an object of type long
which happens to consists of four octets.  One approach is to
write a function that shifts bits into a char object and then
pushes this object out the port.

Using the fundamental type system of C++, you need some size
computations, at compile time, or by the programmer, so that
the program will perform the right number of shifts, for a
given implementation.  With C++ and long, long[], etc, there
are idioms. They typically use the sizeof operator, and division.

The very same technique is available for objects declared of a
type 1e0 .. 1e5 that does not mention any other type's name!
The programmer may leave it to the compiler to choose a
representation for objects of type 1e0 .. 1e5 that is
best on the target hardware for computation.  For I/O, the
programmer again uses the type system and inquires of the type
how many octets there are in the type.  But!  He does not have
to name a type for the "computational objects", such as
declaring them to be "long", he just lists the values that
should be stored in objects of the type, and exactly these, no
more, no less.

In pseudo code,

    type T is exactly 1e0 .. 1e5.
    T obj.   // representation left to the compiler

    // compute, compute, compute, ...  then,

    for k in [0, octet_size(T)) do
      x <- shift_octet_from (obj@k),
      write_octet(x, port_address)
    done.

Note the declaration of T does not mention the name of any
existing type.

In case range types are boring, here is another bare metal type:

    type T is exactly 1e0 .. 1e5 if T % 2 == 0.

Very low level, fairly easy to compute, nothing like 4GL,
and no mention of representation.


2. (Conversion) Suppose I/O means writing a number of structured
objects to a stream.  A program uses many structured objects
in its inner loops, requiring high speed representations. For I/O,
though, a different representation would be better, or is required.

For the computation, simply declare the structure and let the
compiler choose an efficient layout (type sizes, alignment).

    type R is record      struct R {
      x, y, z : S;         S x, y, z;
      t : TS;              TS t;
    end record;          };

In an I/O module, though, specify the layout as needed for I/O.
Doing so will establish order and size of components. It all
happens in the type system, the compiler does it, and the programmer
does not have to write conversion functions:

    -- ... I/O interface ...
private
    -- users of public type R need not be affected

    type R_for_IO is new R;  -- same logical data as R

    for R_for_IO use record
       --  nothing at storage unit 0, padding

       Z at 1 range 0 .. 7;
       Y at 2 range 0 .. 7;
       X at 3 range 0 .. 7;

       -- 2 storage units padding, again

       T at 6 range 2 .. 13;
    end record;


All that now needs to be done when writing objects to a stream
is to apply a type conversion to the object to be output.
Just an ordinary type conversion.  Since the functions of the
I/O interface deal with all this, the type conversion is never
seen by users of "computational type" R.

[toc] | [prev] | [next] | [standalone]

#8777

On 12.08.11 21:51, Jed wrote:

> So the benefit, then, just not having to learn something?


"Oh no, not again."


(1) If you need to know X in order to write program P, you
     should have learned X.

(2) If you do not need to know X for writing P, having
     learned X neither helps nor hurts. (e.g. X ::= float)

(3) If a language L1 requires X for P, you must learn X.

(4) If a language L2 doesn't require X for P, you may
     learn X, but need not.

(5) If P produced by L1 equals P produced by L2, then
     we don't need X for P.  QED

(There may be other reasons for needing both L1 and L2,
but not X for P.)

When a language L2 exists, its existence demonstrates that
we can drop features of L1 and still get P, exactly.

If X has show that it can hurt, this may be incentive
to drop X for a better replacement.

[toc] | [prev] | [next] | [standalone]

#8853

On 14.08.11 07:35, Jed wrote:

>> (4) If a language L2 doesn't require X for P, you may
>>     learn X, but need not.
> 
> But maybe one would want to.

Sure. I think that a type system designed on behalf
of others will profit when the designers look at the
results of existing type systems in the hand of real
people.

If there were evidence that 80% of CVEs are caused
by use of some fundamental types, would you suggest
keeping those types and, I don't know, fire the guys
who wrote the programs, telling them they shouldn't
be programming?

[toc] | [prev] | [next] | [standalone]

#8780

On 12.08.11 21:51, Jed wrote:

> I like the semantic also (not the syntax though). I still don't have a
> feel for the scope of the desired (your) semantics and the compiler
> implementation effort requited though. So far, I'm clear on "ranged
> integers + size attribute".

As others have argued, and as has come out of the study
mentioned earlier, the language should allow specifying types
by referring to those properties of the solution that
are descriptive of the envisioned type's properties.  That's
rarely int alone, but rather what the programmer has in mind.

Sorry, I can't present to you a complete and consistent summary
of the world's programmers' ideas about whole number types in
their programs, other than in the negative: they are rarely covered
by int, as is exemplified in this thread.

A positive addition: we already have alternative ways of
declaring types and they lead to exactly as efficient
programs.

These types are an interesting challenge, anyway.  A few compiler
writers have done some homework and decided that cyclic types (beyond
wrapping ones such as unsigned int) would be nightmarish to
implement.  At least efficiently, IIUC.

But do they have to implement all kind of ideas, or should
a language just offer building blocks for the type system?
For example, offer a set membership operation, one that can
no just be tacked onto operator=, but such that the compiler
can infer things systematically, guided by standard rules
whenever it meets =.

Is there a way, for example, to define a type system
that  keeps HALT out of  operator=?


> So, a control panel on top of the low-level things. (4GL vs. 3GL).

int refers only to what the C++ standard has to say about
minimal properties of int.  Simply being more specific about what
values I have in mind is far, far away from a 4GL language.
Even WRT GL time.  The idea is at least as old as 3GL, and
has been implemented long ago.
The difference in concept between int and integer types flowing
from programmer's specification need not be huge:
Writing "int" gives permissions to the implementation, so do
"n1 .. n2" etc. Only that a C++ compiler cannot but conflate
the value set the programmer had in mind and the  value set
that happens to be that of int in a given implementation.

[toc] | [prev] | [next] | [standalone]

#8702

On Fri, 12 Aug 2011 00:03:24 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net...
>> On Thu, 11 Aug 2011 05:57:32 -0500, Jed wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net...
>>
>>>> Types that cannot be constructed by the operations of the types algebra
>>>> provided by the language. Richer the algebra is, less built-in types needed.
>>>
>>> Will you give an example to clarify please?
>>
>> Ada does not have predefined modular types in the package Standard, because
>> any modular type can be constructed using "type T is mod N" construct.
> 
> OK, I plainly see what you meant now even without your example. It's 
> amazing what a good night's sleep will do. Last night, I was keying-in on 
> the word "algebra" too much and it blinded me to the overall meaning.
> 
> I'm not sure I'd want that level of flexibility in a language.

I think you get me wrong. It is rather about an ability to state the
contracts than about flexibility. If any type is needed in your design, you
should be able to describe the behavior of that type [by the language
means!] in a way the program reader would understand without looking into
the implementation or compiler/machine documentation.

(Types algebra refers to the set of [meta]operations used to create new
types)

>> That depends. In Ada integer types are constructed from ranges.
> 
> Oh, I thought ranges in Ada were "subtype ranges", hence being based upon 
> the built-ins.

Both:

   type Tiny is range -100..100;  -- A new type
   subtype Nano is Tiny range 0..2; -- A subtype
 
>>  In order to
>> specify the range you need literals. The type of a literal
>> (Universal_Integer) is not the type of the result. So technically the 
>> type is not built on Universal_Integer.
> 
> But the "subrange" is meant as "subrange of some existing type", yes? If 
> so, what existing type?

Mathematically there is no need to have a supertype containing the ranged
one. (The way compiler would implement that type is uninteresting, so long
we are considering only the type interface).

>>> If so, aren't modular, wrapping and overflow-checked equally good for
>>> something and all worthy of being in a language? Of course there is
>>> signed, unsigned and the different bit widths as candidates also.
>>
>> Packed decimal, non-symmetric around zero, saturating, non-continuous, big
>> number, non-complement encoded, integers with ideal values (like NaN etc)
>> and so on, and so forth. You cannot have them built-in.
> 
> Why not? What do you understand as "built-in"? Intel x86 has BCDs, so 
> would be easy to have that as a type in a language. Do you require 
> "built-in" to mean "supported directly by the hardware"?

Built-in = predefined type, e.g. int, char, double.

>> The language shall distinguish the interface, the contract the
>> type fulfills, and the implementation of that type. "raw" turns this
>> picture upside down. First comes an implementation and then, frequently
>> never, consideration whether this implementation is right for the 
>> needs.
> 
> You meant "application" instead of "language", right? So you would prefer 
> to have a special "loop counter integer" instead of using a general 
> unsigned integer?

Sure. In fact in Ada it is much in this way:

   for Index in A'Range loop

I don't care about the type of Index, it is just the type suitable to index
the array A.

>>> Are you suggesting that a language have NO types?
>>
>> I suggest a minimal possible set of given types and as wide as possible set
>> of types constructed.
> 
> And do you reject wrapping an existing integer types to get desired 
> semantics?

Not at all.

>> The point is that it is the application domain
>> requirements to drive the design, and the choice of types in 
>> particular.
> 
> Can that be achieved? At what degree of complexity?

We probably are close to the edge.

> Can it/should it be hardware-supported?

No. Hardware becomes less and less relevant as the software complexity
increases.

> From a HLL-designer POV, saying assembly language is "typeless", is fair, 
> and usually stated that way. One can pick nits at that if they want to.

Yes, but "typeless" actually means broken, implicit types, rather than no
types at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8720

On Fri, 12 Aug 2011 08:26:26 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vn800hbyx8k4$.1lsveclj56197$.dlg@40tude.net...

>> I think you get me wrong. It is rather about an ability to state the
>> contracts than about flexibility. If any type is needed in your design, you
>> should be able to describe the behavior of that type [by the language
>> means!] in a way the program reader would understand without looking into
>> the implementation or compiler/machine documentation.
> 
> In another post in this thread, I wondered if you just want a higher 
> level of abstraction, and then noted that I consider that at a higher 
> level than "close to the machine" like C and C++ are. So, is that what 
> you want?

I want the type semantics specified. C/C++ int is neither lower level nor
closer to the machine it is just ill-defined. The concern is this, not its
relation to the machine, of which I (as a programmer) just do not care.

>>>> That depends. In Ada integer types are constructed from ranges.
>>>
>>> Oh, I thought ranges in Ada were "subtype ranges", hence being based 
>>> upon
>>> the built-ins.
>>
>> Both:
>>
>>   type Tiny is range -100..100;  -- A new type
>>   subtype Nano is Tiny range 0..2; -- A subtype
> 
> What underlies those "new" types though?

That is up to the compiler. 

> Aren't they just "syntactic" sugar over some well-defined primitives?

What are "well-defined primitives"?

> Wouldn't they have to be? I.e., 
> at some point, the hardware has to be interfaced.

Yes. Consider a that the target is a pile of empty bier cans maintained by
a robot. I presume that somehow the position of the cans or maybe their
colors in that pile must reflect values of the type. Why should I (as a
programmer) worry about that?
 
>>>>  In order to
>>>> specify the range you need literals. The type of a literal
>>>> (Universal_Integer) is not the type of the result. So technically the
>>>> type is not built on Universal_Integer.
>>>
>>> But the "subrange" is meant as "subrange of some existing type", yes? 
>>> If so, what existing type?
>>
>> Mathematically there is no need to have a supertype containing the 
>> ranged one.
> 
> I'm only concerned about pragmatics (implementation).

It is simple to implement such a type based on an integer machine type when
values of the language type correspond to the values of the machine type
(injection). It is less simple but quite doable to implement this type on a
array of machine values. The algorithms are well known and well studied. I
see no problem with that.

>> (The way compiler would implement that type is uninteresting,
> 
> Ha! To me that is KEY.

This is not a language design question. It is a matter of compiler design
targeting given machine.

>>>> The language shall distinguish the interface, the contract the
>>>> type fulfills, and the implementation of that type. "raw" turns this
>>>> picture upside down. First comes an implementation and then, frequently
>>>> never, consideration whether this implementation is right for the needs.
>>>
>>> You meant "application" instead of "language", right? So you would prefer
>>> to have a special "loop counter integer" instead of using a general
>>> unsigned integer?
>>
>> Sure. In fact in Ada it is much in this way:
>>
>>   for Index in A'Range loop
>>
>> I don't care about the type of Index, it is just the type suitable to index
>> the array A.
> 
> In loop control, I wouldn't care either, but given that it's a compiler 
> thing then, it wouldn't have to be a special type at all, for the 
> compiler can guarantee that the use of the standard primitive type would 
> be used appropriately for it is the one to generate the code from the 
> loop.

This is an implementation detail which shall not be exposed. Because Index
is a subtype of the array index the compiler can omit any range checks.
Contracts are useful for both the programmer and the compiler.

> I care in data structs though what the "physical" type is.

Why should you? Again, considering design by contract, and attempt to
reveal the implementation behind the contract is a design error. You shall
not rely on anything except the contract, that is a fundamental principle.

>>>>> Are you suggesting that a language have NO types?
>>>>
>>>> I suggest a minimal possible set of given types and as wide as 
>>>> possible set of types constructed.
>>>
>>> And do you reject wrapping an existing integer types to get desired
>>> semantics?
>>
>> Not at all.
> 
> But you do think it is inadequate, clearly.

No. Inadequate would be to expose such integer types in the contracts.
Implementations based on existing types are possible, but you would need
much language support (e.g. reflection) in order to ensure that the
implementation fulfills the contract. As an example, consider an
implementation of

   type I is range -200_000_000..100_000; -- This is the contract, which
      -- includes the range and the behavior of +,-,*/,**,mod,rem, overflow
      -- checks etc

on top of C's int.

>>>> The point is that it is the application domain
>>>> requirements to drive the design, and the choice of types in
>>>> particular.
>>>
>>> Can that be achieved? At what degree of complexity?
>>
>> We probably are close to the edge.
> 
> Meaning "highly complex"?

Enough complex to make unsustainable the ways programs are designed now.

>>> Can it/should it be hardware-supported?
>>
>> No. Hardware becomes less and less relevant as the software complexity
>> increases.
> 
> OK, so another layer of abstraction is what you want. The syntax of, say, 
> Ada's ranged types, for example. So your call is just for more syntactic 
> sugar then, yes?

Rather more support to contract driven design and static analysis.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8749

On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...

>> I want the type semantics specified. C/C++ int is neither lower level nor
>> closer to the machine it is just ill-defined. The concern is this, not its
>> relation to the machine, of which I (as a programmer) just do not care.
> 
> What more definition do you want?

More than what? I see nothing.

> Other than that, what 
> is ambiguous (platform-specific) about C++ int?

That is one of the meanings of ill-defined. 

>>>>>> That depends. In Ada integer types are constructed from ranges.
>>>>>
>>>>> Oh, I thought ranges in Ada were "subtype ranges", hence being based
>>>>> upon
>>>>> the built-ins.
>>>>
>>>> Both:
>>>>
>>>>   type Tiny is range -100..100;  -- A new type
>>>>   subtype Nano is Tiny range 0..2; -- A subtype
>>>
>>> What underlies those "new" types though?
>>
>> That is up to the compiler.
> 
> Do you care about the size of the type ever?

You mean the size of the representation taking into account its memory
alignment? I don't care except for the cases I have to communicate the
hardware or to implement a communication protocol. Though I have to do this
quite often, so I cannot represent a typical case, not so many people are
doing embedded/protocol stuff these days. Anyway, that is well under 1% for
me.

BTW, if you aim at this application domain, note endianness and encoding
stuff. You have very little chance that int is the type the protocol or
hardware uses. In fact, you need here even more language support, because
the type semantics is to be defined far more rigorously. You need to take
the description of the protocol and rewrite it in the language terms. Even
Ada's representation clauses cannot this, e.g. to describe the integers
used in an analogue input terminal (as an integral type).

>>> Aren't they just "syntactic" sugar over some well-defined primitives?
>>
>> What are "well-defined primitives"?
> 
> The built-in things that are closest to the machine, with consistent 
> representation across machines that can be relied on, that other things 
> are built on top of. (That's a stab at it, anywho).

How these contradictory requirements could be fulfilled by something
well-defined? In fact the vagueness of such "primitives" is a consequence
of that contradiction. There is no such primitives, in principle.

>>> Wouldn't they have to be? I.e.,
>>> at some point, the hardware has to be interfaced.
>>
>> Yes. Consider a that the target is a pile of empty bier cans maintained by
>> a robot. I presume that somehow the position of the cans or maybe their
>> colors in that pile must reflect values of the type. Why should I (as a
>> programmer) worry about that?
> 
> Because you know it isn't beer cans (call it, say, "a simplifying 
> assumption") and you may want to (probably will want to) send some of 
> those integers to another machine across the internet or to disk.

In each such case I will have to use a type different from the machine
type. This is just another argument why types need to be precisely
specified. I addressed this issue above.

>>>> Mathematically there is no need to have a supertype containing the
>>>> ranged one.
>>>
>>> I'm only concerned about pragmatics (implementation).
>>
>> It is simple to implement such a type based on an integer machine type when
>> values of the language type correspond to the values of the machine type
>> (injection). It is less simple but quite doable to implement this type on a
>> array of machine values. The algorithms are well known and well studied. I
>> see no problem with that.
> 
> Just another layer of abstraction. So it's as simple as that (another 
> layer of abstraction), yes?

Yes, what in your opinion a machine word is? Just another layer of
abstraction above states of the p-n junctions of some transistors. Do you
care?

>>>> (The way compiler would implement that type is uninteresting,
>>>
>>> Ha! To me that is KEY.
>>
>> This is not a language design question. It is a matter of compiler design
>> targeting given machine.
> 
> Oh? I've been having a language design discussion (primarily).

Then that cannot by any means be a key issue.

>> Why should you? Again, considering design by contract, and attempt to
>> reveal the implementation behind the contract is a design error. You shall
>> not rely on anything except the contract, that is a fundamental principle.
> 
> While that paradigm does have a place, that place is not "everywhere". 

Where?

> The comments being made in this thread are really suggesting 4GL. While 
> that is fine, there is a place for 3GLs and hybrids. One size fits all, 
> really doesn't.

Maybe, but in software engineering it certainly does.

> Well then, if wrapping is OK, what else is needed and why?

Wrapping is an implementation, the question is WHAT does this
implementation actually implement?

>> Inadequate would be to expose such integer types in the contracts.
> 
> What contracts?

>> Implementations based on existing types are possible, but you would need
>> much language support (e.g. reflection) in order to ensure that the
>> implementation fulfills the contract. As an example, consider an
>> implementation of
>>
>>   type I is range -200_000_000..100_000; -- This is the contract, which
>>      -- includes the range and the behavior of +,-,*/,**,mod,rem, 
>> overflow
>>      -- checks etc
>>
>> on top of C's int.
> 
> Oh, THAT "contract". (I reserve that term for function calls, just to 
> avoid overloading it, but I actually prefer "specification" as I 
> associate "contract" with Eiffel).
> 
> I'm don't know what you are suggesting the ideal implementation would be 
> of the ranged type above.

There is no ideal implementations, there are ones fulfilling functional and
non-functional requirements.

>>>>>> The point is that it is the application domain
>>>>>> requirements to drive the design, and the choice of types in
>>>>>> particular.
>>>>>
>>>>> Can that be achieved? At what degree of complexity?
>>>>
>>>> We probably are close to the edge.
>>>
>>> Meaning "highly complex"?
>>
>> Enough complex to make unsustainable the ways programs are designed 
>> now.
> 
> Explain please.

If the bugs rate will not be reduced, there will not be enough human
resources to keep software development economically feasible. And this is
not considering future losses of human lives in car accidents caused by
software faults etc.

>>>>> Can it/should it be hardware-supported?
>>>>
>>>> No. Hardware becomes less and less relevant as the software 
>>>> complexity increases.
>>>
>>> OK, so another layer of abstraction is what you want. The syntax of, say,
>>> Ada's ranged types, for example. So your call is just for more syntactic
>>> sugar then, yes?
>>
>> Rather more support to contract driven design and static analysis.
> 
> That doesn't appear to be a lot of complexity to introduce into a 
> compiler. It seems like common sense. So, what am I missing here?

Contract specifications. "int" is not a contract.

> The new enums in C++11 are a step in the right direction, yes? Maybe in 
> the next iteration we'll get ranges.

Let's see.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8770

On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net...
>> On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...
>>
>>>> I want the type semantics specified. C/C++ int is neither lower level nor
>>>> closer to the machine it is just ill-defined. The concern is this, not its
>>>> relation to the machine, of which I (as a programmer) just do not
>>>> care.
>>>
>>> What more definition do you want?
>>
>> More than what? I see nothing.
> 
> The semantics of C++ types are specified.

By the word "int"?

>>> Size guarantee?
>>> Other than that, what
>>> is ambiguous (platform-specific) about C++ int?
>>
>> That is one of the meanings of ill-defined.
> 
> Don't use it.

Which was the point.

>> BTW, if you aim at this application domain, note endianness and encoding
>> stuff. You have very little chance that int is the type the protocol or
>> hardware uses.
> 
> Picking on int?

int, long, unsinged represent an example of wrong language design. The
point was that the semantics of an [integer] must be derived from the
application domain.

>> In each such case I will have to use a type different from the machine
>> type. This is just another argument why types need to be precisely
>> specified. I addressed this issue above.
> 
> But they are precisely specified on any given platform.

1. They are not. In order to see the specification of int, you have to read
the compiler documentation. My point was that the program code does not
specify the properties of int. The answer that it is defined somewhere
somehow is not an argument at all, anything works in this or that way.

2. I don't care about the platform, I care about what the program is
supposed to do. The type's properties shall be defined by the application
domain.

>> Just another layer of
>> abstraction above states of the p-n junctions of some transistors. Do
>> you care?
> 
> At some level, I care, yes. At that level, no. I'm not against your 
> proposal, I just don't know the scope of it. I have a feeling that going 
> to the level you are calling for is what would say is "an exercise" 
> instead of practical engineering. Just a feeling though, mind you. Tell 
> me this, how close is Ada (and which one) to your ideal? All I know about 
> Ada is what I've read about it. Maybe I should write some programs in it.

Ada is close, but not close enough. It is light years ahead of C++
concerning numeric types, so the problems with Ada might be difficult to
understand for a C programmer. Ada puts too much magic into numeric types.
I would prefer less. Ada lacks numeric interfaces abstracted away. Ada
lacks mapping of classes of numeric types onto proper types. [There are
classes, but no objects] Exceptions are not contracted. Too many things
required static. Other things are dynamic while should have been static,
etc.

>>>>>> (The way compiler would implement that type is uninteresting,
>>>>>
>>>>> Ha! To me that is KEY.
>>>>
>>>> This is not a language design question. It is a matter of compiler
>>>> design targeting given machine.
>>>
>>> Oh? I've been having a language design discussion (primarily).
>>
>> Then that cannot by any means be a key issue.
> 
> That's opinion, not fact.

It is a conclusion from the fact that we were discussing language design
issues rather than code generation problems.

>>>> Why should you? Again, considering design by contract, and attempt to
>>>> reveal the implementation behind the contract is a design error. You shall
>>>> not rely on anything except the contract, that is a fundamental
>>>> principle.
>>>
>>> While that paradigm does have a place, that place is not "everywhere".
>>
>> Where?
> 
> The formality of "design by contract" as used in developing 
> functions/methods.

That is a procedural view on software developing [a very outdated one,
IMO].

But design by contract is a mere engineering principle, it applies
absolutely everywhere in engineering. If you disagree, please, show
examples.

[I don't mean here Meyer's notion of DbC, which is largely wrong, IMO]

>>> Well then, if wrapping is OK, what else is needed and why?
>>
>> Wrapping is an implementation, the question is WHAT does this
>> implementation actually implement?
> 
> I was just asking why you find that inadequate such that something 
> (largely more complex?) is needed.

Hmm, then I didn't understand your question.

> Oh, you were thinking something else when I wrote: "Can that be achieved? 
> At what degree of complexity?". I asked if creating your ideal language 
> (this "definitively specified higher level" language) is feasible and if 
> so, what does that do to the complexity of the implemenation (compiler)?

I think it should make the compiler simpler. Implementation of the RTL is a
different issue.

> Is a comparison of Ada and C++ pretty much that answer?

As a matter of fact, since I partially did both, to compile Ada is way
simpler than to compile C++.

>> Contract specifications. "int" is not a contract.
> 
> Does Ada meet your desired requirements?

Ada is the closest existing approximation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8772

On 08/13/11 09:15 PM, Dmitry A. Kazakov wrote:
> On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote:
>
>>> BTW, if you aim at this application domain, note endianness and encoding
>>> stuff. You have very little chance that int is the type the protocol or
>>> hardware uses.
>>
>> Picking on int?
>
> int, long, unsinged represent an example of wrong language design. The
> point was that the semantics of an [integer] must be derived from the
> application domain.

They are an example of a specific language design decision, not a wrong 
one.  It's pretty rare for the application domain to be concerned about 
the semantics of an integer beyond those specified by the language.  In 
those rare cases where it does, the language provides a means of doing 
so though user defined types.

>>> In each such case I will have to use a type different from the machine
>>> type. This is just another argument why types need to be precisely
>>> specified. I addressed this issue above.
>>
>> But they are precisely specified on any given platform.
>
> 1. They are not. In order to see the specification of int, you have to read
> the compiler documentation. My point was that the program code does not
> specify the properties of int. The answer that it is defined somewhere
> somehow is not an argument at all, anything works in this or that way.

If you want to get the best performance out of a given platform (which 
many C and C++ programs do), you have to program to the characteristics 
of the platform.

> 2. I don't care about the platform, I care about what the program is
> supposed to do. The type's properties shall be defined by the application
> domain.

Can you give an example of where that would be an issues not solved by 
user defined types?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8776

On Sat, 13 Aug 2011 21:29:05 +1200, Ian Collins wrote:

> It's pretty rare for the application domain to be concerned about 
> the semantics of an integer beyond those specified by the language.

If buffer overflows and code quality is not a concern, then yes.

>>>> In each such case I will have to use a type different from the machine
>>>> type. This is just another argument why types need to be precisely
>>>> specified. I addressed this issue above.
>>>
>>> But they are precisely specified on any given platform.
>>
>> 1. They are not. In order to see the specification of int, you have to read
>> the compiler documentation. My point was that the program code does not
>> specify the properties of int. The answer that it is defined somewhere
>> somehow is not an argument at all, anything works in this or that way.
> 
> If you want to get the best performance out of a given platform (which 
> many C and C++ programs do), you have to program to the characteristics 
> of the platform.

First of all, performance is not a functional requirement. If functional
requirements are not met, non-functional ones are irrelevant. Thus the
question stands: what does int implement? Where in the program code is any
specification of the *functional* requirements which the implementation
chosen to be int is supposed to fulfill [in the best etc possible way,
which in its turn requires validation]? How do I know if int is OK, not
unsigned, not long, not short and so on?

Secondly, how do you know that int gives you the best performance across
all possible implementations fulfilling the functional requirements? By
choosing int you prohibit the compiler to select any other machine type,
which also does the things you want. The point is, specify what you want
and let the compiler to implement it in a best possible way. Choosing an
implementation is an optimization issue, you can aim at memory use, at
time, at best lock-free sharing and so on. Fixing a machine type makes your
program potentially less efficient. More precisely you specify the
semantics of required type, more knowledge the compiler has to generate
efficient code.

>> 2. I don't care about the platform, I care about what the program is
>> supposed to do. The type's properties shall be defined by the application
>> domain.
> 
> Can you give an example of where that would be an issues not solved by 
> user defined types?

BTW, the point was: don't use built-in numeric types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8781

On 08/13/11 09:52 PM, Dmitry A. Kazakov wrote:
> On Sat, 13 Aug 2011 21:29:05 +1200, Ian Collins wrote:
>
>> It's pretty rare for the application domain to be concerned about
>> the semantics of an integer beyond those specified by the language.
>
> If buffer overflows and code quality is not a concern, then yes.

Most variables have limited scope and a well defined range.  So if I use 
an int in a for loop over a small set of data, I'm not writing poor 
quality code.

>>>>> In each such case I will have to use a type different from the machine
>>>>> type. This is just another argument why types need to be precisely
>>>>> specified. I addressed this issue above.
>>>>
>>>> But they are precisely specified on any given platform.
>>>
>>> 1. They are not. In order to see the specification of int, you have to read
>>> the compiler documentation. My point was that the program code does not
>>> specify the properties of int. The answer that it is defined somewhere
>>> somehow is not an argument at all, anything works in this or that way.
>>
>> If you want to get the best performance out of a given platform (which
>> many C and C++ programs do), you have to program to the characteristics
>> of the platform.
>
> First of all, performance is not a functional requirement.

It very often is the first one for most of the embedded systems I write!

> If functional
> requirements are not met, non-functional ones are irrelevant.

The functional requirements are irrelevant if they can not be met in the 
required time.

> Thus the
> question stands: what does int implement? Where in the program code is any
> specification of the *functional* requirements which the implementation
> chosen to be int is supposed to fulfill [in the best etc possible way,
> which in its turn requires validation]? How do I know if int is OK, not
> unsigned, not long, not short and so on?

In general, you can't.  Where it matters, you have to measure.

> Secondly, how do you know that int gives you the best performance across
> all possible implementations fulfilling the functional requirements? By
> choosing int you prohibit the compiler to select any other machine type,
> which also does the things you want. The point is, specify what you want
> and let the compiler to implement it in a best possible way. Choosing an
> implementation is an optimization issue, you can aim at memory use, at
> time, at best lock-free sharing and so on. Fixing a machine type makes your
> program potentially less efficient. More precisely you specify the
> semantics of required type, more knowledge the compiler has to generate
> efficient code.

I do see your point and for C or C++ the best we can do knowing a 
variable is signed or unsigned of a given range is to use one of the C 
fast_xx types.  Far from ideal I know.

Yes I agree being able to specify a type without reference to an 
underlying fundamental type is a powerful feature C and C++ lack.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8783

On 13.08.11 13:10, Ian Collins wrote:
> On 08/13/11 09:52 PM, Dmitry A. Kazakov wrote:
>> On Sat, 13 Aug 2011 21:29:05 +1200, Ian Collins wrote:
>>
>>> It's pretty rare for the application domain to be concerned about
>>> the semantics of an integer beyond those specified by the language.
>>
>> If buffer overflows and code quality is not a concern, then yes.
>
> Most variables have limited scope and a well defined range. So if I use an int in a for loop over a small set of data, I'm not writing poor quality code.

Even if language design is not to be judged what you or Dmitry,
or I, if I may, write in any given specific circumstance, it
is still true that every other week an overflow drills
a CVE into the internet.


> Yes I agree being able to specify a type without reference to an underlying fundamental type is a powerful feature C and C++ lack.

Could you say why? I speculate that Jed would like to hear,
too.

[toc] | [prev] | [next] | [standalone]

#8795

On 08/13/11 11:46 PM, Georg Bauhaus wrote:
> On 13.08.11 13:10, Ian Collins wrote:
>
>> Yes I agree being able to specify a type without reference to an underlying fundamental type is a powerful feature C and C++ lack.
>
> Could you say why? I speculate that Jed would like to hear,
> too.

The answer was in the paragraph I was responding to....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8784

On Sat, 13 Aug 2011 23:10:48 +1200, Ian Collins wrote:

> On 08/13/11 09:52 PM, Dmitry A. Kazakov wrote:
>> On Sat, 13 Aug 2011 21:29:05 +1200, Ian Collins wrote:
>>
>>> It's pretty rare for the application domain to be concerned about the
>>> semantics of an integer beyond those specified by the language.
>>
>> If buffer overflows and code quality is not a concern, then yes.
> 
> Most variables have limited scope and a well defined range.  So if I use
> an int in a for loop over a small set of data, I'm not writing poor
> quality code.

Yes you are (in this hypothetical example), if you care about either 
reliability or efficiency.

By specifying "int" you are prohibiting the compiler from both:
(a) using a smaller and possibly faster type that is adequate to cover 
the range of data.
and (b) using a larger type if "int" does not actually cover the range.

Specify user-defined types "range 1 .. 100" or "range 32760 ..32769" or 
"range lower .. upper" and let the compiler choose the optimal base type 
for the current target. (Imagine using "int" here on a 16-bit platform) 

Incidentally, the values of "lower" and "upper" need not be determined 
until runtime. The compiler can infer the best base type from whatever 
constraints it finds on "lower" and "upper".

So why get in its way?

- Brian

[toc] | [prev] | [next] | [standalone]

#8787

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Incidentally, the values of "lower" and "upper" need not be determined
> until runtime. The compiler can infer the best base type from whatever
> constraints it finds on "lower" and "upper".

I don't think that can be true? OK, the range can be postponed until
runtime, but the base type of which the actual bounds are instances must
be known (talking about a compiler here, not an interpreter).

[toc] | [prev] | [next] | [standalone]

#8836

On Sat, 13 Aug 2011 14:12:51 +0100, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> Incidentally, the values of "lower" and "upper" need not be determined
>> until runtime. The compiler can infer the best base type from whatever
>> constraints it finds on "lower" and "upper".
> 
> I don't think that can be true? OK, the range can be postponed until
> runtime, but the base type of which the actual bounds are instances must
> be known (talking about a compiler here, not an interpreter).

Yes, that's what I meant by the constraints on the bounds ... the base 
type of the range must be wide enough to accommodate both bounds. I see 
no need to specify it; that's the compiler's job.

- Brian

[toc] | [prev] | [next] | [standalone]

#8820

On Sat, 13 Aug 2011 23:35:58 -0500, Jed wrote:

> Dmitry A. Kazakov wrote:
> 
>> First of all, performance is not a functional requirement.
> 
> What planet are you from?

It happened so, that 50% of what I am doing is designing embedded and
real-time systems.

> Of course it is a functional requirement. I.e, 
> where performance matters and is thus specified.

Where performance (timing) really matters at the level of severity making
it functional, it is specified in the form of real-time constraints. Then
your case looks much worse, fatal rather, sorry.

You have to show that an activity X is completed before the deadline T,
that must follow from the types selected and overall design. This means
that timing of the operations shall be contracted (which sill does not
guarantee you anything, but necessary to any form of static analysis). And
you have no contracts at all!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8821

On Sat, 13 Aug 2011 23:49:00 -0500, Jed wrote:

> Dmitry A. Kazakov wrote:
> 
>> Choosing an implementation is an optimization
>> issue,
> 
> Hmm. The truth of this is "easily" determined (by academics, not by me!). 
> Starting in on the theory, the "register" keyword is a good starting 
> point for thought.

In early 60s, maybe. Nowadays it should be "register", "L1 cache", "L2
cache", "L3 cache" etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8829

On Sat, 13 Aug 2011 23:29:12 -0500, Jed wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net...
>>>> On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...
>>>>
>>>>>> I want the type semantics specified. C/C++ int is neither lower
>>>>>> level nor closer to the machine it is just ill-defined. The
>>>>>> concern is this, not its relation to the machine, of which I (as
>>>>>> a programmer) just do not
>>>>>> care.
>>>>>
>>>>> What more definition do you want?
>>>>
>>>> More than what? I see nothing.
>>>
>>> The semantics of C++ types are specified.
>>
>> By the word "int"?
> 
> By "specified", I mean "you know what to expect" (being, you have not a 
> guarantee).

No, "what to expect" follows from the specification. E.g. "the can opener
operates in the temperature range -10..+40 °C". This is a specification.
"The can opener may operate at some temperature" is not.

>> int, long, unsinged represent an example of wrong language design.
> 
> I agree (did you mean in C++, or in general?).

In general. It is

1. untyped approach. Not because of implicit conversions, which are bad of
course. The main reason is that the programmer should be encouraged to
choose different integer types for semantically different things, even if
numerically these things could be implemented by the same type.

2. Lack of contracts, machine/language- rather than application domain
driven choice of types.

>>  The
>> point was that the semantics of an [integer] must be derived from the
>> application domain.
> 
> Maybe it's good enough in a lot of instances. Say, a memory address. 
> 32-bit unsigned address works nicely (on a 32-bit machine).

Address is not an integer type. Consider segmented architecture as an
example.

>> My point was that the program
>> code does not specify the properties of int.
> 
> And I'm saying, maybe ("maybe" is a key word here) that is just a purist 
> approach and not better than practical compromise.

A compromise between what and what?

>> 2. I don't care about the platform, I care about what the program is
>> supposed to do.
> 
> Another way to skin the cat: write to a virtual machine. Java. .Net.

No, it is an attempt to constrain to one platform. VM, when used, is *the*
hardware. As history shows, all such attempts were in vain.

>>>>>> Why should you? Again, considering design by contract, and
>>>>>> attempt to reveal the implementation behind the contract is a
>>>>>> design error. You shall not rely on anything except the contract,
>>>>>> that is a fundamental principle.
>>>>>
>>>>> While that paradigm does have a place, that place is not
>>>>> "everywhere".
>>>>
>>>> Where?
>>>
>>> The formality of "design by contract" as used in developing
>>> functions/methods.
>>
>> That is a procedural view on software developing [a very outdated one,
>> IMO].
> 
> No it is not. Classes have methods. (I'm surprised you even said that).

Yes, they do. Yet an ADT (class is a type) is seen as something more than
just a collection of subprograms. It is not just methods (and other
operations) are subjects of contracts.

> I furthered 
> saying that I have a feeling you are seeking some "purist" ideal or 
> something for comp sci labs in academia.

Not at all. I am looking for a language for practical projects we are doing
(automation, embedded, networking, RT systems). Using a bad language is an
economic disadvantage.

>>> Oh, you were thinking something else when I wrote: "Can that be
>>> achieved? At what degree of complexity?". I asked if creating your
>>> ideal language (this "definitively specified higher level" language)
>>> is feasible and if so, what does that do to the complexity of the
>>> implemenation (compiler)?
>>
>> I think it should make the compiler simpler.
> 
> Do explain please. I can appreciate that in the abstract things look 
> rosey, but the devil is always in the details. One can design the perfect 
> bridge, but the problem is that landscapes are never perfect.

It is simpler to perform semantic analysis if you have a unified types
system. Each special case multiplies complexity.

>>> Is a comparison of Ada and C++ pretty much that answer?
>>
>> As a matter of fact, since I partially did both, to compile Ada is way
>> simpler than to compile C++.
> 
> That's not saying much of anything. Compare it to C.

K&R C or ANSI C? Up to the semantic analysis Ada 95 is much simpler than C.
After that C should be simpler.

> I think it has this "module as class-like thing" that seems so 
> archaic,

Hmm, actually it is C++, which conflates types (classes) with modules. This
error is shared by many OOPLs. In Ada a module (package) can provide any
number of types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#8891

On Aug 13, 10:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 13 Aug 2011 02:53:32 -0500, Jed wrote:
> > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message
> >news:1gu6ni1yb54k3$.4nbvfqqndl8m$.dlg@40tude.net...
> >> On Fri, 12 Aug 2011 14:06:55 -0500, Jed wrote:
> >>> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message
> >>>news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...


> >>>> I want the type semantics specified. C/C++ int is neither lower level nor
> >>>> closer to the machine it is just ill-defined. The concern is this, not its
> >>>> relation to the machine, of which I (as a programmer) just do not
> >>>> care.
>
> >>> What more definition do you want?
>
> >> More than what? I see nothing.
>
> > The semantics of C++ types are specified.
>
> By the word "int"?

an integer having a range at leaast large enough to hold the values
-32767..32767
(I may be off a bit on the values but it translates to 16 bits or
larger)

<snip>

> 2. I don't care about the platform, I care about what the program is
> supposed to do. The type's properties shall be defined by the application
> domain.

whilst this degree of abstraction is often good the ability to fiddle
with representaion is also sometimes useful. And if we want our
programs to terminate before the sun goes cold knowing about
representaion is sometimes useful.

I accept many langaues don't reveal represetnation details to the
degree that C (and C++) does.

<snip>

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web