Re: Why use C++?

Re: Why use C++?

[Niklas Holsti]

Stuart Redmann wrote:
> Stuart Redmann wrote
>>> Just one example: We use a lot of COM components in our company. If I
>>> want to use them under C++, I have to
>>> (A) Make sure that I initialize the COM run-time properly,
>>> (B) #import the type libraries,
>>> (C) generate mapping classes from the type libraries so that I can use
>>> the interfaces like I can do under VB.
> 
> Paul wrote:
>> Yes the right tool for these type of applications is usually not C++. If
>> your project was to create the COM object  then C++ would probably be the
>> language of choice.
> 
> It is ;-)
> 
> Sometimes I wish that there was a C++ interpreter as well. This way I
> had to remember only one set of run-time library calls instead of two.
> However, the industry prefers to re-invent the nth virtual machine and
> the xth GUI toolkit. And of course, none of the popular programming
> languages (not even Ada95) supports proper non-wrapping unsigned
> integer types (and I have to use unsigned types for image
> processing).

In what way does Ada (95, or the current standard 2005) not support your 
needs for unsigned types?

If you dislike the wrapping behaviour of the Ada "modular" unsigned 
types, what is wrong with defining your own unsigned integer type in 
Ada, as in

    type My_Number is range 0 .. 53621;

or whatever range you need. This gives you non-wrapping arithmetic with 
run-time checks for overflow, underflow, and range.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Why use C++?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:9ag33sFmuaU1@mid.individual.net...
...
> In what way does Ada (95, or the current standard 2005) not support your 
> needs for unsigned types?

I'm not the OP, but...

> If you dislike the wrapping behaviour of the Ada "modular" unsigned types, 
> what is wrong with defining your own unsigned integer type in Ada, as in
>
>    type My_Number is range 0 .. 53621;

This does not work on the largest unsigned integer type (mod 2**32 in 
Janus/Ada). Ada 95 requires

    type My_Number is range 0 .. 2**32-1;

to be rejected, as the upper bound exceeds Max_Int. (This is technically a 
"signed_integer_type_definition", which shows the cause of the problem.)

The Janus/Ada intermediate code can generate overflow checks for the largest 
integer type, but I've failed to find any reasonable way to model such a 
type in Ada (assuming we want a real integer type, with numeric literals). 
The closest is the "non-standard integer type" is 3.5.4(26) -- but why 
should such a basic need be "non-standard"? And having it "non-standard" 
means that you can't use type declarations like the above to use it. Yuck.

There are uses for wrapping types, but they are far less likely than wanting 
overflow detection. The default should be to catch errors, not turn them 
into different ones.

Too late to fix, unfortunately.

                                                      Randy.





> or whatever range you need. This gives you non-wrapping arithmetic with 
> run-time checks for overflow, underflow, and range.
>
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>       .      @       . 

Re: Why use C++?

[Ludovic Brenta]

"Randy Brukardt" writes on comp.lang.ada:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:9ag33sFmuaU1@mid.individual.net...
> ...
>> In what way does Ada (95, or the current standard 2005) not support your 
>> needs for unsigned types?
>
> I'm not the OP, but...
>
>> If you dislike the wrapping behaviour of the Ada "modular" unsigned types, 
>> what is wrong with defining your own unsigned integer type in Ada, as in
>>
>>    type My_Number is range 0 .. 53621;
>
> This does not work on the largest unsigned integer type (mod 2**32 in 
> Janus/Ada).

Presuming Max_Int = 2**31 - 1, then I'd say range 0 .. 53621 is
perfectly legal.  It would only be illegal on a 16-bit machine.

> Ada 95 requires
>
>     type My_Number is range 0 .. 2**32-1;
>
> to be rejected, as the upper bound exceeds Max_Int. (This is
> technically a "signed_integer_type_definition", which shows the cause
> of the problem.)

But this simply stems from the requirement that Ada be efficiently
implementable on this target hardware, which has 32-bit integers.

-- 
Ludovic Brenta.

Re: Why use C++?

[Dmitry A. Kazakov]

On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:

> There are uses for wrapping types, but they are far less likely than wanting 
> overflow detection. The default should be to catch errors, not turn them 
> into different ones.

The OP mentioned image processing, the behavior frequently needed there is
saturated integer arithmetic, which is nether ranged nor modular.

As for modular types, wrapping is the mathematically correct behavior, it
is not an error.

You just cannot provide every possible arithmetic at the language level.

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

Re: Why use C++?

[Jed]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>
>> There are uses for wrapping types, but they are far less likely than 
>> wanting
>> overflow detection. The default should be to catch errors, not turn 
>> them
>> into different ones.
>
> The OP mentioned image processing, the behavior frequently needed there 
> is
> saturated integer arithmetic, which is nether ranged nor modular.
>
> As for modular types, wrapping is the mathematically correct behavior, 
> it
> is not an error.
>
> You just cannot provide every possible arithmetic at the language 
> level.
>

What do you think the practical level of limitation is? Were you thinking 
"beyond integers" with your statement? What kinds of integer types would 
you like to see built-in to a hypothetical ideal language? 

Re: Why use C++?

[Dmitry A. Kazakov]

On Thu, 11 Aug 2011 03:20:55 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
>> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>>
>>> There are uses for wrapping types, but they are far less likely than wanting
>>> overflow detection. The default should be to catch errors, not turn them
>>> into different ones.
>>
>> The OP mentioned image processing, the behavior frequently needed there is
>> saturated integer arithmetic, which is nether ranged nor modular.
>>
>> As for modular types, wrapping is the mathematically correct behavior, 
>> it is not an error.
>>
>> You just cannot provide every possible arithmetic at the language 
>> level.
>>
> 
> What do you think the practical level of limitation is?

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.

> Were you thinking "beyond integers" with your statement?

There is nothing special in integer types, except that for the types 
algebra you need ordinal numerals (i.e. at least one integer type).

> What kinds of integer types would 
> you like to see built-in to a hypothetical ideal language?

As little as possible. Usage of predefined integer types makes design more 
fragile. E.g. it is bad when somebody uses Ada's Integer, or C++ int (OK, 
in C++ there is no other option), instead of introducing a type reflecting 
the application semantics rather than the decision of some compiler vendor 
motivated by other concerns.

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

Re: Why use C++?

[Jed]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net...
> On Thu, 11 Aug 2011 03:20:55 -0500, Jed wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
>>> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>>>
>>>> There are uses for wrapping types, but they are far less likely than 
>>>> wanting
>>>> overflow detection. The default should be to catch errors, not turn 
>>>> them
>>>> into different ones.
>>>
>>> The OP mentioned image processing, the behavior frequently needed 
>>> there is
>>> saturated integer arithmetic, which is nether ranged nor modular.
>>>
>>> As for modular types, wrapping is the mathematically correct 
>>> behavior,
>>> it is not an error.
>>>
>>> You just cannot provide every possible arithmetic at the language
>>> level.
>>>
>>
>> What do you think the practical level of limitation is?
>
> 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?

>
>> Were you thinking "beyond integers" with your statement?
>
> There is nothing special in integer types, except that for the types
> algebra you need ordinal numerals (i.e. at least one integer type).

I know a little bit (enough to "be dangerous") of Intel assembly, and it 
looks like C/C++ integer types are a direct reflection of what is at that 
level. Even the fact that by default, integer literals are signed. So in 
that respect, I think they are special. They are chosen for efficiency as 
a direct reflection of hardware (I'm not saying all hardware is the same, 
mind you).

>
>> What kinds of integer types would
>> you like to see built-in to a hypothetical ideal language?
>
> As little as possible. Usage of predefined integer types makes design 
> more
> fragile. E.g. it is bad when somebody uses Ada's Integer, or C++ int 
> (OK,
> in C++ there is no other option), instead of introducing a type 
> reflecting
> the application semantics rather than the decision of some compiler 
> vendor
> motivated by other concerns.
>

You have to build those types though based upon the built-in ones, yes? 
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. And are 
not those built-ins good to use "raw" in many cases? Are you suggesting 
that a language have NO types? There is assembly language for that (and 
the instruction set pretty much dictates what types you have to work with 
at that level). 

Re: Why use C++?

[Georg Bauhaus]

On 11.08.11 12:57, Jed wrote:

> You have to build those types though based upon the built-in ones, yes? 
> 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. And are 
> not those built-ins good to use "raw" in many cases? Are you suggesting 
> that a language have NO types? There is assembly language for that (and 
> the instruction set pretty much dictates what types you have to work with 
> at that level). 

I like means to construct discrete types, for example, from
items expressible in the language without explicitly referring
to some built-in named type.  Let literals 0 and 15 be known to the
compiler.  Let the programmer say,
  "I want a ranking system, and I want the type for that system
to have values {0, ..., 15}. Plus I need the following operations,
..., but not these ..., and my "-"/'Pred function should be saturating
(if there should be operator overloading)."

In this request, does the programmer need to refer to int, or uint16_t,
or Ada's Natural, or anything for that?

- georg

Re: Why use C++?

[Nomen Nescio]

"Jed" <jehdiah@orbitway.net> wrote:

> I know a little bit (enough to "be dangerous") of Intel assembly, and it 
> looks like C/C++ integer types are a direct reflection of what is at that 
> level. Even the fact that by default, integer literals are signed. So in 
> that respect, I think they are special. They are chosen for efficiency as 
> a direct reflection of hardware (I'm not saying all hardware is the same, 
> mind you).

What?

Of course there are unsigned integers even in the twisted world of Intel.
What's more C/C++ integer types are not a direct reflection of anything
except the language spec otherwise the code would be completely not
portable.

> You have to build those types though based upon the built-in ones, yes? 
> 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. And are 
> not those built-ins good to use "raw" in many cases? Are you suggesting 
> that a language have NO types? There is assembly language for that (and 
> the instruction set pretty much dictates what types you have to work with 
> at that level). 

It's not true assembly language has no types, especially with certain
systems and certain assemblers. The type in assembly language *does*
usually reflect the native types of the underlying machine very closely,
obviously.

Re: Why use C++?

[Dmitry A. Kazakov]

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.

