Topic: Multiprecision numerics
Author: AllanW@my-dejanews.com
Date: 1998/09/24 Raw View
In article <haberg-1909981145400001@sl08.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In article <3601A611.2351A6B0@ix.netcom.com>, "Paul D. DeRocco"
> <pderocco@ix.netcom.com> wrote:
> >But computer languages aren't anything like the rest of real life.
>
> Sure, the social principles affecting the developments of computer
> languages are exactly the same as of all the rest of society. How could it
> be different?
Are you serious? Is everything in your personal life as ordered and
predictable as a computer?
Natural languages: Imprecise by nature, large vocabulary is desirable
Computer languages: Rigid by requirement (we can't have different
"standard" compilers assign different semantics to the same
syntax!), small vocabulary is desirable (we already have some
minor issues because class and struct mean almost the same thing --
now imagine that someone uses "map" and expects to be able to
"teach" the compiler that this is a synonym!)
Imagine a computer language trying to express human wants, desires,
and emotions.
if (a != b && (a loves b)) { a = b; } // What would this MEAN?
// poetic, rather than functional -- optimize away?
rose.color = red;
violet.color = blue;
sugar.taste = sweet;
this.love = &you;
> > The
> >purpose of a language standard is to establish a _single_ definition of
> >a language to which everyone who uses the language must conform, in
> >order to guarantee portability and interchangeability.
>
> This is clearly so. Has anybody said something else?
Some have argued that this _single_ definition should meet arbitrary
guidelines. In particular, some want the definition to be able to express
every possible language construct. But this would virtually guarantee
that few or no language vendors ever bring a product to market.
It's the same problem as with any business system. As you develop the
system, streamlining one aspect of day-to-day operations, you soon
discover other problems that could equally well be solved by adding
"just one more feature" to the system. This is called "feature creep"
because even though each individual step is quite small, the cumulative
effect is very large. Soon, there are so many requirements that the
system is never complete!
In business systems, and in compiler languages, it is neccesary to define
a "scope" -- i.e. what problems will we solve, or at least, what problems
will we solve for now.
> > When there's a
> >disagreement about what should be in the language, the minority, even if
> >"influential," must simply lose, period.
>
> Why? If I apply this to another context, suppose one develops a standard
> for shoes, and you find that your shoes-size is not a part of that
> standard and it would be easy to add it to the standard. What you are
> saying is as if the others would be saying to you that you could equally
> well walk bare-foot if you do not like their standard.
>
> Would you agree to that?
I'm not sure I buy this analogy, but let's take it a step further.
Let's say that the world has exactly 1,000,000 towns, each with at
least one shoemaker. Furthermore, let's assume we have empirical
data that proves beyond a reasonable doubt (but not beyond a shadow
of a doubt) that 999,984 towns would serve 100% of their customers
by stocking shoe sizes 5 through 24. We recognize that this is less
than 100% -- in 16 towns throughout the world, there are a total of
52 people who either wear a shoe size smaller than size 5, or else
they wear a shoe size larger than 24. Nobody suggests that these
52 people are any less important or valuable than the other billions
of people on the planet.
Now, assume that the ISO/ANSI Shoemaker standard is about to be
released. But first a man shows up wearing a size 39. "I'm not the
only one in the world that wears size 39 or more," he correctly says.
"We should require shoe makers to build and stock all shoe sizes from
size 0.5 to size 59.5. To do otherwise would be to leave out an
important segment of society."
The ISO/ANSI Shoemaker Standards Committee now has a choice.
We can specify that standard shoemakers must make shoes from size 0.5
up to size 59.5. However, clearly most of the shoemakers around the
world do not need this size of shoe. These shoemakers can comply by
creating extra shoe-making machines, even though they will never run
them until they get an odd-size order -- and most of them will never
get that odd-size order. But each new size of shoe machine costs an
extra $10,000 per shoe style -- and with about 89 "odd" sizes in the
range 0.5 to 59.5, this would cost close to $1,000,000 per shoe
style. Even though the machine will NEVER be used in most towns,
because the "odd-size shoe machine" order will NEVER be used.
The other option for these shoemakers is to refuse to make these extra
non-saleable shoe machines, of course. But then they couldn't label
their shoes as ISO/ANSI compatible. This is important to the shoemakers
because government contractors will only buy ISO/ANSI compatible shoes
because of their large supply of accessories (shoe horns, shoe racks,
shoe laces, etc.). We can assume that one item on the standards committee
charter was the need for backwards compatibility with existing shoes and
shoe accessories.
The other option for the ISO/ANSI Shoe Standards Committee is to leave
these extraneous out of the spec. Then, shoemakers will be able to bill
themselves as ISO/ANSI complaint, even though they don't have any
odd-size shoemaking machines.
You might argue that the 16 towns might not make the strange-sized
shoes either, and that this would leave the fine, upstanding (no pun
intended) strange-foot-size citizens out in the rain. But remember
that what a shoemaker is *required* to do doesn't generally block
what that shoemaker is *allowed* to do. In those 16 towns, there will
be a demand for odd-size shoes, and so there will be shoemakers who
make them. (Otherwise the customers will drive to another shoemaker
and/or another town to buy high-quality shoes that fit.)
> The right way to go is, of course, to provide suitable generalizations,
> so that the suitable structures can be added, supporting both the majority
> and the minority.
This is one of the things C++ provides with the "class" keyword. It allows
second- and third-party software to create new functionality that was
never conceived of by the inventors of the language, by the committee
members, or even by the compiler vendor.
In other words, if you can't find what you need, write it!
> The methodology of developing the current C++ standard excludes the
> possibility of adding such insights.
It's excluded until it's considered generally useful. We may express
our deep regrets to the 52 odd-size-foot citizens from around the
country, and respectfully ask them to contact their local shoe
salesman for local shoe extensions.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <3606630C.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>I was not aware that the usability was in question. I presumed that you
>intended something that was unambiguously usable, such as adding a
>'multiprecision' type to the language, and hiding all the details about
>how it was implemented from the user.
I do not know the usability myself without first investigating it.
>I don't think it's feasible to implement a multiprecision type with the
>performance requirements you suggested, but if you remove those
>requirements, I have no other feasibility concerns.
I tried to indicate the context of in which the performance would be
required, in which case one simply tries to do the best. Somehow, you
reinterpreted it.
The actual performace requirement is more complicated in the case of a
dynamic language, because one may use a type "Int" than a type "int" with
additional overhead. So it is not possible to very easily define a
performance criterion in terms of a make/break factor.
>What I am concerned about is the advisability of making it a mandatory
>feature.
For C++, I see that the prudent things for this type of applications is
to work through this and other types of applications and see what is
needed to be added on the low level. (Like the overflow suggestions you
posted in a parallel thread.)
Clearly, any using C++ for implementing high level features will be
satisfied with that the low level features needed are conveniently
available.
Then to the other question, should such higher level features be added
say as libraries: If the C++ low level support is such that a library
feature does not require anything but adding a standard header and source
without conflicting with other features, then there is no limit to what
one can add or how much one can add to a standard library (just put them
in specialized name-spaces). The additional work for those writing the
compilers will be pretty much zero, as they just need to flip in that
source/header/docs in the next version, and nothing else: All that is
needed is somebody writing the source material once.
But I am not myself interested in the prospects of this latter
development, but I foresee that it is possible.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <6u6gag$12t$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM wrote:
>> I was volunteering a great deal of work. Writing these posts
>>take a lot of time,
>
>I could spend all day making lots of mud pies and not impress anyone.
>Productive work is what counts.
I try to point out that what is mud pies to some are treasures to
others, and vice versa. If you want an example, take the art of van Gogh,
which was considered mud pies in the days of his living, but now is
considered a treasure.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <MPG.10702f9b2d3fba83989d83@news.rmi.net>, jcoffin@taeus.com
(Jerry Coffin) wrote:
>C has _exactly_ the same strengths and weaknesses as C++ when it comes
>to implementing conservative GC. In fact, every conservative GC I
>know of for C works essentially identically with C++.
I think you might think of the kind of conservative GC makes a version
of "malloc" by going in on a level between the OS and the compiler, which
is not what I speak of. (See the thread "Dynamic cast of virtual function
pointers".)
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/09/22 Raw View
Hans Aberg wrote:
[...]
> > When there's a
> >disagreement about what should be in the language, the minority, even if
> >"influential," must simply lose, period.
>
> Why? If I apply this to another context, suppose one develops a standard
> for shoes, and you find that your shoes-size is not a part of that
> standard and it would be easy to add it to the standard. What you are
> saying is as if the others would be saying to you that you could equally
> well walk bare-foot if you do not like their standard.
No, it's like saying: "If you want such shoes, then produce them or
find someone who produces them. But don't force *every* shoe-producer
to produce those shoes by mandating them in the standard".
Of course, you'd like it better if your shoe size was mandated for
every shoe-producer, so you would not have to rely on one or a few
particular shoe-producers which fit your need. However, if the market
for those shoes is too small, why force every shoe-producer to produce
them? Why not instead find *one* shoe-producer who is willing to
produce them? If those are successfull enough, other shoe-producers will
start to make them as well, and eventually they will get standard
one day...
BTW, what do you think would have happened, if Stroustrup
insisted on adding classes to the C standard, instead of creating
his own C with Classes (which evolved into C++)?
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <eRFCYOAUEiB2EwKl@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>The existence of a standard does not require
>you to abide by it. It simply requires you not to describe your product
>as conforming if it isn't.
This is only true if one disregards social pressures.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <36069F45.794B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> Until such time as you actually convince somebody else that
>it should be done, it won't get done unless you're willing to do it.
This can only happen if the charter is changed.
>It can't be done at a higher level; ISO is only answerable to its
>members.
There is always a higher level: Every organization is dependent on the
society in which it belongs to.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/22 Raw View
In article <3607A7C9.68672A57@physik.tu-muenchen.de>, Christopher Eltschka
<celtschk@physik.tu-muenchen.de> wrote:
>No, it's like saying: "If you want such shoes, then produce them or
>find someone who produces them. But don't force *every* shoe-producer
>to produce those shoes by mandating them in the standard".
I am not sure we are getting anywhere here, because I try to point out
the social principles guiding the matter, but the reposts line up in a
defense of the development of the C++ standard: That polemics does not
change the facts guiding the social environment in which the C++ standard
will exist.
So the social pressure causes those effects, and if the explanations I
have repeated over and over does not suffice, consult somebody with the
capacity of providing better explanations about such matters: Your local
politician, somebody in political or social science, or somebody used to
deal with such matters.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/09/22 Raw View
Hans Aberg wrote:
>
> In article <6tu2c3$q7o$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
> Clamage) wrote:
> >Still complaining, still not volunteering to do any actual work.
>
> I thought by pointing out the features that I think needs to be changed,
> which you label as "complaining" (perhaps you can only work with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> yes-men?)
^^^^^^^^ oh oh oh. be carefull.
> I was volunteering a great deal of work.
That wasn't explicit.
> Writing these posts
> take a lot of time, and if I had thought bringing out this information was
> a whooly futile work, I would have stopped a long time ago.
Writing posts doesn't generally count as work (except if there
is a very detailled and complete analysis in it). Writing formal
proposals and spending time in std commitees does.
Pointing out problems can be usefull, but doesn't generally
count as working.
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/22 Raw View
Hans Aberg wrote:
...
> I tried to indicate the context of in which the performance would be
> required, in which case one simply tries to do the best. Somehow, you
> reinterpreted it.
You refer to a "context in which the performance would be required", yet
you say of the same context that "one simply tries to do the best". Is
the performance required, or isn't it? I suspect that there are some
words missing from your sentence that would indicate that the "do the
best" clause refers to a different context than the "required" clause.
Only in the second context, whatever it is, are multiprecision integers
feasible. Your performance requirement is not achievable, as far as I
can tell, in any real-world context. Your assertions to the contrary
haven't been meaningful, because you haven't backed them up with any
details showing how it could be done.
> The actual performace requirement is more complicated in the case of a
> dynamic language, because one may use a type "Int" than a type "int" with
> additional overhead. So it is not possible to very easily define a
> performance criterion in terms of a make/break factor.
...
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/23 Raw View
Hans Aberg wrote:
>
> In article <36069F45.794B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> > Until such time as you actually convince somebody else that
> >it should be done, it won't get done unless you're willing to do it.
>
> This can only happen if the charter is changed.
I'm referring to getting the charter changed. If you're not willing to
start working on changing the charter until after the charter has been
changed, you're stuck!
> >It can't be done at a higher level; ISO is only answerable to its
> >members.
>
> There is always a higher level: Every organization is dependent on the
> society in which it belongs to.
True; you could convince nations or even the UN to pass laws or
negotiate treaties to restrict what ISO can do. You could organize a
boycott of ISO by C++ users in an effort to coerce it to obey your will.
However, the direct control of ISO is by its members, and that is the
most appropriate level to act at in order to change its charter.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/23 Raw View
In article <haberg-2209981237480001@sl118.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
>
> This is only true if one disregards social pressures.
Rubbish. There are several excellent non-conforming C compilers because
their target users have no use for a conforming one.
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ncm@nospam.cantrip.org (Nathan Myers)
Date: 1998/09/23 Raw View
The text Hans quotes below is from private mail sent only
to Hans, and not intended for posting to the net. I do not
intend to participate in this discussion any further.
Goodbye, Hans.
Hans Aberg<haberg@REMOVE.matematik.su.se> wrote:
>At 13:35 -0700 98/09/21, Nathan Myers wrote:
>>> So this is one of the reasons that C++ seems to be unable to become a
>>>complete language: Lack of open-mindedness of the participants in such a
>>>group obstructs crucial developments.
>>>
>>> I guess that this is the reason that nearly all important creative
>>>developments of history are one man projects.
>>
>>As we say in English, you are out on a limb and sawing briskly.
>
> It seems you have a funny notion of English.
>
>>You are criticizing the wrong thing, and the wrong people.
>>Be more careful.
>
> Do you think this veiled threat is a sign of open-mindedness?
>
>>The C++ committee members have been unusually open-minded, just
>>as engineers, but especially for a standard committee.
>
> So you claim open-mindedness while on the same time bashing those that
>do not merely say yes to your opinions -- sounds as a contradiction to me.
>
>> Many people
>>have complained for years that they have been too open-minded, and
>>delayed the standard by years as a result.
>
> I feel pretty sure they did not complain over that the committee was too
>open-minded, but over the delays. :-)
--
Nathan Myers
ncm@nospam.cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/23 Raw View
Hans Aberg wrote:
>
> In article <eRFCYOAUEiB2EwKl@robinton.demon.co.uk>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
>
> >The existence of a standard does not require
> >you to abide by it. It simply requires you not to describe your product
> >as conforming if it isn't.
>
> This is only true if one disregards social pressures.
There has been a great deal of social pressure exerted to convince you
to stop bothering this newsgroup; you've resisted that pressure quite
easily. Why should it be any more difficult to ignore the social
pressure to produce a conforming implementation of C++?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/23 Raw View
Many thanks for the tremendous interest in this thread. I am sorry I
cannot stand by any longer in these discussions. :-)
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/18 Raw View
In article <6trf1e$n58$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
(Steve Clamage) wrote:
>The principles behind the standard comprise the charter of the
>C++ committee. We are not free to violate the charter, and are
>constrained to follow it by the organizations (ANSI and ISO) who
>granted the charter.
From the description in your first post of this thread, I realized that
the charter needs to be changed.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/09/18 Raw View
Hans Aberg wrote:
>
> A standard cannot be allowed to exclude influential key groups in the
> name of mass-consumption. This is a important principle of a
> modern democratic society, and I think if it is not true with the
> standards today, it will be a forced principle for the standards
> written tomorrow.
But computer languages aren't anything like the rest of real life. The
purpose of a language standard is to establish a _single_ definition of
a language to which everyone who uses the language must conform, in
order to guarantee portability and interchangeability. When there's a
disagreement about what should be in the language, the minority, even if
"influential," must simply lose, period. And currently, it is only a
minority that uses GC in C++, or believes that GC can be implemented in
some single manner that will satisfy all potential users of GC. That's
why it didn't make it into the standard.
--
Ciao,
Paul
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/09/18 Raw View
In article <haberg-1709981246040001@sl42.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> I think what is going on is that you have invested a lot of time and
> effort, and cannot stand that somebody hints that the standard and the
> principles it builds on are not perfect.
I think what is going on is that you have invested a little time and
effort, and presume you know more than you do, when in fact you haven't
learned a very important principle:
THERE IS NO SUCH THING AS PERFECT.
> What does OTOH mean?
On The Other Hand. Which is American slang for "there is another
point to be considered."
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "James Russell Kuyper Jr." <kuyper@wizard.net>
Date: 1998/09/18 Raw View
Hans Aberg wrote:
>
> In article <6trf1e$n58$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
> (Steve Clamage) wrote:
> >The principles behind the standard comprise the charter of the
> >C++ committee. We are not free to violate the charter, and are
> >constrained to follow it by the organizations (ANSI and ISO) who
> >granted the charter.
>
> From the description in your first post of this thread, I realized that
> the charter needs to be changed.
Are you willing to make the effort that would be needed to change it? I
don't know what the procedure is, but I'm sure one exists, and if you
ask them to, I'm sure the committee members watching this newsgroup
would be willing to point you to documentation of the proper procedure.
However, I can already guess that you will probably need to do some or
all of the following:
1. Join an appropriate organization.
2. Find out the full details of the current charter.
3. Work out a detailed proposal for changing it, and submit it.
4. Convince a sufficiently large number of people that your proposal
should be approved. The group you will have to convince will have many
similarities to this newsgroup. If you wish to convince them, I'd
recommend a little more tact than you've shown here.
Are you willing to take on this effort? If not, one alternative is to
convince someone else to make that effort. If that person is to actually
be willing to do the work you don't want to do, they'll have to be more
strongly motivated on this issue than you are. Can you think of anyone
who would qualify?
If not, could you please stop bothering us about it?
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/21 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
> So a standard must not only ensure that there is a wide group of users,
>but also that its presence does not conflict with the needs of
>individuals.
That is an impossible requirement, because the needs of individuals
conflict.
No matter how a standard turns out, there will always be some
who don't like it.
Any standard must attempt to steer a course that provides maximum
benefit and minimum inconvenience for its intended community of users.
In the end nobody gets exactly what he wants, but a successful
standard will leave the great majority of potential users
satisified.
In the case of the C++ standard, the 50 or people who regularly
attended committee meetings agreed unamimously that the final
standard met that test. The technical experts of about two dozen
countries around the world who reviewed it also agreed unanimously.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <6tk542$1d9$1@nnrp1.dejanews.com>, abrahams@motu.com wrote:
>Actually, C++ has remarkably good support for writing garbage collection, as
>high-level languages go.
I know that those that have tried writing a conservative GC in C++ have
the opposite opinion. Please let me know, how do you find the root set in
C++?
Also, I thought that C++ was to be considered a low-level programming
language; this is its strength, because one can then write efficient code.
If C++ at some point would attempt to be a high level language, I think it
would loose this its strength and start becoming uninteresting.
> I'd be curious to know what language Mr. Aberg finds
>superior in this regard.
I guess it is C, in view that C++ does not have any such support. There
is also the C-- portable assembler language that Simon Peyton Jones is
writing.
One then has to implement from scratch by hand everything that C++ has
the potential of automate for the programmer. Extremely time-consuming,
but I think that this is what people do.
>I can tell from his posts that Mr. Aberg has never participated in a serious
>standardization effort involving a large group. One of the first things one
>learns is that insulting the efforts of conscientious and hard-working
>participants is a sure path *away* from progress.
So this is one of the reasons that C++ seems to be unable to become a
complete language: Lack of open-mindedness of the participants in such a
group obstructs crucial developments.
I guess that this is the reason that nearly all important creative
developments of history are one man projects.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/21 Raw View
In article <haberg-1709981246040001@sl42.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> I think what is going on is that you have invested a lot of time and
>effort, and cannot stand that somebody hints that the standard and the
>principles it builds on are not perfect.
Oddly, I have been in print numerous times saying that the standard is
not perfect. Whether you like it or not, the principles are laid down
by International agreement managed by ISO.
If you want to change C++ participate in your NB's process. If you want
to change the way standards are produced you will have to move up about
three levels to those that specify the rules for standardisation. Do
not confuse the two.
I have always followed the rule 'Do not complain unless you are willing
to do something about it.' Whenever I hear the classic phrase 'Someone
ought to ...' my standard reply is 'Unless you are no one...'
>
> What does OTOH mean?
On the other hand.
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/21 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>In article <6trf1e$n58$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
>(Steve Clamage) wrote:
>>The principles behind the standard comprise the charter of the
>>C++ committee. We are not free to violate the charter, and are
>>constrained to follow it by the organizations (ANSI and ISO) who
>>granted the charter.
> From the description in your first post of this thread, I realized that
>the charter needs to be changed.
Still complaining, still not volunteering to do any actual work.
If you want to get the charter changed, here are some web
sites to help you get started.
http://www.iso.ch/ -- ISO charters SC22/WG21
http://www.ansi.org/ -- ANSI publishes American standards
http://www.ncits.org/ -- NCITS charters J16
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/09/21 Raw View
In article <haberg-1609981304070001@sl27.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
>
> In article <6tmceg$hqd$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
> (Steve Clamage) wrote:
> >That's exactly right! It is not possible to support every language
> >feature and every style of programming in a single language.
> >For C++ there has been over the last 8 years a public decision-
> >making process to determine which candidate features are
> >"broadly used" and which are "too special". Any interested
> >person anywhere in the world is allowed to participate in the
> >process. The process itself has been announced as publicly
> >as possible.
>
> So what I am saying is that this requirement must be dropped if C++
> should become a complete language. The replacement should the addition
> features if they are general in their (logical) nature, and help solving
> central computational problems. In this version, a high number of
> immediate C++ prgrammers using the feature might be consideable, but it
> should be balamnced against the principles normally used for developing
> (scientific) quality.
Then, by your measure, there is no such thing as a "complete
language." So why pick on C++? Go find some other language and
complain that their language isn't complete, either.
Or, perhaps you can create a truely complete language, one that
shows us all how it OUGHT to be done. You could even start with
C++ to build your "Complete" language, just as the people who
made C++ started with C. But then you could fix all the "mistakes"
you keep going on about, and add support for 5,000 specialized
libraries that some "novice programmer" might need someday,
eventually. Here are just a few of the topics that a theoretical
"complete language" should have, but (sadly) most languages today
are simply deficient in them:
* Linear and discrete algebra, including calculus. Why solve
formulas when you're sitting in front of a computer?
* Linear, Surface, and Volume classes, which automatically
convert to every unit type known to mankind
* Navigation and Mapmaking tools. How many millimeters between
Alaska and Sweden by air? How about by boat and bus?
* Time, capable of counting from Big Bang to Ultimate Entropy
with at least nanosecond precision.
* Astronomy. Darn it, the language has no built-in feature
for tracking detectable changes to Andromeda!
* Astrology. Shouldn't the computer know that November 17 is
Scorpio, and Scorpio < Saggetarius?
* Biology, geneolagy, DNA. How can a language be complete
without fundamental tools for this discipline?
* Boolean logic. && and || aren't everything -- what about
universal/existential math, probability, formal proofs?
* Transportation. Despite being the standard example for OO
studies, no language has yet implemented a truely complete
class heirarchy of existing and future vehicle types,
makes, models, attributes. How can we decide what travel
method to use from Alaska to Sweden?
* Chemistry and Medicine. My computer can't even tell me the
atomic weight of platinum! What good is that?!?
* Literature. There should be a way to compare the literary
styles of Shakespeare and Sir Arthur Conan Doyle. Instead,
we can't even use the computer to look up the author of
famous quotations!
* Artificial intelligence. Voice recognition is coming of age,
and yet most computer languages don't have any features
to assist the poor programmer with this daunting task.
Natural language analysis is far too complex for existing
languages, so we should scrap them all. My "paint" program
should be able to drag the lamp, in my photograph, to the
other side of the room -- without leaving a "hole" in the
photo!
* Diplomacy. Shouldn't the computer be able to tell you how to
make suggestions for change, without getting the people
already working on a project angry?
* Thousands more.
If you can make a general-purpose language that includes all of
these topics and others like them, and it really is easy to use and
efficient to run, then I guarantee that you will become wealthy
beyond your dreams, and powerful enough to dictate changes that
everyone will love.
If you CANNOT make a language like this, don't dispair -- neither
can anyone else, at least not today. So standards committees must
look for something more modest. Specifically, they look for language
features powerful enough to let you CREATE most of these other
facilities, without having them built in to the language itself.
Or, as Steve Clamage said:
> >Features that are deemed not general enough to go into the standard
> >can be and often are provided by interested parties as add-on
> >libraries.
>
> Note that there is a difference between a feature being general in
> nature and that a feature has many immediate users: These two concepts are
> in fact independent of each other.
The practical difference between them is unimportant. The easiest
way to recognize that a feature is general in nature is by examining
it's need in the programming community. A feature needed by one
programmer on one special project is considered frivilous. A
feature that is needed by a large percentage of programmers is
usually considered general-purpose enough to gain wide support.
Note that wide support is not the same as Hans Aberg support. An idea
can easily have one of these without the other.
[lots of snippage]
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <3601A611.2351A6B0@ix.netcom.com>, "Paul D. DeRocco"
<pderocco@ix.netcom.com> wrote:
>But computer languages aren't anything like the rest of real life.
Sure, the social principles affecting the developments of computer
languages are exactly the same as of all the rest of society. How could it
be different?
> The
>purpose of a language standard is to establish a _single_ definition of
>a language to which everyone who uses the language must conform, in
>order to guarantee portability and interchangeability.
This is clearly so. Has anybody said something else?
> When there's a
>disagreement about what should be in the language, the minority, even if
>"influential," must simply lose, period.
Why? If I apply this to another context, suppose one develops a standard
for shoes, and you find that your shoes-size is not a part of that
standard and it would be easy to add it to the standard. What you are
saying is as if the others would be saying to you that you could equally
well walk bare-foot if you do not like their standard.
Would you agree to that?
The right way to go is, of course, to provide suitable generalizations,
so that the suitable structures can be added, supporting both the majority
and the minority.
The methodology of developing the current C++ standard excludes the
possibility of adding such insights.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <6tjjsj$9fl$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
>Let's rephrase. Since your original suggestion was for your own private
>use and has not been verified, then it too must be irrelevant for the
>discussions here.
My suggestion was that the usability of the feature should be verified
and that one should not blindly stare at the large number of immediate
users.
James Kuyper said that in view of the argument he gave, that was not
necessary.
Of course, the current C++ standard requires a large number of immediate
users, so I argue that requirement should be dropped in favour of more
general principles.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <6tu2c3$q7o$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
Clamage) wrote:
>Still complaining, still not volunteering to do any actual work.
I thought by pointing out the features that I think needs to be changed,
which you label as "complaining" (perhaps you can only work with
yes-men?), I was volunteering a great deal of work. Writing these posts
take a lot of time, and if I had thought bringing out this information was
a whooly futile work, I would have stopped a long time ago.
>If you want to get the charter changed, here are some web
>sites to help you get started.
>
> http://www.iso.ch/ -- ISO charters SC22/WG21
> http://www.ansi.org/ -- ANSI publishes American standards
> http://www.ncits.org/ -- NCITS charters J16
Than you for the URL's. But for the change of the ISO charter, it is
needed somebody understanding politics. I am not sure it can be done
within those organizations, it is on a too low level.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/21 Raw View
In article <haberg-1909981145400001@sl08.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> Why? If I apply this to another context, suppose one develops a standard
>for shoes, and you find that your shoes-size is not a part of that
>standard and it would be easy to add it to the standard. What you are
>saying is as if the others would be saying to you that you could equally
>well walk bare-foot if you do not like their standard.
Now you are being silly. The existence of a standard does not require
you to abide by it. It simply requires you not to describe your product
as conforming if it isn't. It isn't (yet) illegal to add features to
your implementation, indeed all you need to do is to issue a diagnostic
the first time code being compiled uses any of your extended features.
This will do
'Congratulations on using the outstanding extensions we have provided'
In fact just about every compiler (not just C++) I have ever used
provides extensions (that the good ones allow me to switch off)
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <6tpnej$298$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
Clamage) wrote:
>haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>
>> So a standard must not only ensure that there is a wide group of users,
>>but also that its presence does not conflict with the needs of
>>individuals.
>
>That is an impossible requirement, because the needs of individuals
>conflict.
The process of resolving such conflicts is called "negotiation".
>No matter how a standard turns out, there will always be some
>who don't like it.
Only if the requirement is that all the conflicts should be completetly
resolved.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <mGE8NKAW9VA2EwUO@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>If you want to change C++ participate in your NB's process.
What is NB short for.
> If you want
>to change the way standards are produced you will have to move up about
>three levels to those that specify the rules for standardisation.
Or enter the information on a level above that.
>I have always followed the rule 'Do not complain unless you are willing
>to do something about it.' Whenever I hear the classic phrase 'Someone
>ought to ...' my standard reply is 'Unless you are no one...'
I guess that the one that complains thinks that it is a way to do
something about it. :-)
I can also note a difference in culture, Europeans often proudly point
out that they never complain bout things, whereas in the US one may
proudly state that one is a "complainer".
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
In article <6tuatn$ce7$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
>Then, by your measure, there is no such thing as a "complete
>language." So why pick on C++? Go find some other language and
>complain that their language isn't complete, either.
To me it suffices that C++ is reasonably complete within the scope of
being a low level programming language used to implement other high level
features.
So for example, with respect to a GC, it suffices that C++ supports
extracting the root set and such, so one can write ones own GC or perhaps
use a GC library (and the latter need not be a part of the C++ standard).
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/09/21 Raw View
In article <haberg-1709981245540001@sl42.modempool.kth.se>,
haberg@REMOVE.matematik.su.se says...
> In article <6tk542$1d9$1@nnrp1.dejanews.com>, abrahams@motu.com wrote:
> >Actually, C++ has remarkably good support for writing garbage collection, as
> >high-level languages go.
>
> I know that those that have tried writing a conservative GC in C++ have
> the opposite opinion. Please let me know, how do you find the root set in
> C++?
[ ... ]
[ Note that the following was not originally _specifically_ addressing
the issue of conservative GC, but of being sufficiently generalized
for wide use, or something on that order -- if my summary isn't
sufficient, read the rest of the thread... ]
> > I'd be curious to know what language Mr. Aberg finds
> >superior in this regard.
>
> I guess it is C, in view that C++ does not have any such support. There
> is also the C-- portable assembler language that Simon Peyton Jones is
> writing.
C has _exactly_ the same strengths and weaknesses as C++ when it comes
to implementing conservative GC. In fact, every conservative GC I
know of for C works essentially identically with C++.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: abrahams@motu.com
Date: 1998/09/21 Raw View
In article <haberg-1709981245540001@sl42.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In article <6tk542$1d9$1@nnrp1.dejanews.com>, abrahams@motu.com wrote:
> >Actually, C++ has remarkably good support for writing garbage collection, as
> >high-level languages go.
>
> I know that those that have tried writing a conservative GC in C++ have
> the opposite opinion. Please let me know, how do you find the root set in
> C++?
Exactly the same way you do it in C.
<Semantic discussion of high- vs low- level language distinciton elided>
> > I'd be curious to know what language Mr. Aberg finds
> >superior in this regard.
>
> I guess it is C, in view that C++ does not have any such support. There
> is also the C-- portable assembler language that Simon Peyton Jones is
> writing.
Every C program is a conforming C++ program with identical semantics, or can
be made so trivially. C++ also supports the asm keyword, which gives access
to the target's assembly language. Perhaps C-- has something extra to offer
for implementing GC, but straight C certainly does not. It's hard to imagine
that any language targeting a wide variety of machines can offer a *portable*
way to find the root set.
> One then has to implement from scratch by hand everything that C++ has
> the potential of automate for the programmer. Extremely time-consuming,
> but I think that this is what people do.
C has the same potential to automate those things, as do lisp, cobol, and
fortran. None of them do it.
> >I can tell from his posts that Mr. Aberg has never participated in a serious
> >standardization effort involving a large group. One of the first things one
> >learns is that insulting the efforts of conscientious and hard-working
> >participants is a sure path *away* from progress.
>
> So this is one of the reasons that C++ seems to be unable to become a
> complete language: Lack of open-mindedness of the participants in such a
> group obstructs crucial developments.
It's more a case of basic human psychology at work: nothing seems to close
the minds of responsible volunteers who have spent years responding to
outside input so quickly as wild accusations of a conspiracy to suppress
outside ideas, ill-supported claims, or arrogant presumption that the result
is somehow "incomplete".
> I guess that this is the reason that nearly all important creative
> developments of history are one man projects.
I eagerly await the day that Mr. Aberg arrives on the moon in his hand-built
lunar module.
-Dave
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/21 Raw View
Hans Aberg wrote:
>
> In article <6tu2c3$q7o$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
> Clamage) wrote:
> >Still complaining, still not volunteering to do any actual work.
>
> I thought by pointing out the features that I think needs to be changed,
> which you label as "complaining" (perhaps you can only work with
> yes-men?), I was volunteering a great deal of work. Writing these posts
> take a lot of time, and if I had thought bringing out this information was
> a whooly futile work, I would have stopped a long time ago.
Actually making the change requires far more work than writing the posts
you've made. Until such time as you actually convince somebody else that
it should be done, it won't get done unless you're willing to do it.
> >If you want to get the charter changed, here are some web
> >sites to help you get started.
> >
> > http://www.iso.ch/ -- ISO charters SC22/WG21
> > http://www.ansi.org/ -- ANSI publishes American standards
> > http://www.ncits.org/ -- NCITS charters J16
>
> Than you for the URL's. But for the change of the ISO charter, it is
> needed somebody understanding politics. I am not sure it can be done
> within those organizations, it is on a too low level.
It can't be done at a higher level; ISO is only answerable to its
members. The best you can hope for is to join your country's member
organization, and convince that organisation to lobby the other ISO
members to make the change you want.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/21 Raw View
At 13:35 -0700 98/09/21, Nathan Myers wrote:
>> So this is one of the reasons that C++ seems to be unable to become a
>>complete language: Lack of open-mindedness of the participants in such a
>>group obstructs crucial developments.
>>
>> I guess that this is the reason that nearly all important creative
>>developments of history are one man projects.
>
>As we say in English, you are out on a limb and sawing briskly.
It seems you have a funny notion of English.
>You are criticizing the wrong thing, and the wrong people.
>Be more careful.
Do you think this veiled threat is a sign of open-mindedness?
>The C++ committee members have been unusually open-minded, just
>as engineers, but especially for a standard committee.
So you claim open-mindedness while on the same time bashing those that
do not merely say yes to your opinions -- sounds as a contradiction to me.
> Many people
>have complained for years that they have been too open-minded, and
>delayed the standard by years as a result.
I feel pretty sure they did not complain over that the committee was too
open-minded, but over the delays. :-)
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/09/21 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>At 13:35 -0700 98/09/21, Nathan Myers wrote:
>>The C++ committee members have been unusually open-minded, just
>>as engineers, but especially for a standard committee.
> So you claim open-mindedness while on the same time bashing those that
>do not merely say yes to your opinions ...
It seems to me the reverse is the case.
Although there is lots of disagreement on many topics in this
newsgroup, we don't normally find those holding opposing views
accusing one another of being closed-minded or unwilling to listen
to any but yes-men.
Yet you accuse those who disagree with you of exactly those biases.
Most of us recognize that honest people can disagree honestly,
and that disagreement doesn't necessarily mean that either of
the parties is unwilling to listen to other opinions.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/22 Raw View
Hans Aberg wrote:
>
> In article <6tjjsj$9fl$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
> >Let's rephrase. Since your original suggestion was for your own private
> >use and has not been verified, then it too must be irrelevant for the
> >discussions here.
>
> My suggestion was that the usability of the feature should be verified
> and that one should not blindly stare at the large number of immediate
> users.
I was not aware that the usability was in question. I presumed that you
intended something that was unambiguously usable, such as adding a
'multiprecision' type to the language, and hiding all the details about
how it was implemented from the user.
I don't think it's feasible to implement a multiprecision type with the
performance requirements you suggested, but if you remove those
requirements, I have no other feasibility concerns.
What I am concerned about is the advisability of making it a mandatory
feature.
> James Kuyper said that in view of the argument he gave, that was not
> necessary.
My argument has always been about the appropriateness of adding such a
specialized feature to the language standard; it was never about the
usability, and only indirectly about the feasibility.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/22 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
> My suggestion was that the usability of the feature should be verified
>and that one should not blindly stare at the large number of immediate
>users. ...
> Of course, the current C++ standard requires a large number of immediate
>users, so I argue that requirement should be dropped in favour of more
>general principles.
And who is that performs the evaluations and decides on their
validity?
Under the present scheme, they are interested parties who
volunteer to do the work. Any interested parties. Anyone
who cares enough to do the work.
What are you proposing as an alternative?
You seem to labor under the misconception that some isolated
secret group privately decides what should and should not be
part of C++. As I have attempted to explain many times, the
exact opposite is true.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/22 Raw View
In article 2109981205110001@sl67.modempool.kth.se, haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>
>In article <6tu2c3$q7o$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
>Clamage) wrote:
>>Still complaining, still not volunteering to do any actual work.
>
> I thought by pointing out the features that I think needs to be changed,
>which you label as "complaining" (perhaps you can only work with
>yes-men?),
Clearly, you have no experience with standards groups. Getting agreement
is difficult, requiring extensive discussion, and, ultimately, compromise.
Above all, it takes detailed analysis and thorough proposals to accomplish
any change or addition.
> I was volunteering a great deal of work. Writing these posts
>take a lot of time,
I could spend all day making lots of mud pies and not impress anyone.
Productive work is what counts.
Insisting that other people should do work that you would like to
benefit from isn't going to get you anywhere. If you want to make
a contribution, write a concrete proposal. Say what you want to
accomplish, justify its importance, analyze the impact on the rest
of the language, show that it is practical to implement.
When pressed on such matters you seem to retreat to complaining that
the process is not proper. But the process is open to all and is
run along democratic lines. If you don't like what the process has
produces, become part of the process and try to change it by doing
work such as I have suggested.
---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/22 Raw View
In article <haberg-2209980102280001@sl120.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> I feel pretty sure they did not complain over that the committee was too
>open-minded, but over the delays. :-)
Where have you been. WG21+J16 have suffered from frequent criticism
that they were being too creative, crossing the line between existing
practice (which they are supposed to standardise) and innovation which
they are not supposed to do.
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: abrahams@motu.com
Date: 1998/09/16 Raw View
In article <haberg-1409981432360001@sl89.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
>
> That is probably a very good way to get more advanced and sophisticated
> features excluded:
It's a very good way to make sure that the features that do go in the standard
are implementable and will have predictable semantics. The various individual
members of the committee that I have met tend to be conservative and careful;
the result is that "advanced and sophisticated" features that are not well-
specified or understood (by more than one or two people) will not be accepted
into the language. Most features were tested for feasibility in trial
implementations before being accepted. This is entirely appropriate.
> For example, it is easy to note that C++ lacks support for implementing
> a conservative GC, which I immediately noticed when trying to write onein
> C++.
Actually, C++ has remarkably good support for writing garbage collection, as
high-level languages go. I'd be curious to know what language Mr. Aberg finds
superior in this regard.
> But a fully worked out proposal would involve a bunch of GC experts
> which perhaps do nothing but GC all day. You might not expect the experts
> writing the proposal themselves, but having somebody else writing it based
> on interaction with them.
And the problem with that is...?
<snip>
> As far as I can see, you have a good start for C++ becoming a complete
> language, but no more. By seriously questioning the methodology you have
> used so far, you might make progress, but not otherwise.
I can tell from his posts that Mr. Aberg has never participated in a serious
standardization effort involving a large group. One of the first things one
learns is that insulting the efforts of conscientious and hard-working
participants is a sure path *away* from progress. To be qualified to advise a
journeyman on how to make progress, surely one must have made the journey
himself.
> Aha, you want proposals written according to your own dictates; then you
> should probably engage a special set of people good at rewriting
> suggestions in that way: This would be like a journal which wants things
> coming in a special style, which would engage special layoutare, not the
> authors of articles, for doing that work.
A short story: 2 years ago I noticed that I was dissatisfied with a part of
the C++ standard. I wanted more support for exception-safety. The standard
now supports exception-safety to a level with which I am satisfied. The path
to the results I wanted involved attending meetings, participating in
feasibility discussions on the committee mail reflector, the production of
two trial implementations of the feature, writing a test suite to verify the
trial implementation, writing and presenting two separate proposals to the
committee, justifying the proposals to other members with arguments that most
found satisfactory, exercising tolerance and respect for the objections of
those that didn't agree, and finally, *enlisting the cooperation of more
experienced participants to help me present my ideas in a manner according to
existing practice*. Mr Aberg could do the same, but first he would need to
enlist allies. I suspect his list of potential allies is rapidly dwindling.
> Anyway, this is what I think would be required if you want to add some
> more advanced or more widely useable features (such as Internet libraries)
> to C++.
Mr. Aberg is the one who seems to "want to add some more advanced features" to
C++. The burden of presenting convincing support for his proposals rests with
him.
-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/17 Raw View
In article <6tmceg$hqd$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
(Steve Clamage) wrote:
>That's exactly right! It is not possible to support every language
>feature and every style of programming in a single language.
>For C++ there has been over the last 8 years a public decision-
>making process to determine which candidate features are
>"broadly used" and which are "too special". Any interested
>person anywhere in the world is allowed to participate in the
>process. The process itself has been announced as publicly
>as possible.
So what I am saying is that this requirement must be dropped if C++
should become a complete language. The replacement should the addition
features if they are general in their (logical) nature, and help solving
central computational problems. In this version, a high number of
immediate C++ prgrammers using the feature might be consideable, but it
should be balamnced against the principles normally used for developing
(scientific) quality.
>Features that are deemed not general enough to go into the standard
>can be and often are provided by interested parties as add-on
>libraries.
Note that there is a difference between a feature being general in
nature and that a feature has many immediate users: These two concepts are
in fact independent of each other.
The simplest way to extend C++ further is to work through various
problems, like multiprecision numerics and GC, and add to C++ just those
features that makes it possible to write ones own libraries and programs
conveniently without having reverting to assembler, and such that the code
can be considered to be fairly portable.
Then people can start write C++ libraries with such features, and if C++
eventually should have its own GC or multiprecision library is less
interesting.
>Admittedly, some features (like a dynamic type system) cannot
>be reasonably added on, but to be useful need to be part of
>the core language. Some such features (like a dynamic type
>system) have been deliberately excluded as not conforming to, or
>even being in direct opposition to, the stated language goals.
I should add that I myself never proposed that C++ should have a dynamic
type system (I ahve myself no use of it): Instead, C++ should have the
features added that enables one to implement dynamic features, which is
something different.
C++ is interesting because it has the capacity of generating efficent
code, but then all stuff needed must be there.
>If you have fundamental disagreements with the language goals,
>possibly you should look for some other programming language.
Or C++ could stop calling itself a standard, thereby avoidng creating a
negative pressure by its presence. Society usually has to counter such
negative pressure, anti-monoply laws are examples of this.
The fact that C++ thinks of itself as a standard of widespread use
forces through a principle that it cannot be too special, in a way it
hampers the individuals right to self-development.
>GC is still a bad example to illustrate your objections. Add-on
>GC implementations exist for C++, some of them non-intrusive and
>easy to use. (But still not quite the same as a language with
>built-in GC.)
Again, I have never suggested C++ with a GC: I suggest C++ be extended
so that I can add a GC to the program I write. The GC should be tailored
to the needs of the program, so the GC I need to use I need to either
write myself or use a special library for. (So, in particular, the C++
GC's you have in your mind would not help much for this task.)
So note that there are two entirely different matters: adding feature X
to C++, and adding features to C++ so that feature X can be implemented
conveniently and efficiently using C++. For the different features X I
have discussed, adding it to C++ would be a rather extensive task, and it
would not help solving the problems that I discuss either.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/17 Raw View
In article <1y64gxARgR$1EwAF@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>You really have absolutely no idea what you are talking about. The lack
>of GC in the current standard was a deliberate and considered decision
>even if it is one with which you would clearly disagree.
Well, I thought it was a deliberate and considered decision, so it is
probably you who do not know what you are talking about: I say that this
deliberate and considered decision seems to be caused by narrow-minded
principles used to develop the C++ standard.
>Before you go any further you have to understand what the standards
>process is for and how it works.
You have completly misunderstood this: I try to inform what I think the
standards process ought to be for, by indicating the principles I think
ought to be valid: A standard cannot be allowed to exclude influential key
groups in the name of mass-consumption. This is a important principle of a
modern democratic society, and I think if it is not true with the
standards today, it will be a forced principle for the standards written
tomorrow.
> You might also benefit from a quick course in diplomacy.
Diplomacy is one of my specialties. :-) I am myself for mainly playing
soft-ball when possible.
>Those that donate time (yes they do, there is no pay for doing the work)
>to standards efforts get one small reward, they get to choose what they
>will work on. OTOH anyone is free to come and join in by doing some
>work even if it is work of your own choosing. However you would hate it
>because technical experts expect others to explain their ideas and
>provide rational responses to arguments rather than argument by
>assertion.
I think what is going on is that you have invested a lot of time and
effort, and cannot stand that somebody hints that the standard and the
principles it builds on are not perfect.
What does OTOH mean?
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/09/17 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>In article <1y64gxARgR$1EwAF@robinton.demon.co.uk>, Francis Glassborow
><francis@robinton.demon.co.uk> wrote:
>>Before you go any further you have to understand what the standards
>>process is for and how it works.
> You have completly misunderstood this: I try to inform what I think the
>standards process ought to be for, by indicating the principles I think
>ought to be valid: A standard cannot be allowed to exclude influential key
>groups in the name of mass-consumption. This is a important principle of a
>modern democratic society, and I think if it is not true with the
>standards today, it will be a forced principle for the standards written
>tomorrow.
As I have said repeatedly, no one is excluded from the process.
Any interested persons can contribute to the process even if
they do not wish to become formal members of the standards
committee. Indeed, non-members have submitted proposals which
eventually found their way into the C++ standard. Even casual
comments posted in newsgroups like this one have resulted in
changes to the standard.
> I think what is going on is that you have invested a lot of time and
>effort, and cannot stand that somebody hints that the standard and the
>principles it builds on are not perfect.
No one, least of all committee members, believes the standard is
perfect. We committee members have committed to spending the next few
years reviewing reports of deficiencies in the published standard.
The principles behind the standard comprise the charter of the
C++ committee. We are not free to violate the charter, and are
constrained to follow it by the organizations (ANSI and ISO) who
granted the charter.
> What does OTOH mean?
"On the other hand."
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/09/15 Raw View
In article <haberg-1409981432360001@sl89.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In article <6thksh$5kb$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
> Clamage) wrote:
> >The committee has also solicited input from experts in fields
> >where we needed help. Sometimes help was forthcoming, sometimes
> >not. We usually find that people who complain about significant
> >missing features suddenly become very quiet when we explain
> >that we would be delighted to see a fully worked out proposal.
>
> That is probably a very good way to get more advanced and sophisticated
> features excluded:
>
> For example, it is easy to note that C++ lacks support for implementing
> a conservative GC, which I immediately noticed when trying to write one in
> C++.
You chose a bad example from your point of view. Several GC experts DID
write a proposal; they withdrew it because they and the committee felt that
it was too late for this round. Then Bjarne Stroustrup proposed a few
modifications which would make GC possible (by declaring some specific
operations which result in hiding pointers undefined behavior); it was
voted down.
[...]
> >Complaining is easy. Writing solid proposals requires a lot
> >of work. Instead of complaining that other people aren't
> >volunteering to do work you would like to benefit from, how
> >about doing some of it yourself?
>
> Aha, you want proposals written according to your own dictates; then you
> should probably engage a special set of people good at rewriting
> suggestions in that way: This would be like a journal which wants things
> coming in a special style, which would engage special layoutare, not the
> authors of articles, for doing that work.
There is no requirement that proposals be written according to any
dictates, only that they be complete, and address all of the issues.
There is no requirement that a proposal eminate from, or be presented
by, a committee member, although it is certain that being present
during the discussion can help.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/15 Raw View
In article <6tm6tu$ble$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com wrote:
>You chose a bad example from your point of view. Several GC experts DID
>write a proposal; they withdrew it because they and the committee felt that
>it was too late for this round. Then Bjarne Stroustrup proposed a few
>modifications which would make GC possible (by declaring some specific
>operations which result in hiding pointers undefined behavior); it was
>voted down.
I was aware of that there had been a voted-down GC proposal.
Your description seems to prove my point, namely that the current C++
standardization principles are such that it allows features used broadly
but excludes those that are deemed to special.
So in the case of GC, specialized features that make implementors of
GC's happy are excluded, and therefore nobody gets acces to it via the C++
language: Not those prgramming in it directly via libraries, nor those
using the dynamic languages that otherwise might be implemented using C++.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/09/15 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>In article <6tm6tu$ble$1@nnrp1.dejanews.com>, jkanze@otelo.ibmmail.com wrote:
>>You chose a bad example from your point of view. Several GC experts DID
>>write a proposal; they withdrew it because they and the committee felt that
>>it was too late for this round. Then Bjarne Stroustrup proposed a few
>>modifications which would make GC possible (by declaring some specific
>>operations which result in hiding pointers undefined behavior); it was
>>voted down.
> I was aware of that there had been a voted-down GC proposal.
> Your description seems to prove my point, namely that the current C++
>standardization principles are such that it allows features used broadly
>but excludes those that are deemed to special.
That's exactly right! It is not possible to support every language
feature and every style of programming in a single language.
For C++ there has been over the last 8 years a public decision-
making process to determine which candidate features are
"broadly used" and which are "too special". Any interested
person anywhere in the world is allowed to participate in the
process. The process itself has been announced as publicly
as possible.
Not everyone agrees with every decision. That also isn't possible.
(Standardization has been described as the process of getting
a group of intelligent and opinionated people to agree on trivia.)
Features that are deemed not general enough to go into the standard
can be and often are provided by interested parties as add-on
libraries. The nature of C++ is that it is extensible without
modifying the core language. If a feature so provided proves to
be of wider interest and utility, it can be adopted into a future
version of the standard. Computational types like big integers,
rational numbers, or "money" are perfect examples.
Admittedly, some features (like a dynamic type system) cannot
be reasonably added on, but to be useful need to be part of
the core language. Some such features (like a dynamic type
system) have been deliberately excluded as not conforming to, or
even being in direct opposition to, the stated language goals.
If you have fundamental disagreements with the language goals,
possibly you should look for some other programming language.
Smalltalk or Java might meet your needs, for example. They do
provide dynamic typing and garbage collection. The alternative
is somehow to persuade the membership of the C++ Committee to
change the goals of the language in a future standard.
> So in the case of GC, specialized features that make implementors of
>GC's happy are excluded, and therefore nobody gets acces to it via the C++
>language: Not those prgramming in it directly via libraries, nor those
>using the dynamic languages that otherwise might be implemented using C++.
GC is still a bad example to illustrate your objections. Add-on
GC implementations exist for C++, some of them non-intrusive and
easy to use. (But still not quite the same as a language with
built-in GC.)
I wouldn't be surprised to see GC added to C++ in a future standard,
since there will be time to evaluate proposals. It was never the
case that GC was considered too specialized. The problem was only
one of timing, as James Kanze explained.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jcoffin@taeus.com (Jerry Coffin)
Date: 1998/09/16 Raw View
In article <haberg-1509982018180001@sl21.modempool.kth.se>,
haberg@REMOVE.matematik.su.se says...
[ ... ]
> So in the case of GC, specialized features that make implementors of
> GC's happy are excluded, and therefore nobody gets acces to it via the C++
> language: Not those prgramming in it directly via libraries, nor those
> using the dynamic languages that otherwise might be implemented using C++.
Yes and no -- it's entirely possible to get garbage collectors for C++
(at least one free one, and another commercial one). In theory they
can break if you apply them to code that hides pointers, such as by
writing them out to a file and not storing a copy in memory.
I've used a garbage collector with several megabytes of more or less
randomly chosen C++, and not seen any code that broke it at all.
Certainly if you were writing code with it in mind, it's _easy_ to
avoid the few things that could break it; in fact, unless you set out
with the specific intent of breaking it, you're not likely to ever
notice that it can be broken.
I know of exactly one technique that's reasonably well known, has an
at least somewhat legitimate purpose, and breaks a conservative GC.
You can create a static linked list that can be traversed in either
direction by storing the XOR of the forward and reverse pointers in
each internal node. This allows traversal in either direction while
only storing one pointer-sized object per node.
I suppose in theory, if you were implementing some sort of virtual
memory system of your own, you could end up saving pointers in a disk
file and later expecting them to remain usable.
However, I'd estimate that over 99% of all C++ code in existence could
be used with a conservative GC and never cause a problem at all.
Also, problems would arise (TTBOMK) only because of the code you
wrote, not due to changes in compilers -- using it wouldn't cause
portability problems beyond finding a GC for the systems to which you
wanted to port the code.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/16 Raw View
In article <haberg-1409981432360001@sl89.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> But a fully worked out proposal would involve a bunch of GC experts
>which perhaps do nothing but GC all day. You might not expect the experts
>writing the proposal themselves, but having somebody else writing it based
>on interaction with them.
You really have absolutely no idea what you are talking about. The lack
of GC in the current standard was a deliberate and considered decision
even if it is one with which you would clearly disagree.
>
> So when I say that one should not sit in an ivory tower, then it means
>that one first must recognize which features that seems to be amiss, and
>then round up the people that are experts on that issue. I think an expert
>would be more interested and willing to voulnteer work when the C++
>committee start to show serious interest in an issue, but not before that.
Before you go any further you have to understand what the standards
process is for and how it works. You might also benefit from a quick
course in diplomacy.
>
> As far as I can see, you have a good start for C++ becoming a complete
>language, but no more. By seriously questioning the methodology you have
>used so far, you might make progress, but not otherwise.
Doing what you want has nothing to do with standards. If there were
really a demand any one of a number of commercial vendors would leap at
the chance to make extensions. Ever wonder why even the high quality
specialist vendors don't?
Those that donate time (yes they do, there is no pay for doing the work)
to standards efforts get one small reward, they get to choose what they
will work on. OTOH anyone is free to come and join in by doing some
work even if it is work of your own choosing. However you would hate it
because technical experts expect others to explain their ideas and
provide rational responses to arguments rather than argument by
assertion.
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/09/16 Raw View
Hans Aberg made an interesting but rather obscure suggestion for the
language.
James Kuyper said something like: "Very few users need this feature."
Hans Aberg responded with something like: "How do you know how many
people need the feature?"
> In article <35F7EE9A.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >> >If I was worryied about whether the fraction of users that need this
> >> >feature was between 0.45 and 0.5, this would be a very poor method.
> >> >However, I don't need a high precision estimate to justify a conclusion
> >> >that the fraction is probably a lot less than 0.1.
And lots of other things, all intended to point out that even though
the number wasn't very precise, it was accurate enough for the way
it was used.
In article <haberg-1109981232470001@sl109.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> >> Of course, such claims should be verified by scientific means.
And other defensive statements, designed to make Mr. Kuyper feel as
if he doesn't know what he's talking about.
Kuyper:
> >Why? the claim is not being used by anyone but myself, and I'm not using
> >it for anything that I consider important.
Aberg:
> If it is for your own private use and left unverified, then it is
> irrelevant for the discussions here.
Mr. Aberg, aren't you doing exactly what you're accusing Mr. Kuyper of
doing?
Let's rephrase. Since your original suggestion was for your own private
use and has not been verified, then it too must be irrelevant for the
discussions here.
Perhaps your original suggestion was NOT for your private use, and
perhaps it HAS been verified. But if that's the case, you will have to
tell us HOW it was verified, and WHY a lot of programmers would use it.
Personally, I just don't get it, and I seem to have a lot of company.
> >If the issue is important to
> >you, you should pay the costs (both time and money) of collecting the
> >information needed to convince other people that you are right.
> >Personally, I have no idea how to obtain a more accurate estimate, and I
> >don't care enough to find out.
I agree.
> You seem to use a discussion technique of promoting your own views by
> raising unrealistic conditions on others.
Which part are you calling unrealistic? The need to convince others,
before adding new ideas to the standard? Or do you expect Mr. Kuyper
to foot the bill for ideas YOU (and possibly only you) believe to be
important?
Mr. Aberg, perhaps you are so brilliant that you can easily see what
the rest of us can't see. If that's the case, you will have to (1)
give up on getting it into C++, or (2) take more pains (and probably
cost) to EXPLAIN IT TO US, using TACT AND DIPLOMACY. Currently the
issue is important ONLY TO YOU, but if you want it in the standard
you will have to make it important to EVERYONE.
I'm sure you will retort with some message indicating that I don't
speak for everyone (true, I'm not even on the committee), or that I
don't have any experience with what you want to do (true, but if
very few people do, it doesn't belong in the standard), or some
other rot. Go ahead and retort. But when you've finished your
knee-jerk reaction, re-read this message and THINK ABOUT IT. Take
some time. Ask yourself why the C++ committee should do ANYTHING
for you. There is a correct answer to that question, but until you
figure out what it is, you won't get anywhere.
> In contrast, I believe any further developments of the future versions
> of the C++ standard be based on facts. This way one can avoid it being
> just a mish-mash of unstructured impulsive wants.
If the point of this paragraph was to annoy people, then it was
redundant -- many of us are already quite annoyed.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/16 Raw View
In article <v8vlnnm26d0.fsf@piano.dptmaths.ens-cachan.fr>, Gabriel Dos
Reis <dosreis@DPTMaths.ens-cachan.fr> wrote:
>HA> The problem is evidently that the C++ standard is developed using
>HA> principles of mass-consumption and not principles of quality.
>
>If you don't want to consum it, no one forces you to. Just pick
>the language which best fits your needs.
This is only true if one disregards the social pressure created by the
presence of the C++ standard. Society usually has to counter such indirect
negative influences, for example, anti-monopoly laws are examples this.
So a standard must not only ensure that there is a wide group of users,
but also that its presence does not conflict with the needs of
individuals.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/12 Raw View
In article <haberg-1009981416000001@sl12.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> I could compare this with the development of STL within C++: Some out
>there probably have had some difficulty of understanding it, but thanks to
>my background as a mathematician I instantly recognized it as the first
>small step towards more efficient programming building on abstractions.
The basic STL was offered to the C++ Standards Committees as a complete,
fully worked out and tested package. They then made some changes having
convinced themselves that the substance was of outstanding value. Note
that those responsible were not asked to do the work but asked to
consider including a substantially completed major element to the
Library.
If you want to pursue your ideas re multiprecision numerics you must do
one of two things
either
work with others to prove viability by demonstrating a working package
on at least one platform
or
persuade others of the intrinsic value of your work to the extent that
they are willing to donate considerable resources to producing a viable
package.
I have to say that your present postings would not encourage me to
participate in either of the above. Sometimes you need a bit of
diplomacy to get ideas across, and you also need to do the work or pay
someone to do it.
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/12 Raw View
In article <35F7EE9A.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>> >If I was worryied about whether the fraction of users that need this
>> >feature was between 0.45 and 0.5, this would be a very poor method.
>> >However, I don't need a high precision estimate to justify a conclusion
>> >that the fraction is probably a lot less than 0.1.
>>
>> Of course, such claims should be verified by scientific means.
>
>Why? the claim is not being used by anyone but myself, and I'm not using
>it for anything that I consider important.
If it is for your own private use and left unverified, then it is
irrelevant for the discussions here.
>If the issue is important to
>you, you should pay the costs (both time and money) of collecting the
>information needed to convince other people that you are right.
>Personally, I have no idea how to obtain a more accurate estimate, and I
>don't care enough to find out.
You seem to use a discussion technique of promoting your own views by
raising unrealistic conditions on others.
In contrast, I believe any further developments of the future versions
of the C++ standard be based on facts. This way one can avoid it being
just a mish-mash of unstructured impulsive wants.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: alanstokes@my-dejanews.com
Date: 1998/09/12 Raw View
In article <haberg-1009981416000001@sl12.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In GHC, the Glasgow Haskell compiler implemented in assembler, one
> fellow reports that int's are about 4-5 times faster than Integer's under
> similar circumstances. There is also a Haskell interpreter implemented in
> C, called Hugs.
GHC is not implemented in assembler; it generates assembler. No sane person
would attempt to implement a compiler in raw assembler these days, especially
for such a language.
> One difference between GHC, implemented in assembler, and Hugs,
> implemented in C, is that the latter relatively quickly can be ported to a
> number of platforms.
The reason for the difference in porting time is that for a compiler an
entire new code generator is needed, but for an interpreter it isn't.
(Although one of the 'assembly languages' GHC can produce is C, which eases
the problem somewhat.)
> So if
> one is forced to revert to assembler, the number of platforms will
> decrease radically.
Of course. But nothing is forcing you to revert to assembler. C++ is much more
expressive, and very likely to be efficient enough. (If it isn't, them you can
always hand-optimise, or even move to assembler, the very small propotion of
the code that needs it; but before spending time on this make sure you really
have a problem.)
> So one would really want to be able to use C++ instead of C implementing
> languages such as Haskell, avoiding as much assembler programming as
> possible. One then ends up on the equation I tried to describe in this
> thread.
I'm not sure how this is supposed to follow from what goes before. But there
is no reason why C++ or C shouldn't be used in writing a Haskell compiler or
interpreter, or even as the output language of a compiler.
> However, in order to understand how C++ might be extended to support the
> implemention of such dynamic features, one must also understand the
> context of such dynamic features. This understanding is not always easy to
> describe to those which knows little about it; often some hands on
> experience is needed in order for that understanding to develop.
This is an understatement; I don't think you've succeeded in explaining what
problem you think there is with standard C++ as it is, or what your proposal
to solve the problem is, to anyone on this group.
If you were to make a detailed proposal, and preferably produce a trial
implementation, I should be fascinated to see it.
--
- Alan
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/12 Raw View
Hans Aberg wrote:
>
> In article
> <christian.bau-1009981427530001@christian-mac.isltd.insignia.com>,
> christian.bau@isltd.insignia.com (Christian Bau) wrote:
> >I have read quite a lot of posts from James Kuyper and if my impression is
> >not completely wrong, I would say he is quite qualified to judge whether a
> >suggestion for the C++ standard is reasonable or unreasonable.
>
> I think that he is qualified judging that on the features of C++ dealing
> with programming he has considerable experience with. But from what I
> understand, he does not implement dynamic languages and such.
I also haven't done many other styles of programming. That doesn't
prevent me from having some idea of how many people need various
techniques. I know a great deal about Riemannian manifolds, and am
looking forward to designing a C++ package of my own for working with
them. I would never dream of suggesting that this package be made part
of the standard library.
I think that you are so caught up in the needs of your own project, that
you are having trouble judging just how specialized those needs are.
...
> So if a suggestion is determined to be examined in this avalanche of
> uncontrolled wants, then it may snowball and it can be difficult to put on
> the breaks later. So instead of that one gets peace and quiet,
> systematically putting things into their proper places, the features
> passed through are those surviving this frency of instant wants, resulting
> in a big, unstructutred mish-mash.
It is the process of keeping tight control over what gets into the
standard, or systematically putting things in their proper places, which
helps avoid getting a "big, unstructured mish-mash".
...
> My guess is that you do not implement dynamic languages and such, so you
> do not have any immediate use of it, do not want to learn about it, and do
> not want it to be included for that reason. Right?
I can't speak for Christian Bau, but I suspect you believe the same
about me, so I'll give you my answers:
"do not implement dynamic languages" - True
"do not have any immediate use of it" - True
"do not want to learn about it" - mostly true
(I have some curiosity about it)
"do not want it to be included" - True
"for that reason" - False
I don't want it included because I think that all but a small minority
of other C++ users could say "True" to the first two items on that list.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/12 Raw View
In article <v8vn28887fx.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
>HA> Of course, such claims should be verified by scientific means.
>
>Such as?
Ask the fellow who made the unverified claim, not me.
>HA> Otherwise, the fraction of users of General Relativity is also very
>HA> small, but this does not mean that one should not have it in physics. In
>HA> other words, the principle is that the importance of a feature depends on
>HA> how influential the feature is, and not how many that happens to use it.
>
>You're comparing oranges and apples.
Not really, the principle is the same.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/12 Raw View
In article <6tb5uj$bne$1@nnrp1.dejanews.com>, alanstokes@my-dejanews.com wrote:
>GHC is not implemented in assembler; it generates assembler. No sane person
>would attempt to implement a compiler in raw assembler these days, especially
>for such a language.
It is at least so that one must have a GHC kernel which needs some
decoded understanding of assembler instructions. On top this kernel, GHC
compiles itself I think.
I have not used the program myself; I only note that its need for
assembler makes it not getting ported to many platforms.
>.. But there
>is no reason why C++ or C shouldn't be used in writing a Haskell compiler or
>interpreter, or even as the output language of a compiler.
There are many reasons against using C++ (just the GC question makes C++
a bad choice), and those problems are what we are discussing. I propose
C++ should examined thoroughly to provide the convenient implementation of
such languages.
One way to do this could be to take say the Hugs sources, written
entirely in C and rewrite it in C++, and see what is needed. But nobody is
going to do that massive of work with the attitudes displayed in this
group. For such a thing to work, I think a completely different
methodology to develop the C++ standard is needed.
The way it looks to me, things done in C by hand, like building covers
and binding variables to registers can be done conveniently in C++ by the
use of automatic variables. For example, in C one might construct
MkClosure Env{plus=<whatever>; y=42} ((\f x -> f (f x)) (plus 1) y)
implementing explicity how this environment should he pushed onto the
stack, perhaps binding "plus" to register 7 or something.
In contrast, in C++ I construct
Data g = new Formula(...); // Create g = \f x -> f (f x)
Data p = new Plus(1); // Create "plus 1"
Data y = new Integer(42); // Bind y to 42
return g(new Substitute(\f, p))(new Substitute(\x, y));
and the same computation would result, and I think this corresponds to
what is done by hand in C.
So C++ certainly has the rudiments for doing such work, but is not
complete. I think it should be completed by systematically examining the
features that need to be added.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/12 Raw View
In article <6tbobi$l45$1@engnews1.eng.sun.com>, stephen.clamage@sun.com
(Steve Clamage) wrote:
>Stroustrup's early criterion, and the criterion later adopted by
>the C++ committee, was that to be adopted, a feature should
>solve a general programming problem of wide applicability for
>which there was no good workaround already. That's the plan,
>at least. (An exception is something so commonly needed that
>a standard library function is provided so as to have a standard
>idiom.)
The problem here is that solving a programming problem, general in
nature, is not the same thing as there are many immediate users of that
feature, so this is the part that the current C++ standardization work
misses. One reason for striving for higher levels of generality and
abstractions despite there are no immediate high number of users is that
it often forces through a more organized structure, will later may
influence a higher number of users. Understanding this process requires a
great deal of insight.
>Getting out a standard is a political as well as a technical
>process.
So this is what I try to point out.
>In particular, missing features often reflect lack of participation
>in the committee work by people who would want the feature and
>understand it well enough to write good specifications.
>If no usable proposal is presented to the committee, the feature
>isn't going to appear in the standard. Stroustup in D&E describes
>what I mean by "usable proposal", and it means a lot of hard work.
Instead of sitting in an ivory tower and hoping "usable proposals"
dropping in, I think the committee needs to reach out saying that this or
other category of programming techniques is subject to review; then one
might get contact with those heavily engaged say in implementing dynamic
languages and other such categories.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/12 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
[...]
HA> This your statement confuses me: I program on C++ code compiling on
HA> 400000 lines. Are you suggesting me to describe how that works, despi=
te
HA> you have no knowledge of such techniques at all, or do you want me to
HA> write a new C++ compiler?
If you care to explain me "such techniques" then I think I could
understand them.
In fact, an article describing how to implement your extensions
coming with an *effective* implementation of Standard-C++-plus-your-
extensions would be more than enough. Then I think I could probably
use them to figure out how effectively I need them in my numerical
computations.
HA> I tried the former approach, but that did not seem to produce much
HA> understanding in those that replied, despite working through several
HA> hunderd posts.
HA> For the latter, I plan to include dynamic verions of lex and yacc, so
HA> writing a C++ compiler is not so interesting from that point of view.
Ah, I see. Are your features so interesting?
HA> Otherwise, I do not think I have the full knowledge in my hand to make
HA> the determination of what might be included in the next C++ version, I
HA> just report the features that happen to come my way.
Well, one point to keep in mind is: C++ does not have the pretention
to provide all imaginable features any programmer can come across or to
prove any theorical point. Its main purpose is to serve as a practical
tool. Please consult the D&E for more detailed discussion.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
--
"One reason that life is complex is that it has a
real part and imaginary part." -- Andrew Koenig
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1998/09/12 Raw View
>>>>> Hans Aberg <haberg@REMOVE.matematik.su.se> writes:
HA> Otherwise, the fraction of users of General Relativity is also very
HA> small, but this does not mean that one should not have it in physics. In
HA> other words, the principle is that the importance of a feature depends on
HA> how influential the feature is, and not how many that happens to use it.
>>
>> You're comparing oranges and apples.
> Not really, the principle is the same.
No, it isn't. Physics has already been implemented.
Jason
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/12 Raw View
Hans Aberg wrote:
>
> In article <35F7EE9A.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >> >If I was worryied about whether the fraction of users that need this
> >> >feature was between 0.45 and 0.5, this would be a very poor method.
> >> >However, I don't need a high precision estimate to justify a conclusion
> >> >that the fraction is probably a lot less than 0.1.
> >>
> >> Of course, such claims should be verified by scientific means.
> >
> >Why? the claim is not being used by anyone but myself, and I'm not using
> >it for anything that I consider important.
>
> If it is for your own private use and left unverified, then it is
> irrelevant for the discussions here.
It's not just for my own private use, and I've made as much of an effort
to verify it as is justified by the importance of the issue. I made the
judgement, and used it for two purposes: to decide whether I thought
your proposal should be approved, and to decide whether or not to tell
other people on this newsgroup of my opinion. I presented them with the
reasons for my judgement, leaving them free to make their own judgements
on the issue. That information was entirely relevant for this newsgroup.
What decisions they made based upon their own judgements is their
responsibility, not mine. Whether they had collected enough information
to justify those decisions was also their responsibility. I believe that
I've collected enough information to justify the two decisions I made. I
don't think that the importance of those decisions is sufficient to
justify a high-cost effort to survey the computer industry and find out
more accurately how many people could actually use your proposed change.
> >If the issue is important to
> >you, you should pay the costs (both time and money) of collecting the
> >information needed to convince other people that you are right.
> >Personally, I have no idea how to obtain a more accurate estimate, and I
> >don't care enough to find out.
>
> You seem to use a discussion technique of promoting your own views by
> raising unrealistic conditions on others.
Of course I'm promoting my own views; I wouldn't believe them if I
didn't think they were true, and I wouldn't be posting responses to this
newsgroup if I wasn't certain enough of their truth to state them in
public (I'm wrong embarrassingly often, but that's another issue).
You're free to consider my conditions unrealistic, and I'm free to
belive that you haven't made your point until you meet them. The rest of
the newsgroup is free to make their own judgements on the matter.
> In contrast, I believe any further developments of the future versions
> of the C++ standard be based on facts. This way one can avoid it being
> just a mish-mash of unstructured impulsive wants.
One of the types of facts that is relevant for any proposed change to
the standard is evidence that it is needed by a large enough group of
people to justify the change. As the proposer of this idea, you're
responsible for providing that evidence if you wish to convince me; what
you'd need to do to convince other people may be different.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/13 Raw View
In article <haberg-1109982059140001@sl102.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> If it is the hybrid part you are objecting to, it is just a standard way
>to speed up a class. A technicality, simply. One can do it for strings and
>other classes too. The thing is that a dynamic memory allocation in C++
>can take (some say) 50-100 memory cycles, so if one can avoid that, one
>may speed it up a little. But if a compiler has faster dynamic memory
>allocation, the need for hybrids lessens.
But using one of your arguments, I can reasonably hypothesise that
future architectures will reduce this overhead to insignificance.
Indeed, I think such a development is more likely than the support
needed to provide efficient multi-precision integers at machine level.
BTW if the demand became high enough I would expect the whole facility
to be provided by hardware (much as floating point is today). With a
reasonable array processor I could probably get pretty good extended
precision integer arithmetic without all the hassle you are proposing.
Rather than spend many tens of thousands of hours (remember all the
implementation time over all platforms that your proposal seems to
expect) fixing a problem, let us first focus on some real problems such
as cleaning up the inevitable bugs in the current standard and
investicating what needs to be done to support the needs of C++
programmers developing for resource constrained environments (e.g.
embedded systems).
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/14 Raw View
In article <u9lnnp4nc8.fsf@yorick.cygnus.com>, Jason Merrill
<jason@cygnus.com> wrote:
> >> You're comparing oranges and apples.
>
> > Not really, the principle is the same.
>
>No, it isn't. Physics has already been implemented.
I think that this discussion might be more suitable in groups such as
comp.std.oranges.apples and sci.physics.research (and the latter is
recommended).
But the modern view though is that General Relativity is a physics
theory which is verified by experiments. So it is "implemented" when
created, "debugged" when verified by experiments, and "run" when applied.
So the methodology is exactly the same. :-)
The view that physical theories would have a closer relation to the
physical reality is a view I think was mainly true during the eighteenth
century.
So there appears to be something amiss in the development of the C++
standard, when it builds on principles that one in other quarters of
society scrapped a century ago.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/14 Raw View
In article <6te5di$m7c$1@engnews1.eng.sun.com>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
> Please consult the D&E for more detailed discussion.
Or the article posted by Steve Clamage and my reply in this thread. :-)
>C++ does not have the pretention
>to provide all imaginable features any programmer can come across or to
>prove any theorical point. Its main purpose is to serve as a practical
>tool.
The problem is evidently that the C++ standard is developed using
principles of mass-consumption and not principles of quality.
>In fact, an article describing how to implement your extensions
>coming with an *effective* implementation of Standard-C++-plus-your-
>extensions would be more than enough. Then I think I could probably
>use them to figure out how effectively I need them in my numerical
>computations.
Aha, you mean only the case of Integers. I thought you meant all the
programming techniques used when implementing a dynamic language (which I
know very little of myself, as I implement a dynamic semantics, not a
language).
In the case of Integer, the relation between the C++ extended version
and the non-extended version is trivial: In the extended case, one has
access to arithmetic and binary functions from which overflows can be
extracted efficiently (perhaps via exceptions); in the case of
multiplication, one might have access to functions like "pair<T, T>
mult(T,T)" and the like which efficiently multiplies the whole overflow
(hopefully written in assembler). In the non-extended case, just do the
same thing with the current C++ constructs. Because the overflows and
assembler instructions are not available, one has to do various tricks,
which decreases efficiency.
Then just implement an Integer class straightforwardly as efficiently as
possible, perhaps a hybrid speeding up arithmetic for int's fitting into a
word.
>Ah, I see. Are your features so interesting?
I have no way of telling if you want me to tell if the features of my
program are interesting or the implementation features I come across while
doing such programming.
To the first question, I try to stress generality, and to the extent
that can be achieved, I find that interesting. This leads to a programming
style where I do not feel as in an intellectual straitjacket as much, but
somewhat freer.
To the second question, some of the features I have come across are
intriguing, and other people seem to be in the need of such features too.
One example is the polymorhic virtual function pointer type discussed in
another thread "Dynamic cast of virtual function pointers", which now can
only be implemented using dynamic memory allocation, but would speed up
programs considerably if implemented as a special type not using dynamic
memory allocation.
So my hunch is the there are a set of such techniques that can be
collected and also be of more general use.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/09/14 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
> Instead of sitting in an ivory tower and hoping "usable proposals"
>dropping in, I think the committee needs to reach out saying that this or
>other category of programming techniques is subject to review; then one
>might get contact with those heavily engaged say in implementing dynamic
>languages and other such categories.
Once again, it would be a good idea to become informed instead
of just throwing rocks at a process you don't seem to understand.
The C++ committee doesn't sit in an ivory tower. Its members
come from many areas: academia, government, commercial
enterprises in the computer field, non-computer businesses,
and so on. Represented companies range from huge (IBM, Siemens,
and Toshiba, for example) down to one-person operations.
The fact of the commitee's work, its progress, and details of
features under consideration have been published in many forums over
the last 8 years. Those forums include usenet newsgroups; ISO, ANSI,
and NCITS publications and press releases; a wide variety of computer-
related general-circulation magazines; C++ related textbooks.
Two drafts of the standard have been circulated at no cost as
widely as we could figure out how to do. Input was actively
solicited (again, in all the forums listed above) for comments,
criticism, suggestions. Every comment received was logged,
discussed and replied to.
The committee has also solicited input from experts in fields
where we needed help. Sometimes help was forthcoming, sometimes
not. We usually find that people who complain about significant
missing features suddenly become very quiet when we explain
that we would be delighted to see a fully worked out proposal.
For example, you've complained a lot about features you would
like to see, but despite many requests for you to post one,
I don't remember seeing an actual proposal from you.
Complaining is easy. Writing solid proposals requires a lot
of work. Instead of complaining that other people aren't
volunteering to do work you would like to benefit from, how
about doing some of it yourself?
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/14 Raw View
In article <6thksh$5kb$1@engnews1.eng.sun.com>, clamage@Eng.Sun.COM (Steve
Clamage) wrote:
>The committee has also solicited input from experts in fields
>where we needed help. Sometimes help was forthcoming, sometimes
>not. We usually find that people who complain about significant
>missing features suddenly become very quiet when we explain
>that we would be delighted to see a fully worked out proposal.
That is probably a very good way to get more advanced and sophisticated
features excluded:
For example, it is easy to note that C++ lacks support for implementing
a conservative GC, which I immediately noticed when trying to write one in
C++.
But a fully worked out proposal would involve a bunch of GC experts
which perhaps do nothing but GC all day. You might not expect the experts
writing the proposal themselves, but having somebody else writing it based
on interaction with them.
So when I say that one should not sit in an ivory tower, then it means
that one first must recognize which features that seems to be amiss, and
then round up the people that are experts on that issue. I think an expert
would be more interested and willing to voulnteer work when the C++
committee start to show serious interest in an issue, but not before that.
As far as I can see, you have a good start for C++ becoming a complete
language, but no more. By seriously questioning the methodology you have
used so far, you might make progress, but not otherwise.
>For example, you've complained a lot about features you would
>like to see, but despite many requests for you to post one,
>I don't remember seeing an actual proposal from you.
Yes, I described all the principles needed to work out the details.
>Complaining is easy. Writing solid proposals requires a lot
>of work. Instead of complaining that other people aren't
>volunteering to do work you would like to benefit from, how
>about doing some of it yourself?
Aha, you want proposals written according to your own dictates; then you
should probably engage a special set of people good at rewriting
suggestions in that way: This would be like a journal which wants things
coming in a special style, which would engage special layoutare, not the
authors of articles, for doing that work.
Anyway, this is what I think would be required if you want to add some
more advanced or more widely useable features (such as Internet libraries)
to C++.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/14 Raw View
In article <uDxAooAx8D$1Ewgr@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>But using one of your arguments, I can reasonably hypothesise that
>future architectures will reduce this overhead to insignificance.
>Indeed, I think such a development is more likely than the support
>needed to provide efficient multi-precision integers at machine level.
I think that the user situation may vary: One may use multiprecision
with dynamic memory or with static memory, or simply having the need for
checking int over flows. To get full CPU support for true dynamic
multiprecision numerics is probably difficult, as it there is no good
place to put the intermediate results (modern processors often have
limited internal memory which is ten times faster than accessing RAM).
So making sure that several of the bit and arithmetic operations that
the (more modern) CPU's usually provide, but which C++ does not give
direct access to seems a more modest and easily achievable goal.
>BTW if the demand became high enough I would expect the whole facility
>to be provided by hardware (much as floating point is today).
I think too that is likely, and therefore I think that the C++ standard
will need to prudently address the problem of keeping up in the future
versions. This will require a different principle of action than the
current that there must be a high number of immediate users of a feature.
> With a
>reasonable array processor I could probably get pretty good extended
>precision integer arithmetic without all the hassle you are proposing.
>Rather than spend many tens of thousands of hours (remember all the
>implementation time over all platforms that your proposal seems to
>expect) fixing a problem, let us first focus on some real problems such
>as cleaning up the inevitable bugs in the current standard and
>investicating what needs to be done to support the needs of C++
>programmers developing for resource constrained environments (e.g.
>embedded systems).
Actually, there are two wholly independent questions, what to do with
the current C++ version, which should be stabilized in the way you are
proposing, and what to do with the next version, which is what I discuss:
If new features are added in a more structured way, it will not be so
difficult to add them, and the number of implementation hours required
will not so high. When the current C++ compilers start to stabilize, that
will leave the implementers having something to do with continued
development of C++ compilers.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/14 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
[...]
>> C++ does not have the pretention
>> to provide all imaginable features any programmer can come across or to
>> prove any theorical point. Its main purpose is to serve as a practical
>> tool.
HA> The problem is evidently that the C++ standard is developed using
HA> principles of mass-consumption and not principles of quality.
If you don't want to consum it, no one forces you to. Just pick
the language which best fits your needs. If you want to extend Standard
C++, nothing prevents you to do so. Just go ahead and do so. If you
eventually end up with an actual implementation and want to discuss it,
I don't see any reason why you could not. But please, please, stop
insulting people who have donated their time.
>> In fact, an article describing how to implement your extensions
>> coming with an *effective* implementation of Standard-C++-plus-your-
>> extensions would be more than enough. Then I think I could probably
>> use them to figure out how effectively I need them in my numerical
>> computations.
HA> Aha, you mean only the case of Integers. I thought you meant all the
HA> programming techniques used when implementing a dynamic language (which I
HA> know very little of myself, as I implement a dynamic semantics, not a
HA> language).
HA> In the case of Integer, the relation between the C++ extended version
HA> and the non-extended version is trivial: In the extended case, one has
HA> access to arithmetic and binary functions from which overflows can be
HA> extracted efficiently (perhaps via exceptions); in the case of
HA> multiplication, one might have access to functions like "pair<T, T>
HA> mult(T,T)" and the like which efficiently multiplies the whole overflow
HA> (hopefully written in assembler). In the non-extended case, just do the
HA> same thing with the current C++ constructs. Because the overflows and
HA> assembler instructions are not available, one has to do various tricks,
HA> which decreases efficiency.
HA> Then just implement an Integer class straightforwardly as efficiently as
HA> possible, perhaps a hybrid speeding up arithmetic for int's fitting into a
HA> word.
Then, when can I use your implementation of your extensions?
>> Ah, I see. Are your features so interesting?
HA> I have no way of telling if you want me to tell if the features of my
HA> program are interesting or the implementation features I come across while
HA> doing such programming.
HA> To the first question, I try to stress generality, and to the extent
HA> that can be achieved, I find that interesting. This leads to a programming
HA> style where I do not feel as in an intellectual straitjacket as much, but
HA> somewhat freer.
HA> To the second question, some of the features I have come across are
HA> intriguing, and other people seem to be in the need of such features too.
HA> One example is the polymorhic virtual function pointer type discussed in
HA> another thread "Dynamic cast of virtual function pointers", which now can
HA> only be implemented using dynamic memory allocation, but would speed up
HA> programs considerably if implemented as a special type not using dynamic
HA> memory allocation.
HA> So my hunch is the there are a set of such techniques that can be
HA> collected and also be of more general use.
Probably you're right. But what frutrates me is that I can't find your
implementation of your extensions in order to use them and appreciate
their values.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/14 Raw View
In article <v8vlnnm26d0.fsf@piano.dptmaths.ens-cachan.fr>, Gabriel Dos
Reis <dosreis@DPTMaths.ens-cachan.fr> wrote:
>Then, when can I use your implementation of your extensions?
As far as the Integer class, I have no direct need for it myself: I
implement it because it is a type one is expected to have; the question I
would be most interested in is how this type would behave relative various
runtime questions (such as determining delayed evaluation or building
runtime classes). It is also the initial object in the category of unitary
associative rings, so if one should implement higher abstractions, one can
think of implementing it for that reason.
So I started to write that class, and noticed those problems, and I
wanted to check this out relative to the C++ standard. Writing that class,
however, has a low priority to me, as other things have a higher priority
(for example, stuff related to the implementing the lambda calculus). So
if I write it, it is going to be a day when I do not have better things to
do.
But the class itself is rather standard: The Haskell mailing list has
right now a parallel, wholly independent discussion. The suggestion posted
there yesterday is pretty much the same as the one I plan to use for C++.
A poster mentioned that Smalltalk also has the Integer class, which by now
was fairly speedy.
So I think this and also some other techniques are in fact very standard
that everyone encountering a certain type of problems will need.
Then the concerns really are like the ones as I said: The users of the
final program (written in C++) want to use the Integer class without ever
thinking about int's and the like, but they also want to it to be
efficient relative int's. Then the guy writing the program is more
concerned about high-level things like lambda-theory than fiddling around
with details about the class Integer. The code should be portable say
across 32-bit machines, but also efficient, and one does not want to
revert to assembler. The fellow ending up with the problem of implementing
the problem is normally doing such kind of programming that may be
involved -- some such numerics implementations can be tricky if required
to be efficient, and must be left to experts on such.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/09/09 Raw View
Francis Glassborow wrote:
> I am puzzled, how can anything be accessible at assembler level and
> not in C++? I know that few programmers ever use asm but it is a
> keyword of C++ :)
I see the smiley, but seriously, have you ever tried to access the
"carry" or "overflow" CPU flag in C++ after an addition or
subtraction operation to see if the (integer) result overflowed?
Or tried to perform a bit "rotate" instruction directly in C++?
Or a "byte swap"?
While C++ gives you access to a large portion of the hardware,
it doesn't give you access to all of it. And while you can
certainly use 'asm' on many compilers, it's not portable (and it
does not even exist on some compilers, notably most of those on
Unix).
-- David R. Tribble, dtribble@technologist.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/10 Raw View
In article <35F6D0CB.2B1@noSPAM.central.beasys.com>,
dtribble@technologist.com wrote:
>I see the smiley, but seriously, have you ever tried to access the
>"carry" or "overflow" CPU flag in C++ after an addition or
>subtraction operation to see if the (integer) result overflowed?
>Or tried to perform a bit "rotate" instruction directly in C++?
>Or a "byte swap"?
>While C++ gives you access to a large portion of the hardware,
>it doesn't give you access to all of it. And while you can
>certainly use 'asm' on many compilers, it's not portable (and it
>does not even exist on some compilers, notably most of those on
>Unix).
In fact, this is quite close to the type of extansions of C++ I suggest
one should consider.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/09/10 Raw View
Fergus Henderson wrote:
>> Perhaps Hans Aberg means that if the numbers involved are small
>> enough, then it should not take much longer time than multiplying two
>> ints; but that in the case where the numbers are not small enough to
>> fit into ints, the larger factor (10-100) applies.
James Kuyper <kuyper@wizard.net> writes:
>> If that is what he means, I see no way to implement it, either in C++
>> or in assembly language. If you're right, and that is what he meant,
>> I'd like to see some evidence that it's achievable before even
>> starting to discuss whether it should be mandatory.
Hans Aberg wrote:
> One just tries to upper the performance as much as possible: If the
> factor becomes larger, the type becomes more unusable as a substitute
> for an int. (Specifically, the number of situations of where it can
> substitute an int decreases.)
>
> So just implement it as you please, dynamic memory allocation for
> large Integer's and non-dynamic int's when they are small enough. Then
> optimize to make it useful; the better optimized, the more useful it
> gets.
>
> If it is useful, it depends on the fellow using it and the
> application at hand. But at least in some applications, one cannot
> foresee when it is going to fit into an int at compile time.
>
> This is the application I have in my mind.
>
> There is this other variation, used in cryptology and the like I
> think: Then one works with fixed memory sizes, determined at compile
> time. Speed is however crucial for the usefulness of the application.
> So if there is a difference between assembler and C++ code, one wants
> to take full advantage of that.
> ...
Well, if I needed large binary integer arithmetic, I'd use 'long long
int', as long as I only needed 64 bits. While this type is a recent
addition to C (and doesn't really become standardized until some time
next year), you'll find that a lot of C++ compilers support it
already (if for no other reason than to be interfaceable with C).
OTOH, if I really were going to implement a large-integer arithmetic
class in C++ with more than 64 bits, I'd use a template class.
(I assume "integer" because it was never stated in this thread if we
were talking about fixed-point or integer numbers.) Something like
this:
template <int BITS>
class Bignum // A binary integer of 'BITS' bits
{
public:
Bignum<BITS> & operator +();
Bignum<BITS> & operator -();
Bignum<BITS> & operator +(const Bignum<BITS> &r);
Bignum<BITS> & operator -(const Bignum<BITS> &r);
Bignum<BITS> & operator *(const Bignum<BITS> &r);
Bignum<BITS> & operator /(const Bignum<BITS> &r);
Bignum<BITS> & operator %(const Bignum<BITS> &r);
...
Bignum<BITS> & operator =(const Bignum<BITS> &r);
Bignum<BITS> & operator =(
Bignum<BITS-sizeof(long)*CHAR_BITS> &r);
Bignum<BITS> & operator =(long r);
...
private:
unsigned long d[(sizeof(long)*CHAR_BIT+BITS-1)/BITS];
};
I'd use inline template member functions, and possibly some
template meta-programming, to generate efficient code for the
operators. Since each Bignum object is the exact size it needs
to be (for 'BITS' bits), I wouldn't need to bother with pointers,
dynamic memory allocation, or reference counters.
-- David R. Tribble, dtribble@technologist.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/10 Raw View
In article <v8vyarty55l.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
>My opinion, in reading your description, is that C++ is *not* the
>language you need. It's already complex enough to add more
>complications. So may I suggest you to find another language or design
>your own language ?
Your opinion is a common among those that use C++ mainly for
implementing static features and nothing else. It was also discussed a
number of times in the other threads.
In fine though, one keeps the objective of C++ being a statically typed
language, while facilitating the implementation of dynamic structures
within that framework. It will lessen the complexity for those in the need
of such features, as it will diminish the need for workarounds.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/10 Raw View
In article <35F6AB3C.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
wrote: >I made a rough estimate of how widely useful your suggestion is,
by
>considering its merits, using my own understanding of how much variety
>there is in the C++ market.
I do not claim that this suggestion should result in an inclusion in the
C++ standard, but I do suggest that it might be brought to a serious
investigation by a those that are qualified. A qualified person, in my
view, is a person which has done some serious programming with it, and
knows it cons and pros and can
describe the tradeoffs in words to others.
>I considered that estimate to be confirmed,
>by the facts that you are the only person who has asked for it so far,
>and that during the entire week we've been discussing this no one else
>has posted a message in support of your proposal.
By using your own reasoning, one might reason that you seem to be the
only person making the judgement that the feature should not be discussed
as a suggestion for the C++ standard, so in view of this lack of
opposition, it should be included. I do not suggest this, because I think
that reasoning is equally absurd, I just demonstrate the consequences of
your reasoning when turned against you. So please, skip this kind of
reasoning, it seems to not belong to this group.
>The group of people
>monitoring this newsgroup is a biased sample of the C++ community, but
>it's also a fairly large and varied one, so the absence of any support
>is pretty strong evidence against the likelihood of widespread need.
I thought a good starting point would be if those that replied started
with understanding the feature, instead of starting with saying that it
does not belong to the C++ standard in view of that they do not understand
it.
>What do you consider strange about this process?
I try to point that this kind of reasoning does not help bringing out
the facts.
>If I was worryied about whether the fraction of users that need this
>feature was between 0.45 and 0.5, this would be a very poor method.
>However, I don't need a high precision estimate to justify a conclusion
>that the fraction is probably a lot less than 0.1.
Of course, such claims should be verified by scientific means.
Otherwise, the fraction of users of General Relativity is also very
small, but this does not mean that one should not have it in physics. In
other words, the principle is that the importance of a feature depends on
how influential the feature is, and not how many that happens to use it.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/10 Raw View
In article <35F70732.E17@noSPAM.central.beasys.com>,
dtribble@technologist.com wrote:
>Well, if I needed large binary integer arithmetic, I'd use 'long long
>int', as long as I only needed 64 bits. While this type is a recent
>addition to C (and doesn't really become standardized until some time
>next year), you'll find that a lot of C++ compilers support it
>already (if for no other reason than to be interfaceable with C).
Techniques such as using 32-bit ints, putting them into a 64-bit long,
and then multpily them has already been discussed, but that does not splve
the problem: On a 32-bit-machine, int's and long's can be of the same
size. And on a 64-bit machine, one may want to multiply long's, and then
one is back to the old problem.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/10 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
HA> In article <35F6AB3C.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
HA> wrote: >I made a rough estimate of how widely useful your suggestion is,
HA> by
>> considering its merits, using my own understanding of how much variety
>> there is in the C++ market.
HA> I do not claim that this suggestion should result in an inclusion in the
HA> C++ standard, but I do suggest that it might be brought to a serious
HA> investigation by a those that are qualified. A qualified person, in my
HA> view, is a person which has done some serious programming with it, and
HA> knows it cons and pros and can
HA> describe the tradeoffs in words to others.
Are you of those qualified persons? If not, can you suggest me someone
with whom I can dig up the matter?
[...]
HA> Of course, such claims should be verified by scientific means.
Such as?
HA> Otherwise, the fraction of users of General Relativity is also very
HA> small, but this does not mean that one should not have it in physics. In
HA> other words, the principle is that the importance of a feature depends on
HA> how influential the feature is, and not how many that happens to use it.
You're comparing oranges and apples.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/10 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
[...]
HA> In fine though, one keeps the objective of C++ being a statically typed
HA> language, while facilitating the implementation of dynamic structures
HA> within that framework. It will lessen the complexity for those in the
HA> need of such features, as it will diminish the need for workarounds.
Aside from the fact that you didn't convince me, I'll be glad to see
your implementations of those extensions of Standard C++ you're
submitting.
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/10 Raw View
For those interested in a context of where the feature discuused in this
thread might be used, there is a discussion about "int" versus Integer in
the Haskell mailing list <http://haskell.org/> right now :
In GHC, the Glasgow Haskell compiler implemented in assembler, one
fellow reports that int's are about 4-5 times faster than Integer's under
similar circumstances. There is also a Haskell interpreter implemented in
C, called Hugs.
Programmers of Haskell demand that Integer should be the basic types of
libraries and such, not int's, because one is mainly doing structured
programming in such a language.
One difference between GHC, implemented in assembler, and Hugs,
implemented in C, is that the latter relatively quickly can be ported to a
number of platforms. For example, by working the code over a period of a
few months, I was able to prepare it sufficiently to make a Mac port the
same day as Hugs 1.4 was released. By contrast, a few years ago, a fellow
said he was just going to decode the RISC assembler instructions in order
to prepare GHC for a Mac port, but this work has not yet been done. So if
one is forced to revert to assembler, the number of platforms will
decrease radically.
So one would really want to be able to use C++ instead of C implementing
languages such as Haskell, avoiding as much assembler programming as
possible. One then ends up on the equation I tried to describe in this
thread.
The stuff discussed in this thread is otherwise just a tiny little
feature in a host of features needed in implementing such dynamic
features.
Also note that there is a difference between C++ being extended to
include such dynamic features and C++ being extended to support the
convenient implementation of such dynamic features. -- The scope of the
latter is much more narrow, and therefore more realistic.
However, in order to understand how C++ might be extended to support the
implemention of such dynamic features, one must also understand the
context of such dynamic features. This understanding is not always easy to
describe to those which knows little about it; often some hands on
experience is needed in order for that understanding to develop.
I could compare this with the development of STL within C++: Some out
there probably have had some difficulty of understanding it, but thanks to
my background as a mathematician I instantly recognized it as the first
small step towards more efficient programming building on abstractions.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: christian.bau@isltd.insignia.com (Christian Bau)
Date: 1998/09/10 Raw View
In article <haberg-1009981225060001@sl06.modempool.kth.se>,
haberg@REMOVE.matematik.su.se (Hans Aberg) wrote:
> In article <35F6AB3C.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
> wrote: >I made a rough estimate of how widely useful your suggestion is,
> by
> >considering its merits, using my own understanding of how much variety
> >there is in the C++ market.
>
> I do not claim that this suggestion should result in an inclusion in the
> C++ standard, but I do suggest that it might be brought to a serious
> investigation by a those that are qualified. A qualified person, in my
> view, is a person which has done some serious programming with it, and
> knows it cons and pros and can
> describe the tradeoffs in words to others.
I have read quite a lot of posts from James Kuyper and if my impression is
not completely wrong, I would say he is quite qualified to judge whether a
suggestion for the C++ standard is reasonable or unreasonable. Once a
suggestion is reasonable it may be a lot harder to decide whether
something should be part of C++ or not; there may be nonobvious side
effects of a suggestion, or one might decide that leaving a language
unchanged is more important than a minor improvement. But I dont think you
made suggestions that were reasonable to include in C++.
> >I considered that estimate to be confirmed,
> >by the facts that you are the only person who has asked for it so far,
> >and that during the entire week we've been discussing this no one else
> >has posted a message in support of your proposal.
>
> By using your own reasoning, one might reason that you seem to be the
> only person making the judgement that the feature should not be discussed
> as a suggestion for the C++ standard, so in view of this lack of
> opposition, it should be included. I do not suggest this, because I think
> that reasoning is equally absurd, I just demonstrate the consequences of
> your reasoning when turned against you. So please, skip this kind of
> reasoning, it seems to not belong to this group.
I am much more likely to respond to something that looks like a good idea.
If people dont respond it means automatically they are not interested.
> >The group of people
> >monitoring this newsgroup is a biased sample of the C++ community, but
> >it's also a fairly large and varied one, so the absence of any support
> >is pretty strong evidence against the likelihood of widespread need.
>
> I thought a good starting point would be if those that replied started
> with understanding the feature, instead of starting with saying that it
> does not belong to the C++ standard in view of that they do not understand
> it.
> >If I was worryied about whether the fraction of users that need this
> >feature was between 0.45 and 0.5, this would be a very poor method.
> >However, I don't need a high precision estimate to justify a conclusion
> >that the fraction is probably a lot less than 0.1.
>
> Of course, such claims should be verified by scientific means.
You are free to do this. This group has more a tendency of discussing
change than rejecting change in the C++ standard, even if the discussion
is more like "this would be nice, but we will never have this". As James
Kuyper is in this case "objecting to change" (with very good reason), lots
of people would have complained if he were wrong.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/10 Raw View
David R Tribble wrote:
...
> Well, if I needed large binary integer arithmetic, I'd use 'long long
> int', as long as I only needed 64 bits. While this type is a recent
> addition to C (and doesn't really become standardized until some time
> next year), you'll find that a lot of C++ compilers support it
> already (if for no other reason than to be interfaceable with C).
>
> OTOH, if I really were going to implement a large-integer arithmetic
> class in C++ with more than 64 bits, I'd use a template class.
> (I assume "integer" because it was never stated in this thread if we
> were talking about fixed-point or integer numbers.) Something like
> this:
>
> template <int BITS>
> class Bignum // A binary integer of 'BITS' bits
> {
> public:
> Bignum<BITS> & operator +();
> Bignum<BITS> & operator -();
> Bignum<BITS> & operator +(const Bignum<BITS> &r);
> Bignum<BITS> & operator -(const Bignum<BITS> &r);
> Bignum<BITS> & operator *(const Bignum<BITS> &r);
> Bignum<BITS> & operator /(const Bignum<BITS> &r);
> Bignum<BITS> & operator %(const Bignum<BITS> &r);
> ...
> Bignum<BITS> & operator =(const Bignum<BITS> &r);
> Bignum<BITS> & operator =(
> Bignum<BITS-sizeof(long)*CHAR_BITS> &r);
> Bignum<BITS> & operator =(long r);
> ...
> private:
> unsigned long d[(sizeof(long)*CHAR_BIT+BITS-1)/BITS];
> };
>
> I'd use inline template member functions, and possibly some
> template meta-programming, to generate efficient code for the
> operators. Since each Bignum object is the exact size it needs
> to be (for 'BITS' bits), I wouldn't need to bother with pointers,
> dynamic memory allocation, or reference counters.
The context for this discussion is Mr. Aberg's apparant need to work
with numbers that might be arbitrarily long, with the maximum size not
known at compile time; no fixed value for BITS would work.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/10 Raw View
Hans Aberg wrote:
>
> In article <35F6AB3C.446B@wizard.net>, James Kuyper <kuyper@wizard.net>
> wrote:
...
> I do not claim that this suggestion should result in an inclusion in the
> C++ standard, but I do suggest that it might be brought to a serious
Then why are you posting the suggestion on comp.std.c++? The charter of
this newgroup is to discuss the standard; what's in it, what should be
in it, what it means, whether a specific program or implementation
conforms to it, etc.
...
> >I considered that estimate to be confirmed,
> >by the facts that you are the only person who has asked for it so far,
> >and that during the entire week we've been discussing this no one else
> >has posted a message in support of your proposal.
>
> By using your own reasoning, one might reason that you seem to be the
> only person making the judgement that the feature should not be discussed
> as a suggestion for the C++ standard, so in view of this lack of
I never even suggested it shouldn't be discussed; I did say that it
should be rejected. If I had thought it shouldn't be discussed, I would
have sent e-mail to the moderator asking that your postings not be
accepted.
The fact that no one else has joined me in this is merely additional
evidence of lack of interest. I imagine that most people on this
newsgroup are even more sick and tired of this discussion than I am, and
have been ignoring it. I find myself incapable of ignoring it, but I
really wish I could.
...
> >The group of people
> >monitoring this newsgroup is a biased sample of the C++ community, but
> >it's also a fairly large and varied one, so the absence of any support
> >is pretty strong evidence against the likelihood of widespread need.
>
> I thought a good starting point would be if those that replied started
> with understanding the feature, instead of starting with saying that it
> does not belong to the C++ standard in view of that they do not understand
> it.
I understand your proposal perfectly. I understand exactly why it would
be useful in some contexts. I just don't believe that those contexts are
common enough to justify making it a mandatory part of the C++ language.
If you're asking for it to be anything other than a mandatory part of
the C++ language, comp.std.c++ is the wrong place to discuss it.
...
> >If I was worryied about whether the fraction of users that need this
> >feature was between 0.45 and 0.5, this would be a very poor method.
> >However, I don't need a high precision estimate to justify a conclusion
> >that the fraction is probably a lot less than 0.1.
>
> Of course, such claims should be verified by scientific means.
Why? the claim is not being used by anyone but myself, and I'm not using
it for anything that I consider important. If the issue is important to
you, you should pay the costs (both time and money) of collecting the
information needed to convince other people that you are right.
Personally, I have no idea how to obtain a more accurate estimate, and I
don't care enough to find out.
> Otherwise, the fraction of users of General Relativity is also very
> small, but this does not mean that one should not have it in physics. In
> other words, the principle is that the importance of a feature depends on
> how influential the feature is, and not how many that happens to use it.
And I'm not suggesting that you shouldn't have multiprecision numerics
in computer programming. I am suggesting that you shouldn't have it in
the C++ standard. Since physics is discovered, not designed, there is no
close analog to the standardization process. However, I would perfectly
agree that the details of General Relativity don't belong in textbooks
below the graduate level, and even then only for in textbooks devoted to
that subject. The standard texts in GR are enormous books in themselves,
and there's very little point in discussing the topic in less than full
detail.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/09/11 Raw View
In article <35F7EE9A.59E2@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
> Hans Aberg wrote:
> > By using your own reasoning, one might reason that you seem to be the
> > only person making the judgement that the feature should not be discussed
> > as a suggestion for the C++ standard, so in view of this lack of
>
> I never even suggested it shouldn't be discussed; I did say that it
> should be rejected. If I had thought it shouldn't be discussed, I would
> have sent e-mail to the moderator asking that your postings not be
> accepted.
True. A post stating that your idea should be rejected *is* discussion.
It's hard to be egoless in these discussions, but it's essential to try,
otherwise the discussion has no value.
> The fact that no one else has joined me in this is merely additional
> evidence of lack of interest. I imagine that most people on this
> newsgroup are even more sick and tired of this discussion than I am, and
> have been ignoring it. I find myself incapable of ignoring it, but I
> really wish I could.
For instance, I have not yet spoken on this thread because I had
almost no interest in the idea.
> > I thought a good starting point would be if those that replied started
> > with understanding the feature, instead of starting with saying that it
> > does not belong to the C++ standard in view of that they do not understand
> > it.
>
> I understand your proposal perfectly. I understand exactly why it would
> be useful in some contexts. I just don't believe that those contexts are
> common enough to justify making it a mandatory part of the C++ language.
> If you're asking for it to be anything other than a mandatory part of
> the C++ language, comp.std.c++ is the wrong place to discuss it.
I agree. Mr. Aberg has a particular, very exacting concept of what
a multi-precision math class should look like. Specifically, your
class is a "hybrid" of a single integral type and an array of
some integer type. Values too large for the built-in type would
use an array, which could offer infinite-precision math at the
cost of run-time performance. Your built-in integer was the only
real innovation, the idea being that values small enough to fit
in this integer wouldn't take as much of a performance hit on
calculations.
When I first read it, the idea intrigued me for a few seconds; I
always appreciate new ways of looking at a problem, and this is one
that never occured to me before. But then I began to think about the
consequences. To evaluate the expression a+b, you must handle three
cases: Both values fit into an int, both values are too large for an
int, and one of each. In order to keep any speed benefits at all, you
would have to code these seperately. Then the first case has two
sub-cases: the result fits into an int, or it does not. For math
operations that are not communitive, such as a-b, the "one of
each" case becomes two cases (which value is the small one?).
All these cases could cause code bloat, and it doesn't seem to me
that it would be very much faster than a much more simple solution.
For instance, in a more mundane infinite-precision integer scheme,
you could have each math routine check for special cases of small
integers early, otherwise handle them in the general manner.
However, I don't consider myself an expert on multiple-precision
math. Therefore, I supposed it was possible for someone to overcome
some or all of those obstacles. Rather than post observations that
I considered (and still do consider) to be fairly obvious, I waited
for someone else to explain why it was *not* obvious. However,
today I believe that if anyone had discovered a likely way to
overcome these problems, and was willing to share it, that person
would have done so by now.
Which, as many people have pointed out, is *not* a reason to avoid
creating the class in this manner. It *is* a reason not to make it
part of standard C++.
> > Otherwise, the fraction of users of General Relativity is also very
> > small, but this does not mean that one should not have it in physics. In
> > other words, the principle is that the importance of a feature depends on
> > how influential the feature is, and not how many that happens to use it.
>
> And I'm not suggesting that you shouldn't have multiprecision numerics
> in computer programming. I am suggesting that you shouldn't have it in
> the C++ standard. Since physics is discovered, not designed, there is no
> close analog to the standardization process. However, I would perfectly
> agree that the details of General Relativity don't belong in textbooks
> below the graduate level, and even then only for in textbooks devoted to
> that subject. The standard texts in GR are enormous books in themselves,
> and there's very little point in discussing the topic in less than full
> detail.
FWIW, I think that the need for large numbers, while relatively
rare, is much less rare than the need for laypeople to understand
relativity.
I believe that there should be some simple multi-precision math class
in the standard library someday. Like the string class, it would be
understood that the general-purpose class was designed for flexibility
and reasonable speed and space, rather than specific applications and
ideal speed and space. The idea here is that if a junior programmer
wants to calculate the first 10,000 digits of PI, he shouldn't have to
invent classes for simple-but-large mathematics first.
However, the "hybrid" class presented by Mr. Aberg, IMO, doesn't
fit the "General purpose" label, and therefore doesn't belong in
the standard library.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/11 Raw View
In article <v8vn28887fx.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
>Are you of those qualified persons? If not, can you suggest me someone
>with whom I can dig up the matter?
What I have in my mind is that one should do a serious investigation
with those that are implementing dynamic languages, and see what features
are needed to do that efficiently in C++.
I have suggested one list you can look at <http://haskell.org/>, but
there are many other dynamic languages, I do not even recall all their
names.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/11 Raw View
In article <v8vvhmw8aeq.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
>Aside from the fact that you didn't convince me, I'll be glad to see
>your implementations of those extensions of Standard C++ you're
>submitting.
This your statement confuses me: I program on C++ code compiling on
400000 lines. Are you suggesting me to describe how that works, despite
you have no knowledge of such techniques at all, or do you want me to
write a new C++ compiler?
I tried the former approach, but that did not seem to produce much
understanding in those that replied, despite working through several
hunderd posts.
For the latter, I plan to include dynamic verions of lex and yacc, so
writing a C++ compiler is not so interesting from that point of view.
Otherwise, I do not think I have the full knowledge in my hand to make
the determination of what might be included in the next C++ version, I
just report the features that happen to come my way.
So it surprises me that there are a lot of people posting to this list
which never have done such programming caliming that they have that
knowledge.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/11 Raw View
In article
<christian.bau-1009981427530001@christian-mac.isltd.insignia.com>,
christian.bau@isltd.insignia.com (Christian Bau) wrote:
>I have read quite a lot of posts from James Kuyper and if my impression is
>not completely wrong, I would say he is quite qualified to judge whether a
>suggestion for the C++ standard is reasonable or unreasonable.
I think that he is qualified judging that on the features of C++ dealing
with programming he has considerable experience with. But from what I
understand, he does not implement dynamic languages and such.
>.. Once a
>suggestion is reasonable it may be a lot harder to decide whether
>something should be part of C++ or not; there may be nonobvious side
>effects of a suggestion, or one might decide that leaving a language
>unchanged is more important than a minor improvement.
From what I understand this is how the development of the C++ standard
has gone so far. Fellows try to put all breaks on the features that they
do not immediately need, because they do not want to end up in a
programming group where programmers are using them.
So if a suggestion is determined to be examined in this avalanche of
uncontrolled wants, then it may snowball and it can be difficult to put on
the breaks later. So instead of that one gets peace and quiet,
systematically putting things into their proper places, the features
passed through are those surviving this frency of instant wants, resulting
in a big, unstructutred mish-mash.
If that is the problem, then it is the procedures of the C++
standardization that needs to be changed, and not turning open-minded
discussions into a long row of polemics.
> But I dont think you
>made suggestions that were reasonable to include in C++.
My guess is that you do not implement dynamic languages and such, so you
do not have any immediate use of it, do not want to learn about it, and do
not want it to be included for that reason. Right?
As I said before, the feature discussed in this thread is just a tiny
little one among many others which are used when implementing dynamic
languages and such, and this feature together with many others would be
needed to viewed together in that wider context before one can make any
judgement on the inclusion in the C++ standard.
In my personal view, those that claim otherwise, lack proper judgement
and prudence.
So in particular, if those that now so vehemently oppose the feature
discussed here would suddenly reverse opinion, saying hey, this feature
should be included, I would consider them fools, because the proper
investigation has not yet been made.
I understand this scientific method of analyzing things is not used when
introducing new features in the C++ standard. But I think it should.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/09/11 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
> From what I understand this is how the development of the C++ standard
>has gone so far. Fellows try to put all breaks on the features that they
>do not immediately need, because they do not want to end up in a
>programming group where programmers are using them.
I'd say that's quite a distored view. You can find a detailed
discussion of the process in "The Design and Evolution of C++"
by Bjarne Stroustrup. All of chapter 6 is devoted to that topic.
Briefly, it is not possible to put every feature that anyone
ever wanted, nor even every good idea, into C++ or any other
single programming language. The most common complaint about
C++ is that it is too complex, has too many features, should be
reduced in size, and oh by the way, please add these 3 features
that I cannot do without.
C++ is intended to be a general-purpose programming language,
and does not pretend to be the best language, or even a good
language, for every programming purpose.
Stroustrup's early criterion, and the criterion later adopted by
the C++ committee, was that to be adopted, a feature should
solve a general programming problem of wide applicability for
which there was no good workaround already. That's the plan,
at least. (An exception is something so commonly needed that
a standard library function is provided so as to have a standard
idiom.)
Getting out a standard is a political as well as a technical
process. You can certainly find features that are too specialized,
or important general features that are missing. Of course, you won't
get wide agreement on which features fall into those categories,
which is kind of my point. :-)
In particular, missing features often reflect lack of participation
in the committee work by people who would want the feature and
understand it well enough to write good specifications.
If no usable proposal is presented to the committee, the feature
isn't going to appear in the standard. Stroustup in D&E describes
what I mean by "usable proposal", and it means a lot of hard work.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/11 Raw View
In article <6t9vog$q5n$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com wrote:
>I agree. Mr. Aberg has a particular, very exacting concept of what
>a multi-precision math class should look like. Specifically, your
>class is a "hybrid" of a single integral type and an array of
>some integer type. Values too large for the built-in type would
>use an array, which could offer infinite-precision math at the
>cost of run-time performance.
Please note that I have not specified how the implementation of such
features should be supported in C++:
One way to go would be to review how C++ could better support the things
that can be done at an assembler level (giving access to overflows and the
like). Another way to go could be to doing a numerics library like the C
string functions, which are static, but which can be used to build dynamic
types. And on an even higher level, one could have some kind of dynamic
Integer and other high precision numerics types.
> But then I began to think about the
>consequences. To evaluate the expression a+b, you must handle three
>cases: Both values fit into an int, both values are too large for an
>int, and one of each. In order to keep any speed benefits at all, you
>would have to code these seperately.
So this is a penalty one must be aware of. Therefore, when Integer's are
available (as in Haskell), these are used in non-critical situations, but
one retain int's for use when needed. I think the overhead caused by
deciding those cases could be lessened by CPU hardware developments which
are not too dramatic, so if that happens in the future, the need for using
int's would decrease even further.
>Which, as many people have pointed out, is *not* a reason to avoid
>creating the class in this manner. It *is* a reason not to make it
>part of standard C++.
Since there are different ways of implementing a class Integer, one may
decide to not do it. But it would be good to have full access to the
things that one can do on the assembler level.
>FWIW, I think that the need for large numbers, while relatively
>rare, is much less rare than the need for laypeople to understand
>relativity.
Sorry, I do't know what "FWIW" means. One can note that the
philosophical aspects of General Relativity has influenced the thinking of
our culture tremendously.
>I believe that there should be some simple multi-precision math class
>in the standard library someday. Like the string class, it would be
>understood that the general-purpose class was designed for flexibility
>and reasonable speed and space, rather than specific applications and
>ideal speed and space. The idea here is that if a junior programmer
>wants to calculate the first 10,000 digits of PI, he shouldn't have to
>invent classes for simple-but-large mathematics first.
Precisely, the development of the string library parallels the
development of high precision numerics. I think a similar thing will
happen with other dynamic features, people are just now so tired after the
new C++ standard has been passed so they do not want to see another row of
mish-mash features added to the next C++ version. I do not think myself
that would be prudent: One needs consolidate the current C++ standard in
order to get stable, complying C++ compilers. Then new features must be
added in a much more structured way and to fill out holes and gaps.
>However, the "hybrid" class presented by Mr. Aberg, IMO, doesn't
>fit the "General purpose" label, and therefore doesn't belong in
>the standard library.
If it is the hybrid part you are objecting to, it is just a standard way
to speed up a class. A technicality, simply. One can do it for strings and
other classes too. The thing is that a dynamic memory allocation in C++
can take (some say) 50-100 memory cycles, so if one can avoid that, one
may speed it up a little. But if a compiler has faster dynamic memory
allocation, the need for hybrids lessens.
So let's hypothesize that one day has a class Integer in the C++
standard library. Then that standard is likely to say nothing about the
implementation of it, only define its interface and properties. So whether
it is a hybrid or not will be decided by the fellow implementing it.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/08 Raw View
Hans Aberg wrote:
>
> In article <35F32FBC.15FB@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
...
> In this quibbling over words, a standard is just the flag put on the
> rallying place, and the standard is de-facto when one does not even need
> to put up the flag because people already knows where the rallying place
> is, this is what I meant.
Then by that definition, there has never been a complete internally
consistent de-facto standard for C++. Some people (implementors and
people concerned with writing portable code) need a standard which is
both complete and internally consistent; a de-facto standard will never
qualify.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/08 Raw View
Francis Glassborow wrote:
>
> In article <35F3322F.59E2@wizard.net>, James Kuyper <kuyper@wizard.net>
> writes
>
> >Most
> >assembly languages give you direct access to hardware features that are
> >not directly accessible in C++, and may not even be accessible through
> >operating system calls. I assumed that when you wrote "not in current
> >C++", you meant it; this required me to assume that you were under the
> >misapprehension that multiprecision integers required some such feature
> >of assembly language.
>
> I am puzzled, how can anything be accessible at assembler level and not
> in C++? I know that few programmers ever use asm but it is a keyword of
> C++ :)
There are two ways to answer this; one is to say that asm() is a way of
going into assembler from C++; the argument of asm() isn't C++ code, it
is just a string literal as far as C++ is concerned. The second is to
say that I was talking about portable C++, which would prohibit the use
of asm(), since the interpretation of the contents is
implmentation-defined. Aberg wants a portable solution, and he's asking
the committee to make it portable by making it part of the standard.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <6QIbIVASmD91Ewyh@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>..Concensus does not mean all in this context but
>a substantial majority.
So that's what I tried to point out: One should note use the word
consensus here, but accepting that it is merely a vote according to the
internal rules of the decision making body.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/08 Raw View
Fergus Henderson wrote:
> James Kuyper <kuyper@wizard.net> writes:
> >Hans Aberg wrote:
> >> I think that when working with dynamic features, the goal is to make
> >> them only 10-100 (instead of 1000 to 10000) times slower than highly
> >> optimized C++ code.
> >Let me verify that I understand this: When you said:
> >| multiplication. In addition, all checks must be done efficiently so that
> >| it does not take much longer time than multiplying two int's.
> >
> >what you meant was "it should not take more than 100 times longer than
> >multiplying two ints"?
> Perhaps Hans Aberg means that if the numbers involved are small enough,
> then it should not take much longer time than multiplying two ints;
> but that in the case where the numbers are not small enough to fit
> into ints, the larger factor (10-100) applies.
If that is what he means, I see no way to implement it, either in C++ or
in assembly language. If you're right, and that is what he meant, I'd
like to see some evidence that it's achievable before even starting to
discuss whether it should be mandatory.
> >The results I got on our SGI machine with two 200MH IP 19 processors
> >under IRIX 6.2 were:
> >
> > Factor:32768
> > Ordinary int:0.76 seconds
> > Multiprecision:5.2 seconds
> >
> >This gives a slow-down factor of 6.8; much better even than the low end
> >of 10-100 range you gave me.
> Yes, but your test is testing the easy case where the numbers involved
> are all small.
That's the only case where Aberg established performance criteria.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <35F54C74.3F54@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
Fergus Henderson wrote:
> Perhaps Hans Aberg means that if the numbers involved are small enough,
> then it should not take much longer time than multiplying two ints;
> but that in the case where the numbers are not small enough to fit
> into ints, the larger factor (10-100) applies.
> James Kuyper <kuyper@wizard.net> writes:
>If that is what he means, I see no way to implement it, either in C++ or
>in assembly language. If you're right, and that is what he meant, I'd
>like to see some evidence that it's achievable before even starting to
>discuss whether it should be mandatory.
One just tries to upper the performance as much as possible: If the
factor becomes larger, the type becomes more unusable as a substitute for
an int. (Specifically, the number of situations of where it can substitute
an int decreases.)
So just implement it as you please, dynamic memory allocation for large
Integer's and non-dynamic int's when they are small enough. Then optimize
to make it useful; the better optimized, the more useful it gets.
If it is useful, it depends on the fellow using it and the application
at hand. But at least in some applications, one cannot foresee when it is
going to fit into an int at compile time.
This is the application I have in my mind.
There is this other variation, used in cryptology and the like I think:
Then one works with fixed memory sizes, determined at compile time. Speed
is however crucial for the usefulness of the application. So if there is a
difference between assembler and C++ code, one wants to take full
advantage of that.
The criterion of portability could mean that it should work without too
much changes on a certain class of machines, say 32-bit computers.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <35F54A18.1CFB@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>The final, and key, issue is whether the need for this feature is
>sufficiently widespread to justify mandating that implementors do the
>work, rather than leaving it to third-party library vendors, or even to
>the individual developers themselves.
Or rather, sufficiently influential, especially in the long run.
>It seems extremely unlikely to me
>that the need is widespread, given that you seem to be the only person
>asking for it.
Strange way of drawing conclusions.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <v8v3ea2bn2w.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@DPTMaths.ens-cachan.fr> wrote:
>Well, I happen to be one of those who are *trying* to communicate with
>you. I've got free hours to spend: could you, please, explain me
>again that kind of standard dynamic programming you are doing with
>realistic examples? Please explain also how that kind of programming is
>related to C++ and why Standard C++ failed to fit your needs.
There already were a couple of really, really long threads in this group
in which I tried to explain that, so for that reason I am not sure I have
the effort to explain that once more.
But typically one has a generic variable handing over references to a
class hierarchy, in which the objects have the ability to self-mutate to
an object of another type. This is real simple until one starts trying to
do optimizations, in which case C++ fails miserably: One would want to use
GC instead of reference counts for handling over the references, small
elements might be put into the handles instead of the big hierarchy and so
on.
Then one discovers, by experience, that C++ does not have the stuff to
do that conveniently.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/09 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
HA> In article <v8v3ea2bn2w.fsf@cor.dptmaths.ens-cachan.fr>, Gabriel Dos Reis
HA> <dosreis@DPTMaths.ens-cachan.fr> wrote:
>> Well, I happen to be one of those who are *trying* to communicate with
>> you. I've got free hours to spend: could you, please, explain me
>> again that kind of standard dynamic programming you are doing with
>> realistic examples? Please explain also how that kind of programming is
>> related to C++ and why Standard C++ failed to fit your needs.
HA> There already were a couple of really, really long threads in this group
HA> in which I tried to explain that, so for that reason I am not sure I have
HA> the effort to explain that once more.
Fair enough.
HA> But typically one has a generic variable handing over references to a
HA> class hierarchy, in which the objects have the ability to self-mutate to
HA> an object of another type. This is real simple until one starts trying to
HA> do optimizations, in which case C++ fails miserably: One would want to use
HA> GC instead of reference counts for handling over the references, small
HA> elements might be put into the handles instead of the big hierarchy and so
HA> on.
HA> Then one discovers, by experience, that C++ does not have the stuff to
HA> do that conveniently.
My opinion, in reading your description, is that C++ is *not* the
language you need. It's already complex enough to add more
complications. So may I suggest you to find another language or design
your own language ?
--
Gabriel Dos Reis | Centre de Math=E9matiques et de
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/09 Raw View
Hans Aberg wrote:
>
> In article <35F54A18.1CFB@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
...
> >It seems extremely unlikely to me
> >that the need is widespread, given that you seem to be the only person
> >asking for it.
>
> Strange way of drawing conclusions.
I made a rough estimate of how widely useful your suggestion is, by
considering its merits, using my own understanding of how much variety
there is in the C++ market. I considered that estimate to be confirmed,
by the facts that you are the only person who has asked for it so far,
and that during the entire week we've been discussing this no one else
has posted a message in support of your proposal. The group of people
monitoring this newsgroup is a biased sample of the C++ community, but
it's also a fairly large and varied one, so the absence of any support
is pretty strong evidence against the likelihood of widespread need.
What do you consider strange about this process?
If I was worryied about whether the fraction of users that need this
feature was between 0.45 and 0.5, this would be a very poor method.
However, I don't need a high precision estimate to justify a conclusion
that the fraction is probably a lot less than 0.1.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/06 Raw View
In article <haberg-0609981203440001@sl49.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> Well, if there is already a concensus, one has a so called de facto
>standard, and it is no point in writing it down, as everybody already
>knows about it.
A concensus between experts may not be known to everyone else and needs
documenting to enable trade (one of the primary purposes of an ISO
standard)
>
> In creating a standard, one does not write down a concensus, but
>attempts to reach a concensus by negotiation, and then hopefully writes
>down that negotiated concensus, that is, unless there are some strong
>individuals writing down their own views, pretending it is a concensus.
The standard documents the concensus, the process of producing a
standard includes any necessary reaching of concensus. My apologies if
that seems like hair splitting.
--
Francis Glassborow
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/07 Raw View
Hans Aberg wrote:
>
> In article <35EEC227.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >> I think that James Kuyper interprets the wording "not adding too much
> >> overhead" in ways like "exactly as fast as an int" and the like, but that
> >
> >No. Ordinarily I'd interpret it to mean something like "less than 1.5
> >times as long as integer operations". You've not been specific, and for
> >your benefit I've tried to interpret it as meaning "less than 2.0 times
> >as long as integer operations".
>
> I think that when working with dynamic features, the goal is to make
> them only 10-100 (instead of 1000 to 10000) times slower than highly
> optimized C++ code.
Let me verify that I understand this: When you said:
| multiplication. In addition, all checks must be done efficiently so
that
| it does not take much longer time than multiplying two int's.
what you meant was "it should not take more than 100 times longer than
multiplying two ints"?
That is a rather unusual definition of "not take much longer". I'd love
to be able to tell our client that our project will "not cost much more
than budgeted" and will "not take much longer than scheduled", using
your definition. The disadvantage of course is things like politicians
who will promise that my taxes will "not be much greater" than they are
now.
In any event, if <100 times slower is your standard, it's easily met by
a C++ user-defined type. The following code implements unsigned
multiprecision integers. It only implements the multiplication operator;
the others are left as excersize for the reader. The division operator
will be somewhat more complicated, the addition and subtraction
operators are somewhat simpler. Note also that the full multi-precision
code is left out, since we were specifically discussing the case where
the numbers are so small that it won't get executed.
I implemented unsigned rather than signed multiprecision integers,
because they're simpler, and I can't justify spending the extra time to
cope with the extra issues of the signed types. I don't expect the added
complexity to add significantly to execution time.
This code was developed quick and dirty; it has been compiled, minimally
tested(I printed the values in mout), and executed; it may still have
bugs, and I'm sure it can be improved, but it basically works.
========================================================================
#include <cstddef>
#include <climits>
#include <cstring>
#include <cstdio>
#include <ctime>
// Calculates at compile time the smallest power of 2 greater than the
// square root of its template argument.
template <unsigned long N> class sqrt_power2{
public:
enum { n = N<4 ? 1 : 2*sqrt_power2<N/4>::n};
};
class sqrt_power2<0> {
public:
enum {n = 1};
};
struct multiprecision
{
private:
enum{ factor = sqrt_power2<UINT_MAX>::n, mask=factor-1};
unsigned long i;
unsigned long * pi;
// If pi!=NULL, then i is the the number of elements in pi[]. The value
// represented by those elements is conceptually represented by the
// following code:
//
// infinite_capacity_int sum=pi[0];
// for(int j=1; j<i; j++)
// sum = sum*factor*factor+pi[j];
//
// If pi==NULL, i represents the value. This allows small integers to
// be handled without the overhead costs of dynamic allocation.
public:
multiprecision(unsigned long newi=0) : i(newi), pi(0) {}
operator unsigned long() const { return pi==NULL ? i : pi[i-1];}
~multiprecision() { if(pi!=NULL) delete[] pi; }
multiprecision& operator=(const multiprecision& other)
{
if(&other != this)
{
if(pi!=NULL)
delete[] pi;
i = other.i;
if(other.pi!=NULL)
{
pi = new unsigned long[i];
memcpy(pi, other.pi, i*sizeof(pi[0]));
}
else
pi = NULL;
}
return *this;
}
multiprecision operator*(const multiprecision& other) const
{
multiprecision temp;
if(pi==NULL && other.pi==NULL)
{
unsigned long a = i/factor;
unsigned long b = i&mask;
unsigned long c = other.i/factor;
unsigned long d = other.i&mask;
unsigned long e = b*d;
unsigned long f = b*c+e/factor;
unsigned long g = a*d;
unsigned long h = a*c + f/factor + g/factor;
temp.i = e&mask + ((f+g)&mask)*factor;
if(h!=0)
{
temp.pi = new unsigned long[2];
temp.pi[1] = temp.i;
temp.pi[0] = h;
temp.i = 2;
}
}
else
printf("This is where the full multiprecision would go.");
return temp;
}
// Many other operators.
};
int main(void)
{
printf("Factor:%lu\n", sqrt_power2<UINT_MAX>::n);
multiprecision mfact[256];
multiprecision mout[256];
int ifact[256];
int iout[256];
for(int i=0; i<256; i++)
{
mfact[i]=i;
ifact[i]=i;
}
clock_t loop_start=clock();
for(int j=0; j<10000; j++)
{
for(int i=0; i<256; i++)
iout[i] = ifact[i]*ifact[i];
}
clock_t loop_end=clock();
printf("Ordinary int:%g seconds\n",
double(loop_end - loop_start)/double(CLOCKS_PER_SEC));
loop_start = clock();
for(int j=0; j<10000; j++)
{
for(int i=0; i<256; i++)
mout[i] = mfact[i]*mfact[i];
}
loop_end=clock();
printf("Multiprecision:%g seconds\n",
double(loop_end - loop_start)/double(CLOCKS_PER_SEC));
return 0;
}
========================================================================
The results I got on our SGI machine with two 200MH IP 19 processors
under IRIX 6.2 were:
Factor:32768
Ordinary int:0.76 seconds
Multiprecision:5.2 seconds
This gives a slow-down factor of 6.8; much better even than the low end
of 10-100 range you gave me.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/07 Raw View
Hans Aberg wrote:
>
> In article <zic5EQAEuR81EwYj@robinton.demon.co.uk>, Francis Glassborow
> <francis@robinton.demon.co.uk> wrote:
>
> >In article <haberg-0509980035010001@sl11.modempool.kth.se>, Hans Aberg
> ><haberg@matematik.su.se> writes
> >> I thought standards were created because people did not like the
> >>language as it is -- after all if the language already is agreed upon by
> >>everybody to as what it should be, there would be no need for creating a
> >>standard.
> >
> >No. he purpose of a standard is to document the conscensus of what the
> >language is.
>
> Well, if there is already a concensus, one has a so called de facto
> standard, and it is no point in writing it down, as everybody already
> knows about it.
When the standard is de-facto, many people don't know exactly what that
standard is, and nobody can enforce compliance (as a condition in a
contract, for instance). Only when it is de-jure does it become well
known and enforceable - that's the point of writing it down. Also,
de-facto computer standards have a tendency to become increasingly
internally inconsistent, a fact that can be fixed using the authority
that creates the de-jure standard.
> In creating a standard, one does not write down a concensus, but
> attempts to reach a concensus by negotiation, and then hopefully writes
> down that negotiated concensus, that is, unless there are some strong
> individuals writing down their own views, pretending it is a concensus.
Yes, but the charter of the committee does not call for creating
significant new features. The negotiation that does occur is about
different ways of implementing the same or similar features, which have
already been implemented differently as extensions to at least two
different implementations. The iostream library, for instance, was a
compromise between many different ways of implementing <iostream.h>. I
gather that the final result is not completely backwards compatible with
any pre-existing implementation of <iostream.h>. That's one reason why
it's a good thing that <iostream> uses a different header name.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/07 Raw View
Hans Aberg wrote:
>
> In article <35F03C92.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>
> >Hans Aberg wrote:
> ..
> >Yes you did. In a previous ... you wrote:
> >>> I think you have misunderstood the question: One can create such
> >>> constructs by writing them in assembler, but not in current C++.
>
> From the generalistic point of view, sufficiently general computer
> languages simulate approximations of Turing machines, and the latter are
> equivalent in the sense that what can computed on one of them can also be
> computer on the others. So, therefore one will always expect what is
> logically possible within one such computer language will also be
> logically possible in another.
As a practical matter, rather than a theoretical one, different computer
languages have different and non-overlapping capabilities, even if they
are theoretically (in the infinite memory limit) Turing-complete. Most
assembly languages give you direct access to hardware features that are
not directly accessible in C++, and may not even be accessible through
operating system calls. I assumed that when you wrote "not in current
C++", you meant it; this required me to assume that you were under the
misapprehension that multiprecision integers required some such feature
of assembly language.
> > you wrote:
> >>> multiplication. In addition, all checks must be done efficiently so that
> >>> it does not take much longer time than multiplying two int's.
>
> The equivalence of Turing machines does not preserve the other semantic
> structure one wants describe, so the translation does not result in
> efficient implementations.
>
> So when, by abuse of language, one speaks about "possible" and
> "efficient" that always refer to a pragmatic computer context.
If you meant "cannot be implemented efficiently in current C++", why
didn't you say so? What you actually said has much stronger
implications.
On the issue of whether they can be implemented efficiently enough, see
my posting earlier today, on a different branch of this discussion tree.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/07 Raw View
In article <wfqprNAcqs81EwK6@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>A concensus between experts may not be known to everyone else and needs
>documenting to enable trade (one of the primary purposes of an ISO
>standard)
So? Then the next step is probably to reach a concensus of some kind
among the people supposed to use that formal standard the experts created,
so that it can be a standard also among them.
>The standard documents the concensus, the process of producing a
>standard includes any necessary reaching of concensus. My apologies if
>that seems like hair splitting.
So you are saying that the experts have a veto here, that the ISO
standard cannot be created if some experts disagree. I did not know this.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <35F3322F.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>If you meant "cannot be implemented efficiently in current C++", why
>didn't you say so? What you actually said has much stronger
>implications.
I just sit here, and came to the point where implementing such an
Integer type would be suitable. Normally I have discussions with people
knowing about this context, and it becomes complicated carrying out
discussions with those who do not.
That's how all discussion go: In mathematics, one has even a concept,
introduced by Bourbaki, called "abuse of language", which means that one
does linguistic simplifications which are formally incorrect, but are
needed in order to carry out the discussions conveniently.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/08 Raw View
In article <35F3322F.59E2@wizard.net>, James Kuyper <kuyper@wizard.net>
writes
>Most
>assembly languages give you direct access to hardware features that are
>not directly accessible in C++, and may not even be accessible through
>operating system calls. I assumed that when you wrote "not in current
>C++", you meant it; this required me to assume that you were under the
>misapprehension that multiprecision integers required some such feature
>of assembly language.
I am puzzled, how can anything be accessible at assembler level and not
in C++? I know that few programmers ever use asm but it is a keyword of
C++ :)
--
Francis Glassborow
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <35F329DB.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>what you meant was "it should not take more than 100 times longer than
>multiplying two ints"?
I think I defined the context clearly: One wants a multiprecision
Integer type of which one knows that most of the time it will fit into
int, but there is no compile time method to determine when. Within that
context, it should be as efficient as possible. How this works out in
practise depends on platform, how the type is used, and such things. Pro
implementers should probably do profiling with some good target programs.
>In any event, if <100 times slower is your standard, it's easily met by
>a C++ user-defined type.
I think that a dynamic memory allocation alone can take 50-100 cycles.
Did you fit that into your picture? It becomes complicated when the
Integers have different length.
>I implemented unsigned rather than signed multiprecision integers,
>because they're simpler, and I can't justify spending the extra time to
>cope with the extra issues of the signed types.
I think that signed addition is simpler than unsigned addition and
unsigned multiplication simpler than signded multiplication.
>The following code implements unsigned
>multiprecision integers. It only implements the multiplication operator;
>the others are left as excersize for the reader.
So the tricky thing is to make them work together, as addition is
simpler for signed operations and multplication simpler for unsigned:
Should one allow oneself doing the extra copying for translations between
signed/unsigned?
> Note also that the full multi-precision
>code is left out, since we were specifically discussing the case where
>the numbers are so small that it won't get executed.
This is otherwise the tricky part.
>I don't expect the added
>complexity to add significantly to execution time.
Except for extra copying and dynamic memory allocations and such.
>// Calculates at compile time the smallest power of 2 greater than the
>// square root of its template argument.
>template <unsigned long N> class sqrt_power2{
>public:
> enum { n = N<4 ? 1 : 2*sqrt_power2<N/4>::n};
>};
...
>========================================================================
>The results I got on our SGI machine with two 200MH IP 19 processors
>under IRIX 6.2 were:
>
> Factor:32768
> Ordinary int:0.76 seconds
> Multiprecision:5.2 seconds
>
>This gives a slow-down factor of 6.8; much better even than the low end
>of 10-100 range you gave me.
The higher range comes into play when using dynamic memory allocation,
which one wants to avoid.
So what's the factor when using assembler?
If the factor can be improved only 2-3 times by using assembler, then
one has, by your calculation, and Integer that for most of the time will
substitute well for an int.
So it seems that you have proven the use of adding such an Integer type
to the C++ standard: For the most of the time, one can use the type
Integer, and then go in and optimize in the places where one knows int's
will suffice and speed is crucial.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <35F32FBC.15FB@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>When the standard is de-facto, many people don't know exactly what that
>standard is,
In this quibbling over words, a standard is just the flag put on the
rallying place, and the standard is de-facto when one does not even need
to put up the flag because people already knows where the rallying place
is, this is what I meant.
>and nobody can enforce compliance (as a condition in a
>contract, for instance). Only when it is de-jure does it become well
>known and enforceable - that's the point of writing it down.
So I make a distinction between formal standards and standards in the
general sense as a convention that people somehow do klnow about.
I do this distinction in order to bring out the political reality: It
does not suffice to have a formal standard (like those issued by ISO), if
it does not in some way correspond to the views of the people of what that
standard should be in an informal sense.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/08 Raw View
In article <haberg-0709981215470001@sl02.modempool.kth.se>, Hans Aberg
<haberg@REMOVE.matematik.su.se> writes
> So you are saying that the experts have a veto here, that the ISO
>standard cannot be created if some experts disagree. I did not know this.
Well not quite, because those that have the final vote are national
bodies however most of these must vote yes for an IS to come into
existence. However, in practice if more than a third of the experts
present at a meeting vote against a proposal it will not go into the
relevant working paper (only a simple majority is strictly required at
that level but we would scarcely ever think that was actually enough)
which eventually wends its way through tiers of votes till the NB's get
to vote on a Draft IS. Concensus does not mean all in this context but
a substantial majority.
--
Francis Glassborow
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/08 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
[...]
HA> That's how all discussion go: In mathematics, one has even a concep=
t,
HA> introduced by Bourbaki, called "abuse of language", which means that =
one
HA> does linguistic simplifications which are formally incorrect, but are
HA> needed in order to carry out the discussions conveniently.
Well, Boubaki and his Mathematics have little to do with this
thread -- sci.maths is more appropriate to troll on Bourbaki and
al.=20
A question related to your assertion: if there is an "abuse of
language" isn't it that not only the "linguistic simplifications are
formally incorrect" but there is also an indescriptible confusion in
the discussions ?=20
--=20
Gabriel Dos Reis | Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/08 Raw View
I sent out a message early today which has not yet shown up on the
newsgroup, even though later messages have already shown up. I'm
re-sending it, and taking advantage of this opportunity to fix some
defects in the previous version.
Hans Aberg wrote:
>
> In article <35EEC227.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >> I think that James Kuyper interprets the wording "not adding too much
> >> overhead" in ways like "exactly as fast as an int" and the like, but that
> >
> >No. Ordinarily I'd interpret it to mean something like "less than 1.5
> >times as long as integer operations". You've not been specific, and for
> >your benefit I've tried to interpret it as meaning "less than 2.0 times
> >as long as integer operations".
>
> I think that when working with dynamic features, the goal is to make
> them only 10-100 (instead of 1000 to 10000) times slower than highly
> optimized C++ code.
Let me get this straight; when you said, in an earlier message, that
> ... In addition, all checks must be done efficiently so that
> it does not take much longer time than multiplying two int's.
what you meant was:
"does not take more than 100 times as long as multiplying two
int's"
?
I think I'll tell NASA that our project will "not take much longer" than
scheduled. They'll appreciate my use of your definition, I'm sure.
Now, if that is your criterion, it's easily met. Here's an
implementation based upon your suggestion of the half-integer method of
implementing it. It may have bugs, and I'm sure it can be improved, but
it compiles, passes the minimal testing I gave it, and executes
reasonably.
I only implemented unsigned multiprecision integers. There are some
messy portability issues with signed integers that I wanted to avoid,
and I doubt that the solution to those issues would significantly
increase the execution time.
I only implemented the multiplication operator. The other operators are
left as an excersize. The division operator should be a little more
complicated, the addition and subtraction ones should be a bit simpler.
I didn't implement the full multiprecision code; only the part that gets
executed for small integers, since your criterion was only applicable to
small integers. However, the overhead for small integers that the rest
of the code would impose is represented.
========================================================================
#include <cstddef>
#include <climits>
#include <cstring>
#include <cstdio>
#include <ctime>
// Compile time function of unsigned long:
template <unsigned long N> class comp_func{
public:
enum {
// smallest integral power of 2 greater than sqrt(N):
sqrt_power2 = N<4 ? 1 : 2*comp_func<N/4>::sqrt_power2
};
};
class comp_func<0> {
public:
enum {sqrt_power2 = 1};
};
// problem: the recommended minimum value for maximum template
// instantiation depth is only 17, not enough to evaluate sqrt_power2
// for 64 bit integers.
// Add the following specialization to reduce the recursion depth:
#if ULONG_MAX/65536U > 65535U
class comp_func<4294967295U>
{
public:
enum {sqrt_power2=65536U};
};
#endif
struct multiprecision
{
private:
enum{ factor = comp_func<ULONG_MAX>::sqrt_power2,
mask=factor-1};
unsigned long ulnum;
unsigned long *pl;
// If pl!=NULL, then ulnum is the the number of elements in
// pl[]. The value represented by those elements is conceptually
// represented by the following code:
//
// infinite_capacity_int sum=pl[0];
// for(unsigned long i=1; i<ulnum; ulnum++)
// sum = sum*factor*factor+pl[i];
//
// If pl==NULL, ulnum represents the value. This allows small
// integers to be handled without the overhead costs of dynamic
// allocation.
// This assumes that UINT_MAX is less than the square of
// 'factor'; that will be true only if UINT_MAX is 1 less than a
// power of 4. This is the case for every implementation I know
// of, but isn't required by the standard. I'm working on a
// method for removing that assumption.
public:
multiprecision(unsigned long newl=0) : ulnum(newl), pl(0) {}
operator unsigned long() const {
return pl==NULL ? ulnum : pl[ulnum-1];
}
~multiprecision() { if(pl!=NULL) delete[] pl; }
multiprecision& operator=(const multiprecision& other)
{
if(&other != this)
{
if(pl!=NULL)
delete[] pl;
ulnum = other.ulnum;
if(other.pl!=NULL)
{
pl = new unsigned long[ulnum];
memcpy(pl, other.pl, ulnum*sizeof(pl[0]));
}
else
pl = NULL;
}
return *this;
}
multiprecision operator*(const multiprecision& other) const
{
multiprecision temp;
if(pl==NULL && other.pl==NULL)
{
unsigned long a = ulnum/factor;
unsigned long b = ulnum&mask;
unsigned long c = other.ulnum/factor;
unsigned long d = other.ulnum&mask;
unsigned long e = b*d;
unsigned long f = b*c+e/factor;
unsigned long g = a*d; // maximum: mask*mask
unsigned long h = a*c + f/factor + g/factor;
temp.ulnum = e&mask + ((f+g)&mask)*factor;
if(h!=0)
{
temp.pl = new unsigned long[2];
temp.pl[1] = temp.ulnum;
temp.pl[0] = h;
temp.ulnum = 2;
}
}
else
printf("Full multiprecision code would go here.");
return temp;
}
// Many other operators.
};
int main(void)
{
const unsigned long num=262144/sizeof(multiprecision);
const int reps=256;
printf("Factor:%lu\n", comp_func<UINT_MAX>::sqrt_power2);
multiprecision mfact[num];
multiprecision mout[num];
unsigned long lfact[num];
unsigned long lout[num];
for(unsigned long i=0; i<num; i++)
{
mfact[i]=i;
lfact[i]=i;
}
clock_t loop_start=clock();
for(int i=0; i<reps; i++)
{
for(unsigned long j=0; j<num; j++)
lout[j] = lfact[j]*lfact[j];
}
clock_t loop_end=clock();
printf("Ordinary int:%g seconds\n",
double(loop_end - loop_start)/double(CLOCKS_PER_SEC));
loop_start = clock();
for(int i=0; i<reps; i++)
{
for(unsigned long j=0; j<num; j++)
mout[j] = mfact[j]*mfact[j];
}
loop_end=clock();
printf("Multiprecision:%g seconds\n",
double(loop_end - loop_start)/double(CLOCKS_PER_SEC));
return 0;
}
========================================================================
Results from a run on an SGI machine with 2 200 MHz IP 19 CPU's, under
IRIX 6.2:
Factor:32768
Ordinary int:4.26 seconds
Multiprecision:19.48 seconds
This gives a slow-down factor of only 4.57, well under your 10-100
criterion.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <v8vvhmzktdh.fsf@cloche.dptmaths.ens-cachan.fr>, Gabriel Dos
Reis <dosreis@DPTMaths.ens-cachan.fr> wrote:
>Well, Boubaki and his Mathematics have little to do with this
>thread -- sci.maths is more appropriate to troll on Bourbaki and
>al.=20
Well, I brought it up in a way appropriate for the discussions in this
thread, namely pointing out that discussions between humans rely on a
context which is not explicitly stated in every wording.
Or are you claiming that Bourbaki cannot be mentioned in this thread
because there happens to be some math newsgroups available?
>A question related to your assertion: if there is an "abuse of
>language" isn't it that not only the "linguistic simplifications are
>formally incorrect" but there is also an indescriptible confusion in
>the discussions ?=20
Yes, this it is, because I have repeatedly tried to define the context
of the feature I speak about, which defines its wished-for qualities, but
that context is somehow lost by those that reply.
This confusion of language also appeared in some other threads that I
posted, and (from my view-point) it seems to have to do with that those
replying do not know about the kind of dynamic programming I am doing
(which I think otherwise is rather standard), and are imposing condtions
form the static programming they are used to.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: fjh@cs.mu.OZ.AU (Fergus Henderson)
Date: 1998/09/08 Raw View
James Kuyper <kuyper@wizard.net> writes:
>Hans Aberg wrote:
>>
>> I think that when working with dynamic features, the goal is to make
>> them only 10-100 (instead of 1000 to 10000) times slower than highly
>> optimized C++ code.
>
>Let me verify that I understand this: When you said:
>
>| multiplication. In addition, all checks must be done efficiently so that
>| it does not take much longer time than multiplying two int's.
>
>what you meant was "it should not take more than 100 times longer than
>multiplying two ints"?
Perhaps Hans Aberg means that if the numbers involved are small enough,
then it should not take much longer time than multiplying two ints;
but that in the case where the numbers are not small enough to fit
into ints, the larger factor (10-100) applies.
>The results I got on our SGI machine with two 200MH IP 19 processors
>under IRIX 6.2 were:
>
> Factor:32768
> Ordinary int:0.76 seconds
> Multiprecision:5.2 seconds
>
>This gives a slow-down factor of 6.8; much better even than the low end
>of 10-100 range you gave me.
Yes, but your test is testing the easy case where the numbers involved
are all small.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/08 Raw View
In article <6t3b64$au2$1@mulga.cs.mu.OZ.AU>, fjh@cs.mu.OZ.AU (Fergus
Henderson) wrote:
>Perhaps Hans Aberg means that if the numbers involved are small enough,
>then it should not take much longer time than multiplying two ints;
>but that in the case where the numbers are not small enough to fit
>into ints, the larger factor (10-100) applies.
Yes, because when they are larger, one must use dynamic memory
allocation, which is slow. By avoiding dynamic memory allocation for small
numbers, which is the more frequent case, one can get the lower factor.
The choice between the small (non-dynamic allocation) and large (dynamic
allocation) case must happen at runtime.
This is the situation I have in my mind. I think that others in the need
of high precision numerics may have other requirements.
In addition, by using modern GC (garbage collecting) techniques, dynamic
memory allocation can be speeded up considerably. Then it starts to become
interesting to have high speed routines for long multiprecision numbers
too.
So if C++ is augmented with features supporting the implementation of
GC's, it should also be augmented with other features supporting efficient
implementation of such dynamic features.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/08 Raw View
Hans Aberg wrote:
> In article <35F329DB.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
...
> >In any event, if <100 times slower is your standard, it's easily met by
> >a C++ user-defined type.
>
> I think that a dynamic memory allocation alone can take 50-100 cycles.
> Did you fit that into your picture? It becomes complicated when the
> Integers have different length.
There is no dynamic memory allocation done in my example for small
integers, unless the user does it. If the user dynamically allocates a
multiprecision integer, then the only fair comparison is to a case where
the user dynamically allocates an ordinary integer. In that case, the
speed ratio drops, because very nearly the same amount of time is added
to each.
> >I implemented unsigned rather than signed multiprecision integers,
> >because they're simpler, and I can't justify spending the extra time to
> >cope with the extra issues of the signed types.
>
> I think that signed addition is simpler than unsigned addition and
> unsigned multiplication simpler than signded multiplication.
Unsigned operations treat all bits equally; signed operations treat the
sign bit differently from any other bit, which makes them more
complicated. The standard defines what happens in the case of unsigned
overflow; signed overflow is implementation-defined. Bitwise operations
such as '&' and '>>' also well-defined for unsigned integers, but
implementation-defined for negative numbers. Coping with those issues in
a portable fashion is a detail I didn't want to bother with.
> > Note also that the full multi-precision
> >code is left out, since we were specifically discussing the case where
> >the numbers are so small that it won't get executed.
>
> This is otherwise the tricky part.
That's why I left it out; you're the one who needs this feature - you
fill it in. I was only interested in showing that your speed ratio
requirements for integers that are small enough to not trigger those
parts of the code, can be met.
> >I don't expect the added
> >complexity to add significantly to execution time.
>
> Except for extra copying and dynamic memory allocations and such.
I was referring to the signed/unsigned issue; there is no copying or
dynamic memory allocation associated with resolving that issue.
...
> So what's the factor when using assembler?
I don't have current access to an assembler for any assembly language I
am familiar with. My need to do assembly language programming has
dropped radically as compiler technology has improved, and as more and
more hardware-level features are becoming available through C/C++
interfaces. You're the one claiming that assembler could be enough
faster on some machines to justify not using C++ code; please support
that claim.
...
> So it seems that you have proven the use of adding such an Integer type
> to the C++ standard: For the most of the time, one can use the type
> Integer, and then go in and optimize in the places where one knows int's
> will suffice and speed is crucial.
No; I have supported my claim that a user-defined type using portable
C++ code can be implemented efficiently enough to meet your
requirements. Whether assembly language is enough faster to justify the
expense of doing a seperate implementation in assembly language for each
platform is yet another issue. That issue can't even be usefully
discussed until someone produces an assembly language version, and
timing comparisons to C++ code on the same platform.
The final, and key, issue is whether the need for this feature is
sufficiently widespread to justify mandating that implementors do the
work, rather than leaving it to third-party library vendors, or even to
the individual developers themselves. It seems extremely unlikely to me
that the need is widespread, given that you seem to be the only person
asking for it.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/09/08 Raw View
>>>>> =ABHA=BB, Hans Aberg <haberg@REMOVE.matematik.su.se> wrote:
[...]
HA> Or are you claiming that Bourbaki cannot be mentioned in this threa=
d
HA> because there happens to be some math newsgroups available?
May I say lacanism?
>> A question related to your assertion: if there is an "abuse of
>> language" isn't it that not only the "linguistic simplifications are
>> formally incorrect" but there is also an indescriptible confusion in
>> the discussions ?=3D20
HA> Yes, this it is, because I have repeatedly tried to define the cont=
ext
HA> of the feature I speak about, which defines its wished-for qualities,=
but
HA> that context is somehow lost by those that reply.
HA> This confusion of language also appeared in some other threads that=
I
HA> posted, and (from my view-point) it seems to have to do with that tho=
se
HA> replying do not know about the kind of dynamic programming I am doing
HA> (which I think otherwise is rather standard), and are imposing condti=
ons
HA> form the static programming they are used to.
Well, I happen to be one of those who are *trying* to communicate with
you. I've got free hours to spend: could you, please, explain me
again that kind of standard dynamic programming you are doing with
realistic examples? Please explain also how that kind of programming is
related to C++ and why Standard C++ failed to fit your needs.
--=20
Gabriel Dos Reis | Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/08/30 Raw View
Should not the C++ standard library have some features facilitating the
implementation of multiprecision numerics?
For example a multiplication
pair<T, T> mult(T, T);
for the basic types T = int, long int, etc, with the pair containing both
the high and low T's. The thing is that the CPU is likely (I think) to
carry out the full multiplication, and in implementing multiprecision
numerics one wants to take advantage of that.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/08/31 Raw View
Hans Aberg wrote:
> Should not the C++ standard library have some features facilitating the
> implementation of multiprecision numerics?
> For example a multiplication
> pair<T, T> mult(T, T);
> for the basic types T = int, long int, etc, with the pair containing both
> the high and low T's. The thing is that the CPU is likely (I think) to
> carry out the full multiplication, and in implementing multiprecision
> numerics one wants to take advantage of that.
No. Such things are too specialized to belong in the C++ standard. You
can create your own without too much trouble, I would imagine.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/08/31 Raw View
James Kuyper <kuyper@wizard.net> wrote:
>Whether the multiprecision integers are built-in features of the
>language, or user-defined classes, they can't be implemented with 0
>overhead for values that will fit in an int. Code must be generated
>wherever they are used, to test whether they are small enough, and that
>code will inherently take a lot more time than ordinary arithmetic
>operations.
The first thing is that I want the C++ implementation to be as efficient
as possible, taking full advantage of low level features without having to
revert to assembler programming.
>> Say you have a computer were int's and long int's are both 32-bit.
>You
>
>A portable solution will, of course, produce correct results regardless
>of whether 'int' and 'long' are the same size.
I mentioned the restriction that the long and int are of the same size
because it is common on 32-bit machines and otherwise one can cheat: If a
long is 64-bit, one just converts the ints to longs, multiplies them, and
any overflow will fit into that.
>..Show me how to do that in pseudo-code that is
>equivalent to the machine code that you want the compiler to generate
>for a built-in multiprecision integer type; I'll show you how to write
>equivalent C++ code that can be attached to a user-defined type.
>Remember; if portability is one of your issues, as it appears to be, you
>can't count on the relevant features being built into the machine code
>language itself.
I can give you the C++ pseudo-code: Create a structure
class Integer {
int low;
unsigned* highp;
public:
friend Integer operator*(const Integer&, const Integer&);
};
The idea is that for small numbers highp is 0, avoiding dynamic memory
allocation, but when one must revert to multiprecision numbers, that is
stored in the highp, whereas the length and sign is stored in the low.
Then, with the "mult" function in hand just write
Integer operator*(const Integer& x, const Integer& y) {
if (x.is_low() && y.is_low()) {
pair<int, int> p = mult(x, y);
if (p.second == 0) return Integer(y); // Create an int.
else return Integer(p); // Multiprecision Integer.
}
... // Multi-precision stuff.
}
So one ends up with figuring out how to do the
pair<int, int> mult(int, int);
The multiprecision stuff would also need to use a similar function if the
implementation should be efficient (assuming that the CPU supplies such a
function).
So with some such C++ features in hand, one can fairly easy do fairly
portable implementations of multiprecision numerics.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/08/31 Raw View
In article <35EAB1B7.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>No. Such things are too specialized to belong in the C++ standard. You
>can create your own without too much trouble, I would imagine.
Let's see how _you_ do it without much trouble in current C++:
The idea is to build a structure which can dynamically change between
int's and multiprecision Integers without much loss of performance for
small numbers fitting into an int.
Say you have a computer were int's and long int's are both 32-bit. You
want to multiply to int's, and if there is overflow, one should create a
multiprecision Integer of those two int's high and low resulting from the
multiplication. In addition, all checks must be done efficiently so that
it does not take much longer time than multiplying two int's.
So how do you do it without much trouble?
I can add that some OS's have special routines corresponding
pair<int, int> mult(int, int);
but that is not portable.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/02 Raw View
In article <35EAB1B7.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>No. Such things are too specialized to belong in the C++ standard. You
>can create your own without too much trouble, I would imagine.
I think you have misunderstood the question: One can create such
constructs by writing them in assembler, but not in current C++. So
extending C++ this way helps the programmer not having to know the
assembler languages of the various CPU's. This is in line with the
original objective of C, which C++ inherited.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/02 Raw View
James Kuyper <kuyper@wizard.net> wrote:
James Kuyper <kuyper@wizard.net> wrote:
>> Integer operator*(const Integer& x, const Integer& y) {
>> if (x.is_low() && y.is_low()) {
>> pair<int, int> p = mult(x, y);
>> if (p.second == 0) return Integer(y); // Create an int.
>> else return Integer(p); // Multiprecision Integer.
>> }
>
>I don't see any way for a built-in type to implement the equivalent of
>the above code in machine code (ignoring the hidden details inside
>mult(x,y)), with fewer than three comparisons per multiply operation.
>Those comparisons alone will, on most of the machines I'm familiar with,
>take almost as much time, if not more time, than an ordinary integer
>multiply.
It depends on how much hard-wired multiplication the computer has, of course.
>That is why I felt that your specification that it should
>carry negligible overhead when the numbers are low is infeasible.
One faces a situation where multiprecison numbers are required, but one
wants the implementation dynamically to speed it up as much as possible
when multiprecison is not needed. (So there is no way to foresee the
useage at compile time.)
>I was really looking for pseudocode for the mult() function. I have some
>ideas how it can be done, but none with a low overhead.
I can think of two methods, splitting up the int's in half-size int's
and the multiply the different parts and add them using suitable
bitshifts. Alternatively, one might devise a binary multiplication using
addition and bit-shifts alone, but that is probable even slower.
But it seems unnecessary for the programmer to do all that if the CPU
already provides an instruction for it (regardless how you would want to
apply it).
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos_Reis <gdosreis@sophia.inria.fr>
Date: 1998/09/02 Raw View
haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
> Should not the C++ standard library have some features facilitating t=
he
> implementation of multiprecision numerics?
>=20
> For example a multiplication
> pair<T, T> mult(T, T);
> for the basic types T =3D int, long int, etc, with the pair containing =
both
> the high and low T's.
No.
> The thing is that the CPU is likely (I think) to
> carry out the full multiplication, and in implementing multiprecision
> numerics one wants to take advantage of that.
You said "likely". In fact you do not have any warranty. I guest you
implement such a thing yourself -- and if you insist on having=20
control over the hardware (royalroad to non-portability) then you
might want to consider "asm()".
--=20
Gabriel Dos Reis | Centre de Math=E9matiques et de=20
dosreis@cmla.ens-cachan.fr | Leurs Applications
Fax : (33) 01 47 40 21 69 | ENS de Cachan -- CNRS (URA 1611)
61, Avenue du Pdt Wilson, 94235 Cachan - Cedex
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/04 Raw View
Hans Aberg wrote:
>
> In article <35EEFC61.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >The purpose of my request for example assembly language is to refute two
> >of your claims. The first is your claim that it can't be implemented in
> >C++, but only in assembler.
>
> I never claimed that; in fact I started to write such code. It is
> obvious it can be done in C++.
Yes you did. In a previous message on this thread
<haberg-3008981621290001@sl109.modempool.kth.se> you wrote:
>> I think you have misunderstood the question: One can create such
>> constructs by writing them in assembler, but not in current C++. So
> >The second is your claim that it can be
> >implemented so as to impose negligible overhead compared with ordinary
> >integers, when the numbers are small enough that ordinary integers would
> >have been sufficient.
>
> I never said that either: The idea is not to get a structure that can
In a previous message on this thread
<haberg-3108981848480001@sl55.modempool.kth.se> you wrote:
>> multiplication. In addition, all checks must be done efficiently so that
>> it does not take much longer time than multiplying two int's.
However, you only said that it is a goal which must be achieved. I admit
that I'm responsible for making the assumption that you were claiming to
know for certain that it was an achievable goal. To me, this implied
that you knew of some way to actually achieve it, on at least one
platform. I apologize for making that unjustified assumption; it's quite
clear now that it was a false one.
...
> >> So you seem to think that C++ is the dictatorship of the majority, which
> >> usually is a mediocracy:
> >
> >That's right; C++ is a standard, not a place for innovation in the name
> >of bleeding edge efficiency.
>
> I think you are confusing "innovation" with providing the quality
> material which is essential for more sophisticated programmers.
What Standard C++ mandates should be implementable with high quality,
but it's not supposed to mandate everything that a programmer might
need. You're supposed to supplement it with implementation-specific
features, operating system calls, third party libraries, and your own
code, in order to get useful programs.
> >I've noticed a resounding lack of people supporting your request; we two
> >are very nearly the only ones posting to this thread. I suspect that
> >this feature is not widely desired.
>
> I think that many of those that implement more advanced things, like
> dynamic computer languages, have given up using C++, so that is perhaps
> the reason.
Standard C++ isn't the language you want it to be, and IMHO it isn't
appropriate for it to become the language you want it to be.
Furthermore, given the nature of the standardization process, IIRC it
will be at least a decade before it could possibly changed to be what
you want it to be. For the next several years, the only changes that are
permissible are defect corrections.
I recommend that you spend some time during the next few years
convincing some particular implementor to add multiprecision integers.
Then, when discussions are started for the next version of the standard,
there will be some experience with an existing implementation, as a
basis for those discussions.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/04 Raw View
In article <35F03C92.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>> I think that many of those that implement more advanced things, like
>> dynamic computer languages, have given up using C++, so that is perhaps
>> the reason.
>
>Standard C++ isn't the language you want it to be,
I thought standards were created because people did not like the
language as it is -- after all if the language already is agreed upon by
everybody to as what it should be, there would be no need for creating a
standard.
>and IMHO it isn't
>appropriate for it to become the language you want it to be.
I gather if people and evolution disagrees with you, it may be become
appropriate.
>Furthermore, given the nature of the standardization process, IIRC it
>will be at least a decade before it could possibly changed to be what
>you want it to be.
That's how it is breaking grounds.
>For the next several years, the only changes that are
>permissible are defect corrections.
In securing the current standard, yes. But I think it might be possible
to introduce suggestions for the next version.
>I recommend that you spend some time during the next few years
>convincing some particular implementor to add multiprecision integers.
First, I think you are confusing "adding multiprecision integers" with
adding support for implementing such a feature conveiently.
Otherwise, there are probably lots of multiprecision numerics libraries
out there.
>Then, when discussions are started for the next version of the standard,
>there will be some experience with an existing implementation, as a
>basis for those discussions.
I thought the next version discussions already had started by my posts. :-)
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/05 Raw View
In article <haberg-0509980035010001@sl11.modempool.kth.se>, Hans Aberg
<haberg@matematik.su.se> writes
> I thought standards were created because people did not like the
>language as it is -- after all if the language already is agreed upon by
>everybody to as what it should be, there would be no need for creating a
>standard.
No. he purpose of a standard is to document the conscensus of what the
language is. At that stage those that disagree are free to go their own
way but cannot claim to be standard conforming. The term 'existing
practice' does not mean that everyone does it that way but that there is
at least one example (might even be in another language) of an
implementation of that idea.
Actually C++ standardisation walked a very fine line (I think it crossed
it several times) with things like member templates, but I think that
those responsible got it largely right and had they not chanced their
arms C++ woud have been a much poorer language.
--
Francis Glassborow
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/06 Raw View
In article <35F03C92.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>Hans Aberg wrote:
..
>Yes you did. In a previous ... you wrote:
>>> I think you have misunderstood the question: One can create such
>>> constructs by writing them in assembler, but not in current C++.
From the generalistic point of view, sufficiently general computer
languages simulate approximations of Turing machines, and the latter are
equivalent in the sense that what can computed on one of them can also be
computer on the others. So, therefore one will always expect what is
logically possible within one such computer language will also be
logically possible in another.
> you wrote:
>>> multiplication. In addition, all checks must be done efficiently so that
>>> it does not take much longer time than multiplying two int's.
The equivalence of Turing machines does not preserve the other semantic
structure one wants describe, so the translation does not result in
efficient implementations.
So when, by abuse of language, one speaks about "possible" and
"efficient" that always refer to a pragmatic computer context.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@REMOVE.matematik.su.se (Hans Aberg)
Date: 1998/09/06 Raw View
In article <zic5EQAEuR81EwYj@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>In article <haberg-0509980035010001@sl11.modempool.kth.se>, Hans Aberg
><haberg@matematik.su.se> writes
>> I thought standards were created because people did not like the
>>language as it is -- after all if the language already is agreed upon by
>>everybody to as what it should be, there would be no need for creating a
>>standard.
>
>No. he purpose of a standard is to document the conscensus of what the
>language is.
Well, if there is already a concensus, one has a so called de facto
standard, and it is no point in writing it down, as everybody already
knows about it.
In creating a standard, one does not write down a concensus, but
attempts to reach a concensus by negotiation, and then hopefully writes
down that negotiated concensus, that is, unless there are some strong
individuals writing down their own views, pretending it is a concensus.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/02 Raw View
In article <xaj90k326nj.fsf@korrigan.inria.fr>, Gabriel Dos_Reis
<gdosreis@sophia.inria.fr> wrote:
>haberg@REMOVE.matematik.su.se (Hans Aberg) writes:
>
>> Should not the C++ standard library have some features facilitating the
>> implementation of multiprecision numerics?
>No.
I gather this is an expression of a private opinion. Please elaborate so
that others can understand why they should bother about this private
opinion of yours.
>> The thing is that the CPU is likely (I think) to
>> carry out the full multiplication, and in implementing multiprecision
>> numerics one wants to take advantage of that.
>
>You said "likely". In fact you do not have any warranty.
In fact the question is irrelavant whether the CPU has such an
instruction or not: What is important is if it can be made signifantly
faster on relavant platforms.
>and if you insist on having
>control over the hardware (royalroad to non-portability) then you
>might want to consider "asm()".
I think this is some kind of misunderstanding here: I want to implement
these features as efficiently as possible without having to revert to
assembler, and I want C++ to be extended enabling that. Your answer sems
to indicate that you think my question deals with how to solve this
problem within current C++: I know this can be done, of course, but not
without wrestling a lot with details adding a great deal of overhead.
I looks to me that C++ could add multiprecision numerics which for small
numbers do not add too much overhead, especially on the more modern CPU's
with better set of instructions.
Now every dynamic language of signifacnce simply must have multiprecions
numerics built in, so if C++ should be used for the implmentation of such
dynamic languages, it sounds as a good thing to add a multpirecison
numrics library to C++.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/02 Raw View
Hans Aberg wrote:
>
> In article <35EAB1B7.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >No. Such things are too specialized to belong in the C++ standard. You
> >can create your own without too much trouble, I would imagine.
>
> I think you have misunderstood the question: One can create such
> constructs by writing them in assembler, but not in current C++. So
> extending C++ this way helps the programmer not having to know the
> assembler languages of the various CPU's. This is in line with the
> original objective of C, which C++ inherited.
I believe that if you can write it in assembler, I can write the
functional equivalent in C++; a good compiler may even be able to
optimize the C++ code down to match the assembler. Therefore, please
provide an example of how to do this in assembler.
The C++ code may execute a little slower than hand-optimized assembler,
but it just isn't appropriate to require so specialized a need to be
supported as a built-in type mandated by the standard, rather than as a
user-defined type.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/03 Raw View
In article <35ED8F64.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>Hans Aberg wrote:
>> I think you have misunderstood the question: One can create such
>> constructs by writing them in assembler, but not in current C++. So
>> extending C++ this way helps the programmer not having to know the
>> assembler languages of the various CPU's. This is in line with the
>> original objective of C, which C++ inherited.
>
>I believe that if you can write it in assembler, I can write the
>functional equivalent in C++; a good compiler may even be able to
>optimize the C++ code down to match the assembler.
I believe it when I see it.
>..Therefore, please
>provide an example of how to do this in assembler.
If I bring up the suggestion for adding a C++ multiprecision numerics
library in order that I and others that might need it should be able to
avoid having to write it in assembler, why should I post assembler code of
it to this newsgroup. -- It sounds as a contradiction to me.
If you are so sure that an implementation in current C++ is just as fast
as assembler, you should work through a good number of CPU's and compare.
It may also take a couple of generations before implementions have
discovered all the tricks one can do.
>The C++ code may execute a little slower than hand-optimized assembler,
>but it just isn't appropriate to require so specialized a need to be
>supported as a built-in type mandated by the standard, rather than as a
>user-defined type.
So seem to think that C++ is the dictatorship of the majority, which
usually is a mediocracy:
Whenever I post a suggestion of a C++ extension to this group there are
a couple of guys who never use the feature saying, no, this is too
specialized. It would be much better to hear from some of those fellows
who use the feature, know it well, and can report back their experience of
it.
With respect to multiprecision numerics, it shows up in various
contexts, one is in dynamic languages and such, and in cryptography I
recall. It is only uncommon to people who do not use it.
There are probably a lot of programmers out in industry who never can
think on something more general than an "int", but I did not have those in
mind as an audience when bringing up this suggestion.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/03 Raw View
Hans Aberg wrote:
...
> I looks to me that C++ could add multiprecision numerics which for small
> numbers do not add too much overhead, especially on the more modern CPU's
> with better set of instructions.
Could you explain that in more detail? It looks impossible to me. An
example of how it could be done on even a single machine would be
helpful. The issue of whether the standard should be changed to mandate
it's implementation on all machines comes later.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/03 Raw View
In article <35ED903B.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>Hans Aberg wrote:
>...
>> I looks to me that C++ could add multiprecision numerics which for small
>> numbers do not add too much overhead, especially on the more modern CPU's
>> with better set of instructions.
>
>Could you explain that in more detail? It looks impossible to me. An
>example of how it could be done on even a single machine would be
>helpful. The issue of whether the standard should be changed to mandate
>it's implementation on all machines comes later.
I already gave one suggestion, namely a class with an int or long, which
could be used for small numbers, and a pointer which could point to an
array of int's or long's when that does not suffice, like this:
class Integer {
long low;
long* high;
public:
};
One then optimizes around this idea, probably to try to make the checks
for overflow take as little time as possible.
I think that James Kuyper interprets the wording "not adding too much
overhead" in ways like "exactly as fast as an int" and the like, but that
is impossible: I just describe a common pragmatics when implementing this
kind of stuff. Do the best one can.
Right now, dynamic memory allocation is very slow in C++, so that should
be avoided (but this may change in the future). Then one does not want to
add a whole lot of instructions for the structure substituting for the
integers.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/03 Raw View
In article <haberg-0309980147140001@sl122.modempool.kth.se>, Hans Aberg
<haberg@matematik.su.se> writes
> If I bring up the suggestion for adding a C++ multiprecision numerics
>library in order that I and others that might need it should be able to
>avoid having to write it in assembler, why should I post assembler code of
>it to this newsgroup. -- It sounds as a contradiction to me.
>
> If you are so sure that an implementation in current C++ is just as fast
>as assembler, you should work through a good number of CPU's and compare.
>It may also take a couple of generations before implementions have
>discovered all the tricks one can do.
First note that almost all the standard library is written in C++ though
implementors may elect to hand code in assembly language if they wish
(that can be expensive and adds to maintenance problems as such elements
must be recoded for each processor - not just each family. If I cared
about speed I would probably not be happy with 8088 coding running on a
pentium II)
If something is in the standard ALL conforming implementations must
provide it. Where something will be broadly used across several
platforms it makes sense to provide it in the standard. Where it is of
specialist concern it might be better to leave it to specialist
providers (who will know their own market)
Actually, I have for long contended that we need a more fine grained set
of standards with specialist libraries standardised separately from the
core language.
In the final analysis you get in the standard what those writing it have
devoted their time to. I know this is harsh, and there are all sorts of
things I would like to have seen considered but without at least one
active supporter attending meetings most ideas have little chance.
I suggest that if you want to see multi-precision numerics in C++ an
early priority is to find one (preferably more) people who are willing
to promote it at meetings (and promote it largely means defend work done
rather than persuade others to do the work)
It is instructive to look at the work done on C9X. A lot of numerical
extensions work has been incorporated because there are a number of
participants promoting it. There is no language support for parallel
processing (MIMD and SIMD) because (among other things) there was no one
able to do the job and free to attend meetings. The latter might not
have made it anyway but without a sponsor it did not even get a hearing.
--
Francis Glassborow
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/03 Raw View
Hans Aberg wrote:
>
> In article <35ED8F64.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >Hans Aberg wrote:
> >> I think you have misunderstood the question: One can create such
> >> constructs by writing them in assembler, but not in current C++. So
> >> extending C++ this way helps the programmer not having to know the
> >> assembler languages of the various CPU's. This is in line with the
> >> original objective of C, which C++ inherited.
> >
> >I believe that if you can write it in assembler, I can write the
> >functional equivalent in C++; a good compiler may even be able to
> >optimize the C++ code down to match the assembler.
>
> I believe it when I see it.
You can't see it if you won't provide the needed input.
> >..Therefore, please
> >provide an example of how to do this in assembler.
>
> If I bring up the suggestion for adding a C++ multiprecision numerics
> library in order that I and others that might need it should be able to
> avoid having to write it in assembler, why should I post assembler code of
> it to this newsgroup. -- It sounds as a contradiction to me.
The standard is not supposed to be a platform for development of new
features; it's supposed to be a forum for standardizing the interface to
features that have already been proven out by at least one experimental
implementation. In the course of standardizing something, the committee
may change it enough that it counts as an innovation, and the C++
committee has been accused of doing just that, far too often. That is a
legitimate thing to complain about; whether the complaints are justified
is an issue for another thread.
> If you are so sure that an implementation in current C++ is just as fast
> as assembler, you should work through a good number of CPU's and compare.
> It may also take a couple of generations before implementions have
> discovered all the tricks one can do.
I only said that it could be almost as efficient with a good compiler.
Whether it actualy will be depends upon both the compiler and the code.
If maximum efficiency is the issue, of course you must write in
assembler; the only question is whether the C implementor, a third-party
vendor, or the user himself, should be responsible for writing the
assembly language code. This feature is too specialized to require it of
all implementations; it might be a plausible candidate for a
implementation-specific extension, or a third-party library.
The purpose of my request for example assembly language is to refute two
of your claims. The first is your claim that it can't be implemented in
C++, but only in assembler. The second is your claim that it can be
implemented so as to impose negligible overhead compared with ordinary
integers, when the numbers are small enough that ordinary integers would
have been sufficient. Fundamental integer operations are very fast on
every machine I'm aware of; you can't replace them with significantly
more complicated operations, without incurring a significant speed
penalty. I don't see anyway I can disprove either claim, if you won't
provide an example.
> >The C++ code may execute a little slower than hand-optimized assembler,
> >but it just isn't appropriate to require so specialized a need to be
> >supported as a built-in type mandated by the standard, rather than as a
> >user-defined type.
>
> So seem to think that C++ is the dictatorship of the majority, which
> usually is a mediocracy:
That's right; C++ is a standard, not a place for innovation in the name
of bleeding edge efficiency. The only things that belong in the standard
are features needed so widely as to justify requiring every
implementation to support them. Of course, those features should be
designed so they can be implemented as efficiently as possible, but the
standard should not worried about potntially implementation-dependent
details of efficiency.
> Whenever I post a suggestion of a C++ extension to this group there are
> a couple of guys who never use the feature saying, no, this is too
> specialized. It would be much better to hear from some of those fellows
> who use the feature, know it well, and can report back their experience of
> it.
I've noticed a resounding lack of people supporting your request; we two
are very nearly the only ones posting to this thread. I suspect that
this feature is not widely desired.
> With respect to multiprecision numerics, it shows up in various
> contexts, one is in dynamic languages and such, and in cryptography I
> recall. It is only uncommon to people who do not use it.
I suspect that it is far less widely used than, for instance, matrix
inversion, which is another example of a feature that is too specialized
for inclusion in the standard.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/03 Raw View
In article <hnMDxnAVwn71EwCk@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>First note that almost all the standard library is written in C++ though
>implementors may elect to hand code in assembly language if they wish
From what I have seen, code often starts out in C or C++, but then at
crucial points one replaces it with suitable assembler or OS commands at
crucial points.
>(that can be expensive and adds to maintenance problems as such elements
>must be recoded for each processor - not just each family. If I cared
>about speed I would probably not be happy with 8088 coding running on a
>pentium II)
Of course, it depends on what platforms one has in mind, but the problem
is often not too bad, as CPU's run in families which are reasonably
instruction compatible.
>If something is in the standard ALL conforming implementations must
>provide it. Where something will be broadly used across several
>platforms it makes sense to provide it in the standard. Where it is of
>specialist concern it might be better to leave it to specialist
>providers (who will know their own market)
This is usually the reason to put it there. One should note that it is
not necessary to for it to run efficiently on all platforms, only on those
interesting for the feature.
So with respect to multiprecision numerics, that is a feature that is
common in dynamic languages (like Haskell, which I made a Mac port of).
For such an application, as matters now stand, it turns out that there is
not much of a point in trying to implement it on computers that are less
powerful than a RISC, or Pentium 32-bit CPU.
But this is perfectly OK for a C++ standard: It will not run efficently
on some older model computers, but then one is not likely to use it on
those computers either.
>Actually, I have for long contended that we need a more fine grained set
>of standards with specialist libraries standardised separately from the
>core language.
Right, indeed, and if there is to be a new version of the C++ standard,
that ought to be a topic for this new standard.
The thing is that even though certain features may appear to be very
specialized to those who do not need them, what is important is also how
influential those features are where they are used. So for example,
dynamical implementations of various kinds certainly belongs to the
future. It should be easy to implement such dynamical features efficiently
using C++.
>In the final analysis you get in the standard what those writing it have
>devoted their time to. I know this is harsh, and there are all sorts of
>things I would like to have seen considered but without at least one
>active supporter attending meetings most ideas have little chance.
This seems to be major problem with the current C++ standard, that those
who wrote it never seems to have spent much time on implementing dynamical
features.
It might be OK for the current C++ standard, but one might hope for a
bettering for the next version.
>I suggest that if you want to see multi-precision numerics in C++ an
>early priority is to find one (preferably more) people who are willing
>to promote it at meetings (and promote it largely means defend work done
>rather than persuade others to do the work)
That is why I posted it here, to see if there was anybody else
encountering the feature. :-)
>It is instructive to look at the work done on C9X. A lot of numerical
>extensions work has been incorporated because there are a number of
>participants promoting it. There is no language support for parallel
>processing (MIMD and SIMD) because (among other things) there was no one
>able to do the job and free to attend meetings. The latter might not
>have made it anyway but without a sponsor it did not even get a hearing.
This is also a weakness of current C++, that it does not have language
constructs supporting parallel computing.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/09/04 Raw View
In article <haberg-0309981145480001@sl05.modempool.kth.se>, Hans Aberg
<haberg@matematik.su.se> writes
> I already gave one suggestion, namely a class with an int or long, which
>could be used for small numbers, and a pointer which could point to an
>array of int's or long's when that does not suffice, like this:
> class Integer {
> long low;
> long* high;
> public:
> };
>One then optimizes around this idea, probably to try to make the checks
>for overflow take as little time as possible.
I think that it actually becomes much more complicated. I know the idea
seems simple but there are many problems on the way. I am not convinced
that it is worth the effort for general computation (try implementing an
efficient multibyte division -- yes I do know what I am writing about as
I wrote a heavily optimised 64-bit int for a Z80 based system, to get
anywhere near acceptable general performance I had separate functions
depending on the absolute magnitude of the divisor -- I also had some
special multibyte multiplications. The point I am making is that what
you would do for an int where only add and subtract was required would
be different from what you do if you also want to multiply and different
again if you want maximum range for division. In any specific
application domain you may want different choices.
BTW Knuth has an extremely fast coding for ints where only
multiplication and division are required, I doubt that you would want
to use it in the real world (he gives it as an example of special
purpose representations)
--
Francis Glassborow
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/09/04 Raw View
Hans Aberg wrote:
>
> In article <35ED903B.446B@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
> >Hans Aberg wrote:
> >...
> >> I looks to me that C++ could add multiprecision numerics which for small
> >> numbers do not add too much overhead, especially on the more modern CPU's
> >> with better set of instructions.
> >
> >Could you explain that in more detail? It looks impossible to me. An
> >example of how it could be done on even a single machine would be
> >helpful. The issue of whether the standard should be changed to mandate
> >it's implementation on all machines comes later.
>
> I already gave one suggestion, namely a class with an int or long, which
> could be used for small numbers, and a pointer which could point to an
> array of int's or long's when that does not suffice, like this:
> class Integer {
> long low;
> long* high;
> public:
> };
Your explanation is incomplete, without an example detailing the
instructions to be executed to implement at least some of the
operations. I know how to implement the operations, but not in a way
that meets your criteria.
> One then optimizes around this idea, probably to try to make the checks
> for overflow take as little time as possible.
>
> I think that James Kuyper interprets the wording "not adding too much
> overhead" in ways like "exactly as fast as an int" and the like, but that
No. Ordinarily I'd interpret it to mean something like "less than 1.5
times as long as integer operations". You've not been specific, and for
your benefit I've tried to interpret it as meaning "less than 2.0 times
as long as integer operations".
> is impossible: I just describe a common pragmatics when implementing this
> kind of stuff. Do the best one can.
"Do the best you can" corresponds to multiplications that run from 4 to
13 times slower, using the best methods I've been able to figure out,
under the 4 different assembly languages I'm familiar with. In making
these estimates I assumed that the operations are in-lined, and ignored
some optimization-dependent details such as the time needed to load
registers. If that's an acceptable overhead cost, I'll be happy to
provide examples showing how it could be implementated as a user-defined
type that should achieve comparable speed on a really good compiler. If
that's not an acceptable amount of overhead, then you need to show that
it can be done with whatever you do consider to be acceptable amounts of
overhead.
> Right now, dynamic memory allocation is very slow in C++, so that should
> be avoided (but this may change in the future). Then one does not want to
> add a whole lot of instructions for the structure substituting for the
> integers.
I don't see how an implementation could avoid using dynamic allocation
to fill in the 'high' pointer in your structure, whether it was as a
built-in or a user-defined type. No other dynamic allocation would be
required, even for a user-defined type.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jpotter@falcon.lhup.edu (John Potter)
Date: 1998/09/04 Raw View
James Kuyper <kuyper@wizard.net> wrote:
: Hans Aberg wrote:
: > Whenever I post a suggestion of a C++ extension to this group there are
: > a couple of guys who never use the feature saying, no, this is too
: > specialized. It would be much better to hear from some of those fellows
: > who use the feature, know it well, and can report back their experience of
: > it.
: I've noticed a resounding lack of people supporting your request; we two
: are very nearly the only ones posting to this thread. I suspect that
: this feature is not widely desired.
I am only interjecting a thought. Support for neither.
Given a 16 bit machine, it is possible to use the features of the
architecture.
unsigned short a(16000), b(8000);
unsigned long c((long)a * b);
It seems to me that the only thing missing is an integer type which is
double the size of the hardware type. It would then be possible to
get the two register answer produced by single register multiplication
and to provide a double register dividend for division.
This may not generalize to all architectures and it may not be a
reasonable thing for the standard; however, it seems to be the only
thing needed to make efficient multiprecision math possible in C++.
Should it then be a standard library? That's another question.
John
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/04 Raw View
In article <35EEC227.2781@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>> I think that James Kuyper interprets the wording "not adding too much
>> overhead" in ways like "exactly as fast as an int" and the like, but that
>
>No. Ordinarily I'd interpret it to mean something like "less than 1.5
>times as long as integer operations". You've not been specific, and for
>your benefit I've tried to interpret it as meaning "less than 2.0 times
>as long as integer operations".
I think that when working with dynamic features, the goal is to make
them only 10-100 (instead of 1000 to 10000) times slower than highly
optimized C++ code.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/04 Raw View
In article <NbFIutAyer71EwEX@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:
>In article <haberg-0309981145480001@sl05.modempool.kth.se>, Hans Aberg
><haberg@matematik.su.se> writes
>> I already gave one suggestion, namely a class with an int or long, which
>>could be used for small numbers, and a pointer which could point to an
>>array of int's or long's when that does not suffice, like this:
>> class Integer {
>> long low;
>> long* high;
>> public:
>> };
>>One then optimizes around this idea, probably to try to make the checks
>>for overflow take as little time as possible.
>I think that it actually becomes much more complicated. I know the idea
>seems simple but there are many problems on the way. I am not convinced
>that it is worth the effort for general computation (try implementing an
>efficient multibyte division -- yes I do know what I am writing about as
>I wrote a heavily optimised 64-bit int for a Z80 based system, to get
>anywhere near acceptable general performance I had separate functions
>depending on the absolute magnitude of the divisor -- I also had some
>special multibyte multiplications.
To begin with, the idea is not to get a structure which is as efficient
as an int in situations where one knows that nothing more that an int will
ever be needed. I do not think there is any situation where one can expect
dynamic checks to equal in performance with the optimizations that can be
done at compile time.
Another aspect though is that the arcitecture of todays computer is
designed heavily around static programming, but it is moving towards
supporting features needed in dynamic programming.
So the quest for a language like C++ is to prudently understand that
development, and support the implementation of such dynamic features using
C++.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/04 Raw View
In article <35EEFC61.59E2@wizard.net>, James Kuyper <kuyper@wizard.net> wrote:
>The purpose of my request for example assembly language is to refute two
>of your claims. The first is your claim that it can't be implemented in
>C++, but only in assembler.
I never claimed that; in fact I started to write such code. It is
obvious it can be done in C++.
>The second is your claim that it can be
>implemented so as to impose negligible overhead compared with ordinary
>integers, when the numbers are small enough that ordinary integers would
>have been sufficient.
I never said that either: The idea is not to get a structure that can
substitute for an "int" in the cases where it is possible to foresee at
compile time that no more than an int is needed.
In the cases I have in my mind, one knows that int's will suffice for
the most of the time, but sometimes multiprecision is will be needed, and
it is not posiible to forsee when that happens. So using an int is not an
option.
>> So you seem to think that C++ is the dictatorship of the majority, which
>> usually is a mediocracy:
>
>That's right; C++ is a standard, not a place for innovation in the name
>of bleeding edge efficiency.
I think you are confusing "innovation" with providing the quality
material which is essential for more sophisticated programmers.
For example, providing the material making it easy to implemnet an OS is
not the majority stuff, but should be a part of C++ if wants to keep up
with the original objective of C.
The techniques that today seem experimental and esotheric to bread
programmers of today, are in fact standard to the more sophisticaed
programmer of today, and will be standard to bread programmers of
tomorrow.
>I've noticed a resounding lack of people supporting your request; we two
>are very nearly the only ones posting to this thread. I suspect that
>this feature is not widely desired.
I think that many of those that implement more advanced things, like
dynamic computer languages, have given up using C++, so that is perhaps
the reason.
Besides, I am used to attempting to break grounds among a bunch of
die-hards; usually the change starts to happen a decade after I stopped
being interested in the feature. After all, somebody must be first.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: haberg@matematik.su.se (Hans Aberg)
Date: 1998/09/04 Raw View
In article <6snf2k$a33$1@pigpen.csrlink.net>, jpotter@falcon.lhup.edu
(John Potter) wrote:
>Given a 16 bit machine, it is possible to use the features of the
>architecture.
>
> unsigned short a(16000), b(8000);
> unsigned long c((long)a * b);
>
>It seems to me that the only thing missing is an integer type which is
>double the size of the hardware type. It would then be possible to
>get the two register answer produced by single register multiplication
>and to provide a double register dividend for division.
I think this was mentioned for 32-bit multiplications on a 64-bit
computer. Some CPU's may also have say a 32-bit memory bus, and 64 bit
internal registers, and then it would work the same.
In addition, manufacturers of CPU may make special support for such
features, if they start to appear in programs, in which case that
development will make the programs more speedy.
Hans Aberg * Anti-spam: Remove "REMOVE." from email address.
* Email: Hans Aberg <haberg@REMOVE.member.ams.org>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]