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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#8892

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

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

#8897

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.

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

#8902

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

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

#8901

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.

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

#8904

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

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

#8909

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

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

#8924

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;

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

#8936

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

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

#8937

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;

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

#8689

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

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

#8693

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

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

#8734

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

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

#8696

"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

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

#8698

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
$

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

#8703

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

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

#8704

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

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

#8713

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.

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

#8731

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.

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

#8735

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;

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

#8858

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.

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

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

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

csiph-web