>>> What kinds of integer types would
>>> you like to see built-in to a hypothetical ideal language?
>>
>> As little as possible. Usage of predefined integer types makes design more
>> fragile. E.g. it is bad when somebody uses Ada's Integer, or C++ int (OK,
>> in C++ there is no other option), instead of introducing a type reflecting
>> the application semantics rather than the decision of some compiler vendor
>> motivated by other concerns.
> 
> You have to build those types though based upon the built-in ones, yes?

That depends. In Ada integer types are constructed from ranges. 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.
 
> 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.

> And are not those built-ins good to use "raw" in many cases?

Always bad. 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.

> 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. The point is that it is the application domain
requirements to drive the design, and the choice of types in particular.

> There is assembly language for that (and 
> the instruction set pretty much dictates what types you have to work with 
> at that level).

There is no language without types. That includes assembly languages.
Weak/paraconsistent typing does not mean no typing. In each context you
have a type associated with any object involved in an operation on that
object.

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

Re: Why use C++?

[Paul]

"Nomen Nescio" <nobody@dizum.com> wrote in message 
news:4209d782502610f6dbc08933d358b6d6@dizum.com...
> "Jed" <jehdiah@orbitway.net> wrote:
>
>> I know a little bit (enough to "be dangerous") of Intel assembly, and it
>> looks like C/C++ integer types are a direct reflection of what is at that
>> level. Even the fact that by default, integer literals are signed. So in
>> that respect, I think they are special. They are chosen for efficiency as
>> a direct reflection of hardware (I'm not saying all hardware is the same,
>> mind you).
>
> What?
>
> Of course there are unsigned integers even in the twisted world of Intel.
> What's more C/C++ integer types are not a direct reflection of anything
> except the language spec otherwise the code would be completely not
> portable.
>
>> You have to build those types though based upon the built-in ones, yes?
>> 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. And are
>> not those built-ins good to use "raw" in many cases? Are you suggesting
>> that a language have NO types? There is assembly language for that (and
>> the instruction set pretty much dictates what types you have to work with
>> at that level).
>
> It's not true assembly language has no types, especially with certain
> systems and certain assemblers. The type in assembly language *does*
> usually reflect the native types of the underlying machine very closely,
> obviously.
>
I think what jedhiah means is there are no types at asm level, just sizes 
such as Byte, DWord, QWord etc. These scalars are neither signed not 
unsigned but there are operations that can process the data which assumes a 
sign.
Of course there are different types if you consider scalars, real numbers, 
pointers and UDT's as different types.


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Why use C++?

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:87pqkc6fwj.fsf@ludovic-brenta.org...
> "Randy Brukardt" writes on comp.lang.ada:
...
>> Ada 95 requires
>>
>>     type My_Number is range 0 .. 2**32-1;
>>
>> to be rejected, as the upper bound exceeds Max_Int. (This is
>> technically a "signed_integer_type_definition", which shows the cause
>> of the problem.)
>
> But this simply stems from the requirement that Ada be efficiently
> implementable on this target hardware, which has 32-bit integers.

Huh? Unsigned 32-bit integers are directly supported by the machine hardware 
(on every real 32-bit processor I've ever looked at). The problem is that 
Ada requires all integers to be signed or wrap-around, which is silly.

                                         Randy.

Re: Why use C++?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>
>> There are uses for wrapping types, but they are far less likely than 
>> wanting
>> overflow detection. The default should be to catch errors, not turn them
>> into different ones.
>
> The OP mentioned image processing, the behavior frequently needed there is
> saturated integer arithmetic, which is nether ranged nor modular.

I'm not familar with any hardware on which saturated integer arithmetic is 
provided. If it was, I would expect direct language support for it (which 
need not require new kinds of types).

> As for modular types, wrapping is the mathematically correct behavior, it
> is not an error.

Right, but using modular types as a stand-in for unsigned integers doesn't 
really work.

Syntactically, Ada ought to have a way to declare an overflow-checked 
integer type without any restriction to signed/unsigned representations.

Modular types are something altogether different (and in all honesty, rare 
enough that direct language support is of dubious value -- most of us 
supported adding them to Ada 95 simply because it was the only way to get 
any support for the largest unsigned integer type).

> You just cannot provide every possible arithmetic at the language level.

No, you should have a single general integer type (with no reflection on 
"bits" or "signs"). The rest should be modeled as libraries. (I think we 
actually agree on this -- must be something in the water today. ;-) Ada has 
screwed this up (but not as badly as most languages).

                                    Randy.

Re: Why use C++?

[Jed]

"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 it 
may be too much effort for too little benefit. It seems it may be doing 
something in software that could be supported in hardware but isn't (?).
Maybe too much of a "purist" approach. I'd need more info about it and be 
convinced it is worth it before I'd put that on my shortlist of 
compelling features for a language to have. Investigation into Ada? Does 
Ada, in your opinion, "do it right/better"?

>
>>>> What kinds of integer types would
>>>> you like to see built-in to a hypothetical ideal language?
>>>
>>> As little as possible. Usage of predefined integer types makes design 
>>> more
>>> fragile. E.g. it is bad when somebody uses Ada's Integer, or C++ int 
>>> (OK,
>>> in C++ there is no other option), instead of introducing a type 
>>> reflecting
>>> the application semantics rather than the decision of some compiler 
>>> vendor
>>> motivated by other concerns.
>>
>> You have to build those types though based upon the built-in ones, 
>> yes?
>
> 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.

>  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?

>
>> 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"?

>
>> And are not those built-ins good to use "raw" in many cases?
>
> Always bad.

Pretty strong opinion there.

> 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?

>
>> 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?

> 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? Can it/should it be 
hardware-supported? Is it compromised if implemented in software?

>> There is assembly language for that (and
>> the instruction set pretty much dictates what types you have to work 
>> with
>> at that level).
>
> There is no language without types. That includes assembly languages.

"Typeless" then (quotes usually omitted for the meaning is generally 
understood).

> Weak/paraconsistent typing does not mean no typing. In each context you
> have a type associated with any object involved in an operation on that
> object.

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.

Re: Why use C++?

[Jed]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e43c072$0$6625$9b4e6d93@newsspool2.arcor-online.net...
> On 11.08.11 12:57, Jed wrote:
>
>> You have to build those types though based upon the built-in ones, 
>> yes?
>> 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. And 
>> are
>> not those built-ins good to use "raw" in many cases? Are you 
>> suggesting
>> that a language have NO types? There is assembly language for that 
>> (and
>> the instruction set pretty much dictates what types you have to work 
>> with
>> at that level).
>
> I like means to construct discrete types, for example, from
> items expressible in the language without explicitly referring
> to some built-in named type.  Let literals 0 and 15 be known to the
> compiler.  Let the programmer say,
>  "I want a ranking system, and I want the type for that system
> to have values {0, ..., 15}. Plus I need the following operations,
> ..., but not these ..., and my "-"/'Pred function should be saturating
> (if there should be operator overloading)."
>
> In this request, does the programmer need to refer to int, or uint16_t,
> or Ada's Natural, or anything for that?
>

I understand that desire. I consider that 
higher-than-close-to-the-machine level of programming for, it's just 
abstracting some underlying thing. I wonder if that is what Dmitry wants: 
a higher level of abstraction. 

Re: Why use C++?

[Jed]

"Nomen Nescio" <nobody@dizum.com> wrote in message 
news:4209d782502610f6dbc08933d358b6d6@dizum.com...
> "Jed" <jehdiah@orbitway.net> wrote:
>
>> I know a little bit (enough to "be dangerous") of Intel assembly, and 
>> it
>> looks like C/C++ integer types are a direct reflection of what is at 
>> that
>> level. Even the fact that by default, integer literals are signed. So 
>> in
>> that respect, I think they are special. They are chosen for efficiency 
>> as
>> a direct reflection of hardware (I'm not saying all hardware is the 
>> same,
>> mind you).
>
> What?

What what?

>
> Of course there are unsigned integers even in the twisted world of 
> Intel.
> What's more C/C++ integer types are not a direct reflection of anything
> except the language spec otherwise the code would be completely not
> portable.

I didn't say it was. I said it probably arose from that. I'll bet integer 
literals are signed in most assembly languages (going out on a limb with 
this, because I really don't know). Hence, a no-brainer translation of 
HLL code to assembly (recognizing, of course, that compilers are free to 
generate machine code directly, rather than generating assembly).

>
>> You have to build those types though based upon the built-in ones, 
>> yes?
>> 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. And 
>> are
>> not those built-ins good to use "raw" in many cases? Are you 
>> suggesting
>> that a language have NO types? There is assembly language for that 
>> (and
>> the instruction set pretty much dictates what types you have to work 
>> with
>> at that level).
>
> It's not true assembly language has no types,

It's generally considered "typeless" from the POV of HLL programmers. It 
has relative meaning. No need to be pedantic about it.

> especially with certain
> systems and certain assemblers. The type in assembly language *does*
> usually reflect the native types of the underlying machine very 
> closely,
> obviously.

And I'll bet, more often than not, C/C++ built-in types reflect that 
also. It would be "silly" to specify a language to what is uncommon.

Re: Why use C++?

[Robert Wessel]

On Fri, 12 Aug 2011 00:02:55 -0500, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
>news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
>> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>>
>>> There are uses for wrapping types, but they are far less likely than 
>>> wanting
>>> overflow detection. The default should be to catch errors, not turn them
>>> into different ones.
>>
>> The OP mentioned image processing, the behavior frequently needed there is
>> saturated integer arithmetic, which is nether ranged nor modular.
>
>I'm not familar with any hardware on which saturated integer arithmetic is 
>provided. If it was, I would expect direct language support for it (which 
>need not require new kinds of types).


Many DSPs, graphics coprocessors and the like have saturating integer
arithmetic, usually in addition to conventional arithmetic.  x86 has
saturating integer vector instructions as well, dating back to MMX
(PADDUSW, for example)..

Re: Why use C++?

[Jed]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:j22c61$5lo$1@munin.nbi.dk...

> Modular types are something altogether different (and in all honesty, 
> rare enough that direct language support is of dubious value -- most of 
> us supported adding them to Ada 95 simply because it was the only way 
> to get any support for the largest unsigned integer type).
>

Isn't the wrapping behavior just a consequence of wanting to get a 
representation in which signed and unsigned integers can be easily 
converted to each other? I.e., "they" didn't sit down and say, "let's 
implement unsigned integers with wrapping behavior". 

Re: Why use C++?

[Paavo Helde]

"Jed" <jehdiah@orbitway.net> wrote in news:j22ddq$7pq$1@dont-email.me:

> 
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message 
> news:j22c61$5lo$1@munin.nbi.dk...
> 
>> Modular types are something altogether different (and in all honesty, 
>> rare enough that direct language support is of dubious value -- most 
of 
>> us supported adding them to Ada 95 simply because it was the only way 
>> to get any support for the largest unsigned integer type).
>>
> 
> Isn't the wrapping behavior just a consequence of wanting to get a 
> representation in which signed and unsigned integers can be easily 
> converted to each other? I.e., "they" didn't sit down and say, "let's 
> implement unsigned integers with wrapping behavior". 

Indeed, the 2's complement representation allows to use the same hardware 
instruction for implementing the signed and unsigned addition (ditto for 
subtraction). However, this means that the hardware will raise the 
overflow flag exactly in the same fashion, so it would be equally easy to 
detect the overflow.

I guess that they were instead thinking about intermediate results. As 
the wrap-around point (zero) is very close to the common usage range of 
unsigned integers, it may well happen that in a complex arithmetic 
expression a temporary intermediate result may fall below zero whereas 
the final result will be OK again. This would in effect mean that the 
addition-subtraction operations would lose the associativity property, 
which would cause some headaches. E.g. the programmer should always use 
parens for indicating the relative order of addition and subtraction, 
e.g. a+(b-c) and take care that no intermediate result would overflow. As 
the common C/C++ implementations do not bother to check overflow even for 
the signed types, this would just mean that there would be a lot more of 
formally undefined behavior which seems to work as expected on a lot of 
hardware. So, instead of introducing a lot of UB they chose to make 
things like a+b-c legal by a simple trick of declaring the unsigned types 
wrap-around.

Yes, Ada could have been wiser, I'm sorry to hear this is not the case.

Cheers
Paavo

Re: Why use C++?

[Georg Bauhaus]

On 12.08.11 08:51, Paavo Helde wrote:

> I guess that they were instead thinking about intermediate results. As
> the wrap-around point (zero) is very close to the common usage range of
> unsigned integers, it may well happen that in a complex arithmetic
> expression a temporary intermediate result may fall below zero whereas
> the final result will be OK again. This would in effect mean that the
> addition-subtraction operations would lose the associativity property,
> which would cause some headaches. E.g. the programmer should always use
> parens for indicating the relative order of addition and subtraction,
> e.g. a+(b-c) and take care that no intermediate result would overflow. As
> the common C/C++ implementations do not bother to check overflow even for
> the signed types, this would just mean that there would be a lot more of
> formally undefined behavior which seems to work as expected on a lot of
> hardware. So, instead of introducing a lot of UB they chose to make
> things like a+b-c legal by a simple trick of declaring the unsigned types
> wrap-around.
>
> Yes, Ada could have been wiser, I'm sorry to hear this is not the case.

Sort of; Ada does have a number of definitions around overflow and
when overflow matters, when in intermediate results.

      1. with System;
      2. procedure ovfl is
      3.   type I is range 1 .. System.MAX_INT;
      4.   r, a, b, c: I;
      5. begin
      6.   a := 1;
      7.   b := I'Last;
      8.   c := 2;
      9.   r := a + b - c;  -- overflow
                  |
         >>> warning: value not in range of type "I" defined at line 3
         >>> warning: "Constraint_Error" will be raised at run time

     10.   r := a + (b - c);  -- o.K.
     11.   r := (a + b) - c;  -- overflow
                   |
         >>> warning: value not in range of type "I" defined at line 3
         >>> warning: "Constraint_Error" will be raised at run time

     12. end ovfl;


$ ./ovfl

raised CONSTRAINT_ERROR : ovfl.adb:9 overflow check failed
$

Re: Why use C++?

[Georg Bauhaus]

On 12.08.11 07:03, Jed wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote in message

>> 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 it
> may be too much effort for too little benefit. It seems it may be doing
> something in software that could be supported in hardware but isn't (?).
> Maybe too much of a "purist" approach. I'd need more info about it and be
> convinced it is worth it before I'd put that on my shortlist of
> compelling features for a language to have.

Perhaps it is info if beginners in embedded systems programming
consistently produce much better results (statistics collected
and testedover some 6 years) when they have an expressive  and
likely more intuitive type system for fundamental types.  My guess
is that the absence of representation riddles is a boon.  Put yourself
in the position of a beginner who is woken up at 5p.m. They would not
recall the rules regarding enum vs int, or the collection of traditional
idioms for declaring arrays in C, autotruncation of numeric values
to fit in the space of LHS; and likely neither the more modern
classes addressing hardware things.
   Then, will understanding the type declarations

    type Intensity is range 0 .. 255;
    for Intensity'Size use 8;
    type RGB is (Red, Green, Blue);
    type Pixel is array (RGB) of Intensity;

require much besides what is written?   Compare

    #define RGB_LIMIT 3

    typedef unsigned char Intensity;
    enum RGB {Red, Green, Blue};
    typedef Intensity Pixel[RGB_LIMIT];

and

   switch (1) {
   case 0: break;
   case CHAR_BIT == 8: break;
   }

somewhere.  If I am a beginner, what is the number of technicalities
I must know it order to understand the second way of declaring things?
(I'll leave out that the declare-like-used rule in typedef is
confusing many. Maybe that's because the typdef-ed name isn't in some
fixed position in the typedef.)

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Dmitry A. Kazakov]

On Fri, 12 Aug 2011 00:02:55 -0500, Randy Brukardt wrote:

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

>> As for modular types, wrapping is the mathematically correct behavior, it
>> is not an error.
> 
> Right, but using modular types as a stand-in for unsigned integers doesn't 
> really work.

I never felt much need in unsigned integers, except when communicating with
hardware. But then the behavior upon overflow is either irrelevant or
better be wrapping.

> Syntactically, Ada ought to have a way to declare an overflow-checked 
> integer type without any restriction to signed/unsigned representations.

Maybe, however that should not be limited to unsigned integers. If you, as
an influential ARG member, are going to change something (:-)), then,
please, consider more general shifted integer types:

   type Shifted range 100..200;
   for Shifted'First use 0; -- The first value is 100.

