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

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

Why use C++?

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

Contents

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

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

#8516 — Why use C++?

I've made the title too provocative. What I mean is, why use C++ for
small ( > 1000 lines ) coding jobs?
It doesn't make much sense to me as...

C++ syntax requires a lot more typing, debugging and memory,
Compilation time can be irksome,
C++ is devoid of the plethora of features you find on Python, Ruby or
our dear Swiss Army Chainsaw.

Don't get me wrong, I don't dislike C++, nor am I trying to rile up
the great gurus among us, however, I fail to see a practical reason to
use this language much as I go about my hacking life.
I understand that it compiles directly into binary and can be from
there run without an interpreter, but that seems a small price to pay
for a five line ( in good practice ) hello world.

Miro

[toc] | [next] | [standalone]

#8518

"Miro" <nickbergeronsemail@gmail.com> wrote in message 
news:fb9f787c-af06-427a-82b6-b0684e8dcbc5@s2g2000vby.googlegroups.com...
> I've made the title too provocative. What I mean is, why use C++ for
> small ( > 1000 lines ) coding jobs?
> It doesn't make much sense to me as...
>
> C++ syntax requires a lot more typing, debugging and memory,
> Compilation time can be irksome,

Compared to what?


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

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

#8609

"Miro" wrote:
[snip]
> > C++ syntax requires a lot more typing, debugging and memory,
> > Compilation time can be irksome,

On 6 Aug., Paul wrote:
> Compared to what?


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.

Steps (A) and (C) are already provided by Visual Basic, so I prefer VB
for smaller projects.

Regards,
Stuart

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

#8611

"Stuart Redmann" <DerTopper@web.de> wrote in message 
news:1e292299-2cbe-4443-86f3-b19b8af50fff@c29g2000yqd.googlegroups.com...
> "Miro" wrote:
> [snip]
>> > C++ syntax requires a lot more typing, debugging and memory,
>> > Compilation time can be irksome,
>
> On 6 Aug., Paul wrote:
>> Compared to what?
>
>
> 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.
>
> Steps (A) and (C) are already provided by Visual Basic, so I prefer VB
> for smaller projects.
>

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. 


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

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

#8627

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

Regards,
Stuart

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

#8635

"Stuart Redmann" <DerTopper@web.de> wrote in message 
news:1fd0cc9b-859d-428e-b68a-11e34de84225@gz10g2000vbb.googlegroups.com...
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 ;-)

Yeah I was meaning to create the actual COM component, not an instance of 
one, just incase I didn't make that clear :)

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

Have you tried Managed C++?
I tried C# which was ok, for dotnet stuff but didn't really try ManagedC++. 
I can't get into VB at all, I started to learn VB(version 5 or something) 
way back pre-dotnet but lost interest and couldn't really get back into it.

I prefer the syntax for C++ because its similar to javascript and Java and 
don't find it too much of an effort to jump across languages and get right 
back into it. VB on the other hand is just a different kettle-of-fish 
altogether :)



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

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

#8643

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

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

#8652

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

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

#8653

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

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

#8688

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

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

#8658

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

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

#8664

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

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

#8668

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

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

#8671

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

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

#8700

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

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

#8714

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

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

#8756

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

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

#8737

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.

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

#8754

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. 

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

#8921

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.

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

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

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

csiph-web