Re: Why use C++?

["Jed" <jehdiah@orbitway.net>]

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