(Of course there should be better syntax here)

>> You just cannot provide every possible arithmetic at the language level.
> 
> No, you should have a single general integer type (with no reflection on 
> "bits" or "signs"). The rest should be modeled as libraries. (I think we 
> actually agree on this -- must be something in the water today. ;-)

As the result of so called "global warming" we have no summer third year in
a row. Much, much cold water... (:-))

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

Re: Why use C++?

[Ludovic Brenta]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> As the result of so called "global warming" we have no summer third
> year in a row. Much, much cold water... (:-))

The summer occurred in May and June this year in Europe :)

-- 
Ludovic Brenta.

Re: Why use C++?

[Georg Bauhaus]

On 12.08.11 11:45, Ludovic Brenta wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> As the result of so called "global warming" we have no summer third
>> year in a row. Much, much cold water... (:-))
> 
> The summer occurred in May and June this year in Europe :)

We need to get more flexible representation clauses for enumeration
types from climate aware compilers.  Also, multiply and statically
dispatching aspects if an Ada program needs to be portable across
planets.
  Obviously,

   type Season is (Spring, Summer, Fall, Winter)
     with (Summer => Summer (Epoch => 21 * Century,
                             Planet => Earth)),
           ...);

Redefinitions of order related operators and attributes
would be automatic.

Re: Why use C++?

[Stuart Redmann]

On 10 Aug, Randy Brukardt wrote:
> >> There are uses for wrapping types, but they are far less likely
> >> than wanting overflow detection. The default should be to catch
> >> errors, not turn them into different ones.


Dmitry A. Kazakov wrote
> > The OP mentioned image processing, the behavior frequently needed
> > there is saturated integer arithmetic, which is nether ranged
> > nor modular.
> >
> > As for modular types, wrapping is the mathematically correct
> > behavior, it is not an error.
> >
> >
> > You just cannot provide every possible arithmetic at the language
> > level.


On 11 Aug., "Jed" wrote:
> What do you think the practical level of limitation is? Were you thinking
> "beyond integers" with your statement? What kinds of integer types would
> you like to see built-in to a hypothetical ideal language?


Well, I found the following snippet on
http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-1-3-5.html:

<citation (hopefully covered by fair use ;-)>
Ada 95 introduced modular types which are of course unsigned integers.
However it has in certain cases proved very difficult to get unsigned
integers and signed integers to work together. This is a trivial
matter in fragile languages such as C but in Ada the type model has
proved obstructive. The basic problem is converting a value of a
signed type which happens to be negative to an unsigned type. Thus
suppose we want to add a signed offset to an unsigned address value,
we might have
type Offset_Type is range –(2**31) .. 2**31–1;
type Address_Type is mod 2**32;
Offset: Offset_Type;
Address: Address_Type;
We cannot just add Offset to Address because they are of different
types. If we convert the Offset to the address type then we might get
Constraint_Error and so on. The solution in Ada 2005 is to use a new
functional attribute S'Mod which applies to any modular subtype S and
converts a universal integer value to the modular type using the
corresponding mathematical mod operation. So we can now write
Address := Address + Address_Type'Mod(Offset);
</citation>

This is clearly cumbersome: We have to use a wrapping int for
Address_Type because Ada does not provide a non-signed integer as the
underlying hardware supports (at least not guaranteed by the language
spec).

Ideally, we should be able to do this:
type IncrediblyLargeType is range -1e100 .. +1e100;
and Ada provides some large number representation that is suitable for
this range (Chinese remainder theorem). Why should I worry about
performance? Remember that premature optimization is the root of all
evil. If it takes half a second for multiplication of such types, then
so be it. However, if it turns out that performance matters, I should
be able to add attributes to the type so that Ada can choose a
hardware supported representation.

I think that we could also drop the wrapping ints at all (I consider
them rather a kludge). If someone want wrapping semantics, he could
still write:
type MyType is range 0 .. 100;
MyVar : MyType;
MyVar = (MyVar * MyVar) mod 100;

Be honest, how often do you really _want_ a wrapping int?

Regards,
Stuart

Re: Why use C++?

[Vinzent Hoefler]

Stuart Redmann wrote:

> I think that we could also drop the wrapping ints at all (I consider
> them rather a kludge). If someone want wrapping semantics, he could
> still write:
> type MyType is range 0 .. 100;
> MyVar : MyType;
> MyVar = (MyVar * MyVar) mod 100;
>
> Be honest, how often do you really _want_ a wrapping int?

Thinking indices instead of pointers, quite often, actually.


Vinzent.

-- 
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

Re: Why use C++?

[Hyman Rosen]

On 8/12/2011 4:32 AM, Georg Bauhaus wrote:
> #define RGB_LIMIT 3
>
> typedef unsigned char Intensity;
> enum RGB {Red, Green, Blue};
> typedef Intensity Pixel[RGB_LIMIT];

I might do this instead as

     typedef unsigned char Intensity;
     enum RGB_Index { Red, Green, Blue, N_RGB_Index };
     typedef Intensity Pixel[N_RGB_Index];

which avoids the need for a macro and ties the number of
intensities in the array directly to its enumerated index.

> switch (1) { case 0: break; case CHAR_BIT == 8: break; }

Oh, that's cute! It's going right into my bag of tricks :-)
You don't need the breaks, though:

     switch (1) { case 0: case CHAR_BIT == 8: ; }

And with C++, you don't need executable code:

// Probe template
template <bool tf> struct probe { };
template <> struct probe<true> { typedef int t; };

// test for 8-bit char
typedef probe<CHAR_BIT == 8>::t is_char_8_bit;

> If I am a beginner, what is the number of technicalities I
 > must know it order to understand the second way of declaring
 > things?

A few; of course, when I was a complete Ada beginner (not that
I'm much more than that now) I was always thrown by the use of
apostrophes as attribute designators. When I see

     for Intensity'Size use 8;

it makes me want to go off searching for where the string ends
and trying to figure out what's going on. I also don't know that
a beginner finds the notion of an enumerated type declared as an
array index to be immediately obvious.

> (I'll leave out that the declare-like-used rule in typedef is
> confusing many. Maybe that's because the typdef-ed name isn't in some
> fixed position in the typedef.)

Re: Why use C++?

[Jed]

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

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? And do you want that in exclusion of well-defined primitive 
integers?

>>> 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? Aren't they just "syntactic" 
sugar over some well-defined primitives? Wouldn't they have to be? I.e., 
at some point, the hardware has to be interfaced.

>>>  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).

> (The way compiler would implement that type is uninteresting,

Ha! To me that is KEY.

> so long we are considering only the type interface).

Abstraction. High level.

>
>>>> 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.

OK, good. That's what I though you meant but just making sure we are on 
the same page.

>
>>> 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.

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

>
>>>> 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.

>
>>> 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"?

>
>> 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?

>
>> 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.
>

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Jed]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e44e50a$0$7619$9b4e6d93@newsspool1.arcor-online.net...
> On 12.08.11 07:03, Jed wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote in message
>
>>> 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 
>> it
>> may be too much effort for too little benefit. It seems it may be 
>> doing
>> something in software that could be supported in hardware but isn't 
>> (?).
>> Maybe too much of a "purist" approach. I'd need more info about it and 
>> be
>> convinced it is worth it before I'd put that on my shortlist of
>> compelling features for a language to have.
>
> Perhaps it is info if beginners in embedded systems programming
> consistently produce much better results (statistics collected
> and testedover some 6 years) when they have an expressive  and
> likely more intuitive type system for fundamental types.

While that is definitely a good characteristic, I can't evaluate it 
without knowing what effort it takes to get it. Certainly something like 
ranged types is easily doable. I'm not sure the scope of what is being 
called for by those calling for it (e.g., Dmitry), that's the problem. I 
ranges is one thing, what are the others?

> My guess
> is that the absence of representation riddles is a boon.

I would say that abstraction is nice sometimes, but if you don't have any 
guarantee of the representation, then that is necessarily a higher-level 
language than C and C++ are (i.e., higher than "close to the metal).

> Put yourself
> in the position of a beginner who is woken up at 5p.m. They would not
> recall the rules regarding enum vs int, or the collection of 
> traditional
> idioms for declaring arrays in C, autotruncation of numeric values
> to fit in the space of LHS; and likely neither the more modern
> classes addressing hardware things.

Some of those things are decicely deficient, yes, but that is not to say 
that abstracting-away the representation is always good. Indeed, do that 
and you have a 4GL rather than a 3GL.

>   Then, will understanding the type declarations
>
>    type Intensity is range 0 .. 255;
>    for Intensity'Size use 8;

Oh, but I thought you desired to abstract-away the representation. What's 
that "Size use 8", then, all about?

>    type RGB is (Red, Green, Blue);
>    type Pixel is array (RGB) of Intensity;
>
> require much besides what is written?   Compare
>
>    #define RGB_LIMIT 3
>
>    typedef unsigned char Intensity;
>    enum RGB {Red, Green, Blue};
>    typedef Intensity Pixel[RGB_LIMIT];
>
> and
>
>   switch (1) {
>   case 0: break;
>   case CHAR_BIT == 8: break;
>   }
>
> somewhere.  If I am a beginner, what is the number of technicalities
> I must know it order to understand the second way of declaring things?
> (I'll leave out that the declare-like-used rule in typedef is
> confusing many. Maybe that's because the typdef-ed name isn't in some
> fixed position in the typedef.) 

Re: Why use C++?

[Fritz Wuehler]

"Jed" <jehdiah@orbitway.net> wrote:

> 
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message 
> news:j22c61$5lo$1@munin.nbi.dk...
> 
> > Modular types are something altogether different (and in all honesty, 
> > rare enough that direct language support is of dubious value -- most of 
> > us supported adding them to Ada 95 simply because it was the only way 
> > to get any support for the largest unsigned integer type).
> >
> 
> Isn't the wrapping behavior just a consequence of wanting to get a 
> representation in which signed and unsigned integers can be easily 
> converted to each other? I.e., "they" didn't sit down and say, "let's 
> implement unsigned integers with wrapping behavior". 

More likely it's a consequence of doing nothing, because the natural
behavior of the hardware is that unsigned integers wrap. Unless there was a
specific language feature designed to prevent this, that is how it will work
on most platforms.

Re: Why use C++?

[Stuart Redmann]

Stuart Redmann wrote:
[snip]
> > Be honest, how often do you really _want_ a wrapping int?


On 12 Aug. Vinzent Hoefler wrote:
> Thinking indices instead of pointers, quite often, actually.

Could you please provide some example? Seriously, I'm really
interested in the usage of wrapping types since in the last ten years
I have not felt the need for wrapping ints at all (well, maybe two or
three times).

>
> Vinzent.
>
> --
> f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

LOL, I like your signature.

Re: Why use C++?

[Ludovic Brenta]

Georg Bauhaus wrote on comp.lang.ada:
> On 12.08.11 11:45, Ludovic Brenta wrote:
>
>> "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> writes:
>>> As the result of so called "global warming" we have no summer third
>>> year in a row. Much, much cold water... (:-))
>
>> The summer occurred in May and June this year in Europe :)
>
> We need to get more flexible representation clauses for enumeration
> types from climate aware compilers.  Also, multiply and statically
> dispatching aspects if an Ada program needs to be portable across
> planets.

And their satellites, obviously.  Things could become pretty messy in
binary star systems, too.  Think of a satellite on a retrograde orbit
(like Triton) around a heavy planet (like Neptune) that is in forward
rotation around the center of gravity of a binary star system...

>   Obviously,
>
>    type Season is (Spring, Summer, Fall, Winter)
>      with (Summer => Summer (Epoch => 21 * Century,
>                              Planet => Earth)),
>            ...);
>
> Redefinitions of order related operators and attributes
> would be automatic.

Don't forget the hemispheres and that seasons depend on latitude.  For
example, between -15 and +15 degrees on Earth there is only one
season; between 15 and 35 degrees, two seasons (dry and wet); between
35 and 72 degrees, four; above 72, two again (day and night).

Also, on some planets (e.g. Mars), the four seasons have different
lengths due to the eccentricity of the orbit.

We need an AI for that...

--
Ludovic Brenta.
The clients strategize efficient, forward-looking, trigger events.

Re: Why use C++?

[Adam Beneschan]

On Aug 11, 10:16 pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> On Fri, 12 Aug 2011 00:02:55 -0500, "Randy Brukardt"
>
>
>
>
>
> <ra...@rrsoftware.com> wrote:
> >"Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message
> >news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
> >> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
>
> >>> There are uses for wrapping types, but they are far less likely than
> >>> wanting
> >>> overflow detection. The default should be to catch errors, not turn them
> >>> into different ones.
>
> >> The OP mentioned image processing, the behavior frequently needed there is
> >> saturated integer arithmetic, which is nether ranged nor modular.
>
> >I'm not familar with any hardware on which saturated integer arithmetic is
> >provided. If it was, I would expect direct language support for it (which
> >need not require new kinds of types).
>
> Many DSPs, graphics coprocessors and the like have saturating integer
> arithmetic, usually in addition to conventional arithmetic.

TI c6x series, for example (that's the one I'm most familiar with).

                                -- Adam

Re: Why use C++?

[Bill Findlay]

On 12/08/2011 16:50, in article
e9987381-4f7b-4d25-9c9b-429fd4da74f6@k15g2000yqd.googlegroups.com, "Stuart
Redmann" <DerTopper@web.de> wrote:

> Stuart Redmann wrote:
> [snip]
>>> Be honest, how often do you really _want_ a wrapping int?
> 
> On 12 Aug. Vinzent Hoefler wrote:
>> Thinking indices instead of pointers, quite often, actually.
> 
> Could you please provide some example? Seriously, I'm really
> interested in the usage of wrapping types since in the last ten years
> I have not felt the need for wrapping ints at all (well, maybe two or
> three times).

In my current project, the following are all defined in one unit:

   type nest_depth is mod 19;
   type sjns_depth is mod 17;

   type word is mod 2**48;
   type field_of_16_bits is mod 2**16;
   type syllable is mod 2**8;
   type halfword is mod 2**24;
   type symbol is mod 2**6;
   type symbol_number is mod 8;

   type microseconds is mod 2**64;
   type priority is mod 2**2;
   type one_bit is mod 2;
   type context is mod 2**2;
   type INS_kind is mod 2**2;
   type order_counter is mod 2**64;

For most of these, the wrapping behaviour is exactly what is needed
to model computer hardware (they are from a KDF9 emulator).

nest_depth and sjns_depth, in particular, are the index types of cyclic
buffers.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Why use C++?

[Georg Bauhaus]

On 12.08.11 17:14, Jed wrote:

>>   Then, will understanding the type declarations
>>
>>    type Intensity is range 0 .. 255;
>>    for Intensity'Size use 8;
> 
> Oh, but I thought you desired to abstract-away the representation. What's 
> that "Size use 8", then, all about?


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.

Considering the RGB array example, you'd have to know that
the imaginary display hardware works better (or at all) if
Intensity values are 8 bit, and components aligned on 8 bit
boundaries, say.  Or that this must be so because a driver
program expects data shaped this way. Typically, though,
data representation is something a compiler should know
better, but of course nothing should be in the way of
a hardware savvy programmer.  Directing compilers can be
beneficial.  Still, this kind of direction should not
steer the structure of a solution.

When have you last thought about the size of the components
of std::string, of of a vtable?  Why, then, is there a
pressing need to think about the sizes of int types?

A few programming issues typically arising from choice of
type.  They key word here is "typical", as in "real world":

1. Change of platform.

A programmer uses language defined type int (or Integer)
all over the place, assuming that objects of the type will
have 32 bit words.  Later, the program should be ported
to a 16 bits platform.  Ouch!  May need to review the entire
program.

The C solution is to at least become aware of the powers of
typedef + discipline + conventions.  Add assertions, compile
time assertions already mentioned, or templates like Hyman
Rosen's. Try isolating and checking the consequences of type
choice. In any case, this seems like a fair bit of mechanism,
and procedures in a programming organization that is outside
the language.

An Ada solution is to avoid Integer where possible
and declare the types you need in the most natural way,
which is by specifying the range of values you need.
Full stop.  (Well, mostly, but is is a lot easier and
to achieve the same goal.)

Any language with a natural way of defining types from abstract
problem domain knowledge has the same advantage in that the
definition doesn't refer to types like int or Integer, but
to the non-changing abstract solution.

2. Changing representation.

When I want to change a type's objects' representation, I must
pick a different type in C.  In Ada (or ...), I'll leave the type
declaration as is, and ask the compiler to represent it differently.
The rest of the program's logic is not affected, as the type's
value set stays the same.

The C way slightly reverses thinking about the program,
then. You must start from the set of fundamental types
and from the set of values they happen to have in some
implementation. Not from the values you need.  You cannot
declare a type that includes precisely the values required
by your solution.  You can apply your knowledge of
the implementation when choosing a type that best
represents your "real" type.  Using C++, I imagine you
can produce clever template computations to this effect.
I'm only guessing, though.  All of this, however, is not as
simple as simply stating that your type's value set should
be such-and-such.

As a simpler example, consider percentages as whole numbers
between 0 and 100.

An exception is when the program is about hardware.
Side note: it is a requirement that an Ada implementation
make all "hardware types" that it supports available to the
programmer.

Re: Why use C++?

[Jed]

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

What more definition do you want? Size guarantee? Other than that, what 
is ambiguous (platform-specific) about C++ int?

>
>>>>> 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?

>
>> 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).

>
>> 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 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.

Just another layer of abstraction. So it's as simple as that (another 
layer of abstraction), yes?

>
>>> (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). You've 
been having a compiler implementation discussion?

>
>>>>> 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.

Sure, it doesn't matter in the case of the loop variable.

>  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.

While that paradigm does have a place, that place is not "everywhere". 
That would be throwing the baby out with the bath water.

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.

>
>>>>>> 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.

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

> 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.

>>>>> 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.

>
>>>> 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?

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

Re: Why use C++?

[Jed]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4e4560e7$0$6546$9b4e6d93@newsspool4.arcor-online.net...
> On 12.08.11 17:14, Jed wrote:
>
>>>   Then, will understanding the type declarations
>>>
>>>    type Intensity is range 0 .. 255;
>>>    for Intensity'Size use 8;
>>
>> Oh, but I thought you desired to abstract-away the representation. 
>> What's
>> that "Size use 8", then, all about?
>
>
> 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. Unless, of course, you are suggesting 
that IO should be abstracted away. Which is fine, if you want that, but 
it necessarily moves one into 4GL-land.

>
> Considering the RGB array example, you'd have to know that
> the imaginary display hardware works better (or at all) if
> Intensity values are 8 bit, and components aligned on 8 bit
> boundaries, say.  Or that this must be so because a driver
> program expects data shaped this way. Typically, though,
> data representation is something a compiler should know
> better, but of course nothing should be in the way of
> a hardware savvy programmer.  Directing compilers can be
> beneficial.  Still, this kind of direction should not
> steer the structure of a solution.

So the benefit, then, just not having to learn something? An electric 
food slicer so that the knives can be put in a locked box?

>
> When have you last thought about the size of the components
> of std::string, of of a vtable?  Why, then, is there a
> pressing need to think about the sizes of int types?

You know that that was a very bad comparison. Completely invalid.

>
> A few programming issues typically arising from choice of
> type.  They key word here is "typical", as in "real world":
>
> 1. Change of platform.
>
> A programmer uses language defined type int (or Integer)
> all over the place, assuming that objects of the type will
> have 32 bit words.  Later, the program should be ported
> to a 16 bits platform.  Ouch!  May need to review the entire
> program.

Such is a language that must maintain backward compatibility. Easy 
solution: don't use int (and learn the language you are programming in). 
The above is a bug. Sure, it was cause by the failings of the language, 
but one is supposed to know those "gotchas". C++ is not for "quick and 
dirty" programming tasks unless one is highly skilled in the usage of the 
language, knowing the ins and outs. Yes, it's easy to imagine something 
better, but that isn't C++, and the comments being made in this thread (I 
keep saying this) seem to want to move from 3GL territory to 4GL.

>
> The C solution is to at least become aware of the powers of
> typedef + discipline + conventions.  Add assertions, compile
> time assertions already mentioned, or templates like Hyman
> Rosen's. Try isolating and checking the consequences of type
> choice. In any case, this seems like a fair bit of mechanism,
> and procedures in a programming organization that is outside
> the language.
>
> An Ada solution is to avoid Integer where possible
> and declare the types you need in the most natural way,
> which is by specifying the range of values you need.
> Full stop.  (Well, mostly, but is is a lot easier and
> to achieve the same goal.)

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".

>
> Any language with a natural way of defining types from abstract
> problem domain knowledge has the same advantage in that the
> definition doesn't refer to types like int or Integer, but
> to the non-changing abstract solution.

Still, 80% solutions are good sometimes too. That "last 10%" can 
exponential increase <something>. (something = complexity or $ or 
time...). So, scope first, then gap analysis (and other analyses) to 
determine if it is worthwhile. Ranged integers? Sure, why not. Something 
more than that, well, the whole scope needs to be presented.

>
> 2. Changing representation.
>
> When I want to change a type's objects' representation, I must
> pick a different type in C.  In Ada (or ...), I'll leave the type
> declaration as is, and ask the compiler to represent it differently.
> The rest of the program's logic is not affected, as the type's
> value set stays the same.

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

>
> The C way slightly reverses thinking about the program,
> then. You must start from the set of fundamental types
> and from the set of values they happen to have in some
> implementation. Not from the values you need.  You cannot
> declare a type that includes precisely the values required
> by your solution.

I think that may be an incremental improvement from the application 
development standpoint. If it was exclusively that, it could become 
tedious. From the compiler implementation standpoint, maybe not worth 
doing too many things beyond, say, ranged integers. Again, what is the 
scope of your proposal? Just saying "a semantically rich programming 
language..." is quite nebulous. I'd like to see a list or something. 1. 
Ranged integers. 2. Scoped strong enums (got that already). 3. ???

>You can apply your knowledge of
> the implementation when choosing a type that best
> represents your "real" type.  Using C++, I imagine you
> can produce clever template computations to this effect.
> I'm only guessing, though.  All of this, however, is not as
> simple as simply stating that your type's value set should
> be such-and-such.
>
> As a simpler example, consider percentages as whole numbers
> between 0 and 100.
>
> An exception is when the program is about hardware.
> Side note: it is a requirement that an Ada implementation
> make all "hardware types" that it supports available to the
> programmer.

Ah ha! ;) In conjunction with all you've said so far, I'll bet you will 
say that IO should companionally be abstracted-away too. That's fine, but 
now, is that a programming language, or an environment? How far on that 
track do you go before you start calling the language "Windows"? 

Re: Why use C++?

[Jed]

"Fritz Wuehler" <fritz@spamexpire-201108.rodent.frell.theremailer.net> 
wrote in message 
news:e42b54adb274b7447820bb6982baf6f5@msgid.frell.theremailer.net...
> "Jed" <jehdiah@orbitway.net> wrote:
>
>>
>> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
>> news:j22c61$5lo$1@munin.nbi.dk...
>>
>> > Modular types are something altogether different (and in all 
>> > honesty,
>> > rare enough that direct language support is of dubious value -- most 
>> > of
>> > us supported adding them to Ada 95 simply because it was the only 
>> > way
>> > to get any support for the largest unsigned integer type).
>> >
>>
>> Isn't the wrapping behavior just a consequence of wanting to get a
>> representation in which signed and unsigned integers can be easily
>> converted to each other? I.e., "they" didn't sit down and say, "let's
>> implement unsigned integers with wrapping behavior".
>
> More likely it's a consequence of doing nothing, because the natural
> behavior of the hardware is that unsigned integers wrap. Unless there 
> was a
> specific language feature designed to prevent this, that is how it will 
> work
> on most platforms.
>

Ah ha! Confirmation comes. I hypothesized similar, further up in the 
thread. 

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Ludovic Brenta]

Jed writes:
>> When have you last thought about the size of the components
>> of std::string, of of a vtable?  Why, then, is there a
>> pressing need to think about the sizes of int types?
>
> You know that that was a very bad comparison. Completely invalid.

On the contrary I think this comparison is perfectly valid.  The
language should distinguish between integers (i.e. numbers) and various
kinds of machine registers.  If you think you need to know the number of
bits in an int, this indicates you are dealing with low-level stuff and
therefore need something much more precise than "int", which specifies
not only size in bits but also bit-endianness, byte-endianness,
alignment, permissible operations and, if arithmetic is possible at all,
overflow semantics.  C conveniently ignores all these things and leaves
them unspecified.  With Ada, the programmer can specify most of those
aspects (except, sadly, for byte-endianness).

If you confuse "size of an int" for "range of permissible values for an
int", then you ignore the possibility that the range might not fit at
all with any size in bits, e.g.

subtype Fridge_Temperature is range 250 .. 313; -- kelvins

Most of the time, you do *not* need to know the size of an int; instead
you need to know the size of a hardware register, field in a network
protocol, etc and these are, quite often, *not* numbers.

-- 
Ludovic Brenta.
The Chief Legal Officer proactively enables our potentials. 

Re: Why use C++?

[Fritz Wuehler]

"Jed" <jehdiah@orbitway.net> wrote:

> I didn't say it was. I said it probably arose from that. I'll bet integer 
> literals are signed in most assembly languages (going out on a limb with 
> this, because I really don't know).

Absolutely not. Assembly language is about talking to the machine directly.
If you can't manipulate native types then your assembler isn't an assembler.

> Hence, a no-brainer translation of  HLL code to assembly (recognizing, of
> course, that compilers are free to generate machine code directly, rather
> than generating assembly).

Most (vast majority) of the compilers on IBM platforms generate object
code. It sounds like you think a goal of HLL design is to be easy to
implement. That's wrong. The goal of HLL design is to make it easy to solve
problems in the problem domain.

> It's generally considered "typeless" from the POV of HLL programmers. It 
> has relative meaning. No need to be pedantic about it.

It wasn't pedantic, it was a simple comment from an assembly coder. Assembly
is typed or it wouldn't be useful. However there's no type enforcement at
the assembler level (usually, although at the hardware level there is.)
That is no the same as not being typed, although to an HLL programmer it may
not be obvious that those two things are not one and the same.

> > especially with certain
> > systems and certain assemblers. The type in assembly language *does*
> > usually reflect the native types of the underlying machine very 
> > closely,
> > obviously.
> 
> And I'll bet, more often than not, C/C++ built-in types reflect that 
> also. It would be "silly" to specify a language to what is uncommon.

You have the tail wagging the dog. The C/C++ built-in types don't reflect
anything but the language design and they don't change their meaning from
platform to platform or from implementation to implementation. That's why
they're types. Incidentally they often map to native types on most
architectures which is why they were created in the first place. But now
that they have been created the people using C/C++ have to live with those
types or build abstract data types on top of them.

> It would be "silly" to specify a language to what is uncommon.

That's exactly the point of HLL. It must provide useful abstractions for
the problem domain. The underlying implementation should not matter at all.

Re: Why use C++?

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message 
news:4e45276d$0$13269$a8266bb1@newsreader.readnews.com...
...
> A few; of course, when I was a complete Ada beginner (not that
> I'm much more than that now) I was always thrown by the use of
> apostrophes as attribute designators. When I see
>
>     for Intensity'Size use 8;
>
> it makes me want to go off searching for where the string ends
> and trying to figure out what's going on. I also don't know that
> a beginner finds the notion of an enumerated type declared as an
> array index to be immediately obvious.

In Ada 2012, you could write this as part of the type declaration (much 
preferable, IMHO):

   type Intensity is range 0 .. 255
       with Size => 8;

and then you wouldn't have to guess what the apostrophe means. You'd still 
have to guess what "Size" means (bits or bytes? It's fairly obvious here, 
but not always).

                                     Randy.

Re: Why use C++?

[Jed]

"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.


>> 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. Consider it deprecated. Some baggage stays around for
compatibility even when new constructs are introduced.

>
>>>>>>> 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.

Interesting.

>
> 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? You don't have to use int. You probably
should never use it. It's virtually useless (maybe not just "virtually"
either). Why would you use int instead of another integer type? You have
a bunch of others to pick from.

> 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).

So much for dumping knowledge of the representation then.

>
>>>> 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.

Yeah, I went to far. I should have left out "across machines".

>
>>>> 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.

But they are precisely specified on any given platform. I think you are 
seeking to abstract that away into the implementation. So you want more 
than just "precisely specified" (for it is already so), you want it 
hidden away.

>
>>>>> 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?

Either 32-bits or 64-bits depending if I'm on Win32 or Win64 
(little-endian and 2's complement is a given). ;)

> 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.

>
>>>>> (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.

>>> 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. Sure, one can easily move to the more general meaning 
of "contract' and use it when talking just about anything, but that's to 
dilute the waters that are "design by contract".

>> 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.

Your strongly-believed, but wrong, opionion noted.

>
>> 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.

>
>>> 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.

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)? 
Is a comparison of Ada and C++ pretty much that answer?

>
>>>>>> 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.

Does Ada meet your desired requirements?

>
>> 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.
>

And not hold our breaths! 

Re: Why use C++?

[Stephen Leake]

Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
writes:

> "Jed" <jehdiah@orbitway.net> wrote:
>
>> 
>> "Randy Brukardt" <randy@rrsoftware.com> wrote in message 
>> news:j22c61$5lo$1@munin.nbi.dk...
>> 
>> > Modular types are something altogether different (and in all honesty, 
>> > rare enough that direct language support is of dubious value -- most of 
>> > us supported adding them to Ada 95 simply because it was the only way 
>> > to get any support for the largest unsigned integer type).
>> >
>> 
>> Isn't the wrapping behavior just a consequence of wanting to get a 
>> representation in which signed and unsigned integers can be easily 
>> converted to each other? I.e., "they" didn't sit down and say, "let's 
>> implement unsigned integers with wrapping behavior". 
>
> More likely it's a consequence of doing nothing, because the natural
> behavior of the hardware is that unsigned integers wrap. 

The natural behavior of the hardware is that signed integers wrap, as
well.

-- 
-- Stephe

Re: Why use C++?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 12 Aug 2011 00:02:55 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
>> news:1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net...
>
>>> As for modular types, wrapping is the mathematically correct behavior, it
>>> is not an error.
>> 
>> Right, but using modular types as a stand-in for unsigned integers doesn't 
>> really work.
>
> I never felt much need in unsigned integers, 

I use them all the time for event counters, that often can overflow in a
long-running system, so the wrapping behavior is important.

I agree it would be nice to declare other integer semantics and still
have literals.

-- 
-- Stephe

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Ian Collins]

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

Re: Why use C++?

[Georg Bauhaus]

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.

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Georg Bauhaus]

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.

Re: Why use C++?

[Georg Bauhaus]

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.

Re: Why use C++?

[Ian Collins]

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

Re: Why use C++?

[Georg Bauhaus]

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.

Re: Why use C++?

[Brian Drummond]

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

Re: Why use C++?

[Simon Wright]

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).

Re: Why use C++?

[Ian Collins]

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

Re: Why use C++?

[Jed]

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).

>
>>>> 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.

Consider it ancillary, for there are other integer types. Singling out 
int is a strawman, for while it is a failure, it is not the only avenue 
in the language.

>
>>> 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.

I agree (did you mean in C++, or in general?). I have a feeling you meant 
in general. In that case, again, I'm not sure that having some of those 
monikers isn't the best compromise.  You know, the 80% rule.

>  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). Ah, but you 
are going to say that that is just convenient coincidence. You could be 
right. I'm not sure at this point. Again, purest approach vs. practical 
compromise is the issue.

>
>>> 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.

"platform" = hardware + OS (if there is one) + compiler.

> 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.

> The answer that it is
> defined somewhere somehow is not an argument at all, anything works
> in this or that way.

Who's arguing? First of all, I wouldn't use int, but if I did, I would 
know what "int" was. Everything does not require cross-platform 
portability.

>
> 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. Your 
own.

> The type's properties shall be defined by the application domain.

If you say so, but that is maybe too much effort for too little gain. 
TBD.

>
>>> 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.

I guess I'll just have to wait and try this other language when you are 
done implementing it. ;)?

>
>>>>>>> (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.

Language design includes foresight into the implementation. Else it's 
just pondering some theoretical ideal. Academic research vs. practical 
engineering.

>
>>>>> 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).

>
> But design by contract is a mere engineering principle,

And a bit more. I always took it as a paradigm associated with a specific 
product (Eiffel). As a matter of fact, I felt kind of "irked" when it was 
presented as "something new" for before that, it was engineering 
technique. I mean, "it's like.. the function/method specification is a 
"contract"... blah, blah", well, duh! But, I digress.

> it applies
> absolutely everywhere in engineering. If you disagree, please, show
> examples.

That's what I meant by saying you can choose to use the terminology in a 
general way, to which I "retort", "well, duh!". Statements of the 
obvious, so what?

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

When I see "Design by Contract", my mind automagically puts a "tm" after 
it. Not that I'm knocking anything.

>
>>>> 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.

The whole time, I've been trying to get a handle on this "nebulous" (to 
me) ideal language of yours and how it differs from "the low hanging 
fruit" of traditional language design and implementation. I furthered 
saying that I have a feeling you are seeking some "purist" ideal or 
something for comp sci labs in academia. That's about it.

>
>> 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.

> 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++.

That's not saying much of anything. Compare it to C.

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

I wonder if there is more to discover in using it than just reading about 
it. I think it has this "module as class-like thing" that seems so 
archaic, so I would fight it at every step of coding, so maybe I'll stick 
to just reading more about it. 

Re: Why use C++?

[Jed]

Dmitry A. Kazakov wrote:

> First of all, performance is not a functional requirement.

What planet are you from? Of course it is a functional requirement. I.e, 
where performance matters and is thus specified. Nuff said. Not worthy of 
a tangent thread of discussion. But not meant to curb any thoughts, and 
yes, this statement of yours does not need any surrounding context, for 
you made the dirrect statement.

Re: Why use C++?

[Jed]

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. Yes, it decidedly does not belong in a language, for 
it is for a compiler to worry about. OTOH, (the other extreme), total 
abstraction from the machine is <something> because ... ah ha! I know 
why. :) OK, figured it out. "Nevermind".

> 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.

OK, but after the hardware guys all conform to a standard. Till then, it 
ain't happenin. 

Re: Why use C++?

[Jed]

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.

It's not a language thing. You would need to trust the hardware guys to 
do that. I'm all for it, as long as it is a homeless person, and not 
someone who has had 50 instead of 15 minutes of fame already, while 
someone is worried about the onset of winter. 

Re: Why use C++?

[Jed]

Georg Bauhaus wrote:
> 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!

Maybe true, but maybe I'd agree, and maybe I'd maybe I'd "bail out" at 
the last step before boarding the airplane, which of course I could maybe 
never ever do, for being so afraid of being in the sky under someone(s) 
else's control... I mean, like Rain Man.

>
> Short summary:
>
> Declaring a type for computation does *not* require specification
> of representation.

That goes without saying. But maybe I LIKE it that way.

> However, should it become necessary

It's not a question of necessity.

> 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.

Maybe, but maybe that is too "pie in the sky" academia/wishful-thinking, 
etc. Who are the beneficiaries of such and it is a benefit at all?

>
>
> (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.)

I know what a 4GL is, do you? ;)

>
> 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.

Pfft. There is no "int", "long", "short"... but there is int32, uint8, 
etc. Don't bother me with past mistakes. Given that, then move on. All 
else is banter/irrelevant (to progress).

>
> 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.

Ech, I have to skip past example code mostly. Until the higher level is 
worked out. "Design in code" is a fantasy (for the most part, it is just 
wailing on the guitar, which is, of course, masturbation).

>
> 2. (Conversion) Suppose I/O means writing a number of structured
> objects to a stream.

Suppose? Suppose this: there is no "stream". :P
 

Re: Why use C++?

[Jed]

Georg Bauhaus wrote:
> On 12.08.11 21:51, Jed wrote:
>
>> So the benefit, then, just not having to learn something?
>
>
> "Oh no, not again."

What.

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

If you chose the path to implement program P, then it behooves you to 
understand the tool you choose to do that with. Else you may end up with 
less than five digits on your right hand (assuming you are right-handed).

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

If one is a "soul-searching geriatric", or a "penis-bound adolescent", 
your theory "holds" (probably not). So who died and left you boss?

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

The consequences of choice.

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

But maybe one would want to. And maybe one would choose not to tell you 
why! :P

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

Isn't that why the USA "economy" is bust? Don't make me say "snakeoil". 
(And for your info, Mr. High on His Horse, I have a college degree, not a 
QED (so don't even start this shit that you are smarter than me) :P ).

[snippage]

Re: Why use C++?

[Jed]

Georg Bauhaus wrote:
> 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,

(attempt at "appeal to authority" noted)

> the language should

"should" doesn't fly on Wikipedia.

> 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.

Do "call me" when your thoughts are accepted on Wikipedia.

>
> A positive addition:

Oh, you were being "negative"?  I didn't notice!

> we

Who is "we"? Trying to include me, unsuspecting, may be a warring action. 
So just don't do that anymore.

> already have alternative ways of
> declaring types and they lead to exactly as efficient
> programs.

It's called reality. Deal with it (better than you dad did, an of course 
your mom does not matter). I didn't say accept it.

>
> These types are an interesting challenge, anyway.

Your types are known, and not interesting.

> A few compiler
> writers

There is no such thing.

> 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?

Dmitry "knows" that. Ask him.

>> 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.

I assure you I know abstraction. You can take your "vote", and shove it 
up your ass. Cry me a river. Reap what you sow.

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Jed]

Fritz Wuehler wrote:
> "Jed" <jehdiah@orbitway.net> wrote:
>
>> I didn't say it was. I said it probably arose from that. I'll bet
>> integer literals are signed in most assembly languages (going out on
>> a limb with this, because I really don't know).
>
> Absolutely not.

Liar.

> Assembly language is about talking to the machine
> directly. If you can't manipulate native types then your assembler
> isn't an assembler.
>

Pedantic "discussion" is annoying to me, so curb it.

>> Hence, a no-brainer translation of  HLL code to assembly
>> (recognizing, of course, that compilers are free to generate machine
>> code directly, rather than generating assembly).
>
> Most (vast majority) of the compilers on IBM platforms generate object
> code.

Their loss! ;)

> It sounds like you think a goal of HLL design is to be easy to
> implement.

The goal? What "goal" are you on about?

> That's wrong.

What is "right" and what is "wrong". (This is great, because you know 
this and everyone else wants to know, right? Do tell, what is WRONG, and 
right.)

>The goal of HLL design

I didn't know it was a <something>.

>  is to make it easy to
> solve problems in the problem domain.

The pageant queen saying "world peace". You can't hang dude. She is 
pretty and has value, while you have none.

>
>> It's generally considered "typeless" from the POV of HLL
>> programmers. It has relative meaning. No need to be pedantic about
>> it.
>
> It wasn't pedantic,

I said it was, so it is. Don't F with me.

> it was a simple comment from an assembly coder.

Bah.

> Assembly is typed or it wouldn't be useful.

Strawman. Context matters.

> However there's no type
> enforcement at the assembler level (usually, although at the hardware
> level there is.)

masturbation.

> That is no the same as not being typed, although to
> an HLL programmer it may not be obvious that those two things are not
> one and the same.
>
>>> especially with certain
>>> systems and certain assemblers. The type in assembly language *does*
>>> usually reflect the native types of the underlying machine very
>>> closely,
>>> obviously.
>>
>> And I'll bet, more often than not, C/C++ built-in types reflect that
>> also. It would be "silly" to specify a language to what is uncommon.
>
> You have the tail wagging the dog.

Says the adolescent with dick in hand.

> The C/C++ built-in types don't
> reflect anything but the language design

Your you inquisitiveness noted. But what about all those people you 
killed?

>
>> It would be "silly" to specify a language to what is uncommon.
>
> That's exactly the point of HLL. It must provide useful abstractions
> for the problem domain. The underlying implementation should not
> matter at all.

You have not platform. You are a killer. Men kill. Women don't. 

Re: Why use C++?

[Jed]

Ludovic Brenta wrote:
> Jed writes:
>>> When have you last thought about the size of the components
>>> of std::string, of of a vtable?  Why, then, is there a
>>> pressing need to think about the sizes of int types?
>>
>> You know that that was a very bad comparison. Completely invalid.
>
> On the contrary I think this comparison is perfectly valid. ]

Who cares what you think?

Re: Why use C++?

[Dmitry A. Kazakov]

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

Re: Why use C++?

[Nomen Nescio]

"Jed" <jehdiah@orbitway.net> wrote:

> Fritz Wuehler wrote:
> > "Jed" <jehdiah@orbitway.net> wrote:
> >
> >> I didn't say it was. I said it probably arose from that. I'll bet
> >> integer literals are signed in most assembly languages (going out on
> >> a limb with this, because I really don't know).
> >
> > Absolutely not.
> 
> Liar.

Dumb jerkoff.

> > Assembly language is about talking to the machine
> > directly. If you can't manipulate native types then your assembler
> > isn't an assembler.
> >
> 
> Pedantic "discussion" is annoying to me, so curb it.

I really don't care what's annoying to you or not. This is usenet, if you
don't like it, go fuck yourself. Nobody will miss you.

> >> Hence, a no-brainer translation of  HLL code to assembly
> >> (recognizing, of course, that compilers are free to generate machine
> >> code directly, rather than generating assembly).
> >
> > Most (vast majority) of the compilers on IBM platforms generate object
> > code.
> 
> Their loss! ;)

Wrong again, shit-for-brains. They've been doing it before your mom had the
ten or so guys who could claim they were your father.


> Says the adolescent with dick in hand.

Better than being you, the guy sucking somebody else's adolescent dick.

Re: Why use C++?

[Brian Drummond]

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

Re: Why use C++?

[Georg Bauhaus]

"Jed" <jehdiah@orbitway.net> 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?

Re: Why use C++?

[Georg Bauhaus]

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?

Re: Why use C++?

[Vinzent Hoefler]

Stuart Redmann wrote:

> Stuart Redmann wrote:
> [snip]
>> > Be honest, how often do you really _want_ a wrapping int?
>
> On 12 Aug. Vinzent Hoefler wrote:
>> Thinking indices instead of pointers, quite often, actually.
>
> Could you please provide some example? Seriously, I'm really
> interested in the usage of wrapping types since in the last ten years
> I have not felt the need for wrapping ints at all (well, maybe two or
> three times).

Indexing of a double-buffer would be the most simple example. Switching
between both halves can then be expressed by a simple increment instead of
conditional statements, or explicit masking of the upper bits.

And while extending the data structure to a ring-buffer, masking does only
work for ring-buffers with a size of power-of-two. So, using a modular type
could even provide a slight performance gain in the special case while the
code still works in the general case.


Vinzent.

-- 
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

Re: Why use C++?

[Nick Keighley]

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>

Re: Why use C++?

[Dmitry A. Kazakov]

On Tue, 16 Aug 2011 01:18:31 -0700 (PDT), Nick Keighley wrote:

>> 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.

Never. It is a strong claim, but it holds. The cases of which you believe
you have to handle the type's layout, are those where the *application*
domain is the machine hardware itself. There exist such rare cases, but
they represent no exception to what I said.

> And if we want our
> programs to terminate before the sun goes cold knowing about
> representaion is sometimes useful.

A premature optimization does not guaranty you anything about performance,
in fact the opposite. Unless your claim is that a deliberate use of a wrong
representation (e.g. shorter than required) might result in a better
performance, due to malfunction.

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

Re: Why use C++?

[Nick Keighley]

On Aug 16, 9:47 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 16 Aug 2011 01:18:31 -0700 (PDT), Nick Keighley wrote:

> >> 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.
>
> Never. It is a strong claim, but it holds. The cases of which you believe
> you have to handle the type's layout, are those where the *application*
> domain is the machine hardware itself. There exist such rare cases, but
> they represent no exception to what I said.

this reminds of the maths that states a quadratic equation always has
two roots (solutions). Those cases where there seems to only one root
is actaully two roots both with the same value.

You attempt to win the argument by definition engineering.


> > And if we want our
> > programs to terminate before the sun goes cold knowing about
> > representaion is sometimes useful.
>
> A premature optimization does not guaranty you anything about performance,
> in fact the opposite. Unless your claim is that a deliberate use of a wrong
> representation (e.g. shorter than required) might result in a better
> performance, due to malfunction.

I'm simply arguning that in the real world performance sometimes
matters. This may involve getting down and dirty with the
representaion and other (usually) implementation details.

Re: Why use C++?

[Georg Bauhaus]

On 16.08.11 10:47, Dmitry A. Kazakov wrote:

> A premature optimization does not guaranty you anything about performance,
> in fact the opposite. Unless your claim is that a deliberate use of a wrong
> representation (e.g. shorter than required) might result in a better
> performance, due to malfunction.

Isn't a program closer to optimal in some formal sense when

- the type stays as declared, i.e., without representation affecting
  values ("percent" = {0..100}) and operations (+, -, ...) in  the
  abstract, but

- eventually, one set of machine operations reflects the program's
  purpose better that another (customers preferring the faster/smoother/
  more stable/uninterrupted performance)?

IOW, both programs will perform the same system functions, but
one does more "efficiently" than the other.  And sells better.
Choosing a different type may change the program's meaning.
Is changing only the representation of types, not the types,
necessarily premature optimization?

Compilers, or their writers, try to achieve good representations.
Why shouldn't programmers at least try the same when the program
has matured and can be polished without hurting any of the system
functions?  As long as this attempt doesn't evolve into general hubris?
And most importantly, as long as the type of values does not change,
as it must standard-wise, for example, in C++ when s/int/long/, say?

In this sense, I think any kind of representation specification is
somewhat like a pragma that says optimize space or optimize time.
Anything wrong with pragmatic hints?

Imagine redefining "int" to be something like

__internal.hpp:

class int <lo, hi, predicate=id>
{
    __int<lo, hi> value;
public:
    ...
};

where __int<...> chooses a compile time checked representation.

Re: Why use C++?

[Dmitry A. Kazakov]

On Tue, 16 Aug 2011 02:52:27 -0700 (PDT), Nick Keighley wrote:

> On Aug 16, 9:47�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 16 Aug 2011 01:18:31 -0700 (PDT), Nick Keighley wrote:
> 
>>>> 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.
>>
>> Never. It is a strong claim, but it holds. The cases of which you believe
>> you have to handle the type's layout, are those where the *application*
>> domain is the machine hardware itself. There exist such rare cases, but
>> they represent no exception to what I said.
> 
> this reminds of the maths that states a quadratic equation always has
> two roots (solutions). Those cases where there seems to only one root
> is actaully two roots both with the same value.
> 
> You attempt to win the argument by definition engineering.

Do you have other definitions?

>>> And if we want our
>>> programs to terminate before the sun goes cold knowing about
>>> representaion is sometimes useful.
>>
>> A premature optimization does not guaranty you anything about performance,
>> in fact the opposite. Unless your claim is that a deliberate use of a wrong
>> representation (e.g. shorter than required) might result in a better
>> performance, due to malfunction.
> 
> I'm simply arguning that in the real world performance sometimes
> matters.

And the conclusion is that the required semantics need not be implemented
if that might degrade performance?

Aren't you trying to redefine the word "required"?

> This may involve getting down and dirty with the
> representaion and other (usually) implementation details.

Aren't type specification and implementation (of that specification)
different things?

"Down and dirty" means "does wrong things", or something else?

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

Re: Why use C++?

[Dmitry A. Kazakov]

On Tue, 16 Aug 2011 12:23:48 +0200, Georg Bauhaus wrote:

> Is changing only the representation of types, not the types,
> necessarily premature optimization?

The answer depends on the time the change is made. "Premature" in its
original meaning (Knuth) means: during design, before functional
requirements are met.
 
> Compilers, or their writers, try to achieve good representations.
> Why shouldn't programmers at least try the same when the program
> has matured and can be polished without hurting any of the system
> functions?

Because this requires heavy machinery: static analysis/coverage tests to
prove consistency and profiling of the most frequent use cases in order to
show performance gains, while the actual gain is usually marginal when
integral types are involved. It is beyond the capabilities of an average
programmer to estimate the effect of a representation change for a modern
machine with its caches, pipelines etc.

> In this sense, I think any kind of representation specification is
> somewhat like a pragma that says optimize space or optimize time.
> Anything wrong with pragmatic hints?

Compiler hints (switches) should not appear in the program code.

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

Re: Why use C++?

[Georg Bauhaus]

On 16.08.11 12:58, Dmitry A. Kazakov wrote:

> Compiler hints (switches) should not appear in the program code.

The won't have to appear in program code if there are

file.hpp
file.hrp  // representations_opt
file.cpp
file.crp  // representations_opt

Re: Why use C++?

[Ludovic Brenta]

Jed wrote:
> Ludovic Brenta wrote:
>> Jed writes:
>>>> When have you last thought about the size of the components
>>>> of std::string, of of a vtable?  Why, then, is there a
>>>> pressing need to think about the sizes of int types?
>
>>> You know that that was a very bad comparison. Completely invalid.
>
>> On the contrary I think this comparison is perfectly valid. ]
>
> Who cares what you think?

Don't insult me (or anyone) and make a fool of yourself in front of
everyone, please.  Your time would be better spent reading what I
wrote.

--
Ludovic Brenta.

Re: Why use C++?

[Bill Findlay]

On 16/08/2011 11:58, in article 17sfxzivd6ba0.1lpjrmelcfuoa$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 16 Aug 2011 12:23:48 +0200, Georg Bauhaus wrote:
> 
>> Is changing only the representation of types, not the types,
>> necessarily premature optimization?
> 
> The answer depends on the time the change is made. "Premature" in its
> original meaning (Knuth) means: during design, before functional
> requirements are met.

There are important cases in which the representation of types is an
essential part of the functional requirement. For example, writing a
bit-accurate emulator for an existing computer architecture; or processing
data generated by a legacy non-Ada system.

These cases are not the most common, but they are also not the ignorable
trivia you claim them to be.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Why use C++?

[Dmitry A. Kazakov]

On Tue, 16 Aug 2011 15:51:29 +0100, Bill Findlay wrote:

> On 16/08/2011 11:58, in article 17sfxzivd6ba0.1lpjrmelcfuoa$.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Tue, 16 Aug 2011 12:23:48 +0200, Georg Bauhaus wrote:
>> 
>>> Is changing only the representation of types, not the types,
>>> necessarily premature optimization?
>> 
>> The answer depends on the time the change is made. "Premature" in its
>> original meaning (Knuth) means: during design, before functional
>> requirements are met.
> 
> There are important cases in which the representation of types is an
> essential part of the functional requirement.

I addressed this in my earlier post.

> For example, writing a
> bit-accurate emulator for an existing computer architecture;

Actually not. You can represent an array of bits in any desired way. The
order of bits and their actual layout in the memory (if observable), are
unrelated:

   type Word is array (1..16) of Boolean;
   type Word is mod 2**16;
   type Word is range 0..2**16-1;
   type Word is new Wide_Character;

You are free to choose any of them and yet remain "bit-accurate". Bit
accuracy is defined by the implementation of Get_Bit, Get_Byte etc
operations.

> or processing data generated by a legacy non-Ada system.

You need only one type for an octet or other atomic type used as the I/O
unit. Note that this type is predefined by the I/O library, so normally
there is no need not to define it. You cannot use anything more complex
than that because there is no any guaranty on I/O semantics of composite
type.

> These cases are not the most common, but they are also not the ignorable
> trivia you claim them to be.

They are. The second case is communication to alien hardware/software
protocols, it is my daily job. You don't need any representation clauses
there.

It is amazing how many people think otherwise. It seems that conflation of
the encoding issues with type representations is very deep rooted.

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

Re: Why use C++?

[Bill Findlay]

On 16/08/2011 20:13, in article 1qwybpbhjv11s.6orqbnwyy15z.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 16 Aug 2011 15:51:29 +0100, Bill Findlay wrote:
> 
> 
>> These cases are not the most common, but they are also not the ignorable
>> trivia you claim them to be.
> 
> They are. The second case is communication to alien hardware/software
> protocols, it is my daily job. You don't need any representation clauses
> there.
> 
> It is amazing how many people think otherwise. It seems that conflation of
> the encoding issues with type representations is very deep rooted.

We seem to have a different conceptualization of "need".

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Why use C++?

[Louisa]

On Aug 11, 5:54 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 10 Aug 2011 17:37:28 -0500, Randy Brukardt wrote:
> > There are uses for wrapping types, but they are far less likely than wanting
> > overflow detection. The default should be to catch errors, not turn them
> > into different ones.
>
> The OP mentioned image processing, the behavior frequently needed there is
> saturated integer arithmetic, which is nether ranged nor modular.
>
> As for modular types, wrapping is the mathematically correct behavior, it
> is not an error.
>
> You just cannot provide every possible arithmetic at the language level.

Signed and unsigned arithmetic are provided in PL/I.
Thus, 0:2**32-1 is available for unsigned binary arithmetic.
So is 0:2**64-1.