From: hasta_l3 on
{ All posters are encouraged to stay on-topic and keep the postings
related to C++. -mod/sk }

Walter Bright wrote :

> James Kanze wrote:
> > As for a million words... I'd say that any language had that
> > many, if you count all of the technical words (e.g. names of
> > diseases, scientific names of plants and animals, ...).
> I was counting them, and no other language has made such
> an accumulation of them.

FWIW, the one million figure is IMO an artifact of the way words
are counted.

Languages like french have official monitoring organisms,
that drop obsolete words from the language, are usually
very cautious before accepting new words, and often don't
include dialects in the official language.

By contrast, the one million figure of english most likely comes
from the Oxford English Corpus, that collects words from a
as many sources as possible, and includes british, american,
australian english as well as obsolete words and one-off coinages.

The Oxford way of counting words is bound to give a larger figure
than the "official" number of words in a more formalized language.

At any rate, dictionaries have the same size in english, french
and german (roughly 50.000 words) - meaning that these languages
have the same number of words for all practical purpose.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Mirek Fidler wrote:
> In reality, I see no reason why good compiler could not optimize out a
> reference.

In your example, the struct was not placed into a register.

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Al on

David Abrahams wrote:
> Walter Bright <walter(a)> writes:
>> Numerical analysis is quite likely something that a mainstream
>> programmer would never encounter. It doesn't come up when you're writing
>> guis, databases, compilers, device drivers, web apps, games
> Whoa, stop right there. Many of today's games contain sophisticated
> physics simulations that require intense numerical analysis.

While current games do indeed use sophisticated physics, most of this
work is relegated to specific libraries (e.g. havok, physx), or engines
(e.g. unreal ragdoll physics) or even dedicated cards (i.e. the ageia
ppu). Therefore, I doubt that most programmers, even those on game dev
teams, directly interact with any numerical analysis code.

On that vein, when can we expect

#include <physics>

to be part of the STL? ;)


[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Walter Bright on
Peter Dimov wrote:
> Walter Bright wrote:
>> Peter Dimov wrote:
>>> In theory, they ought to fail. In practice, most of them work just
>>> fine. That's the beauty of UTF-8. In-place character manipulation
>>> doesn't work in general anyway, even for an ordinary single-byte
>>> encoding.
>> Having them 'mostly' work isn't good enough. Searching doesn't work, for
>> example.
> I believe that it does.


size_type find (charT c, size_type pos = 0) const;

What if c isn't ASCII?

Consider this snippet from the Standard:

string s1("abc");
string::iterator i = s1.begin();
string s2 = s1;
*i = �a�;

How is that supposed to work, if 'a' is not ASCII?

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Bjørn Roald on
Francis Glassborow wrote:
> In article <4569c5cf(a)>, Bj�rn Roald <bjorn(a)>
> writes
>> 1.
>> It is hard to find existing relevant libraries that could be accepted
>> for projects. They are mostly:
>> - not standardized
> And how is that different from Java, C# etc.

My point is that those usually have plenty of library support shipped
with the compiler as e.g. in the JDK, .Net development platforms.

>> - not shipped with compiler
> Ditto

As they are not standardized, as in "come standard with all compilers
from all vendors", they tend not to be found or used.

>> - not portable or ported to all needed platforms
> However languages like Java, C# etc use a VM to circumvent that problem
> and generally do not try to provide for embedded systems. Note that were
> CLI widely implemented the C++/CLI dialect of C++ would reap the same
> benefit.

But then it would not be C++, would it. I tend to think mixed code
under C++/CLI is good to bridge two worlds - but that is about it. Most
people I know selecting .Net as platform prefer other languages.

>> - not well known and trusted
> Oh? Well I do not trust most of the libraries written for those other
> languages. Many of them are simply of inadequate quality for mission
> critical programming.

Yeh, I tend to agree. I do however think most developers and to a
larger extent their management think libraries that comes with the
compiler is of a higher quality than most other. I fail to see why that
is a bad way of looking at things in general. The point is, it is hard
to know which other libraries out there hold similar or better quality.

> Another issue is that languages like Python are not portable in time
> because the language does not maintain portability of legacy code.

Probably true, I am no expert on this. But how is that better for C++
libraries that are not standardized?

>> - not part of a community repository like CPAN for Perl
> IIRC their is very little quality control for code available that way.
> Boost for C++ sets very high requirements. Perhaps we could do with a
> repository with lesser entry requirements.

Yes, I think that would be good thing. Maybe not required to be a new
home for all libraries that want to enter. But rather a place where one
can find and compare candidate libraries for the problem domain.
Information that indicate properties like quality, legal issues,
license, stability of interfaces, support options, user feed-back, etc.
could be organized in a way making things easier for those who search or
attempt to get permission from management or legal department.

>> 2.
>> If relevant library exist for C++ it can often not be accepted in
>> projects for the following reasons:
>> a) legal concerns related to license terms
> Really, and that is different for other languages?

Usually terms for libraries that are shipped with compilers are ok.
Well normally you have already been given or paid for the right to use
them. Thus, since these languages come with more standard or community
libraries, their support for application level features are more

>> b) platform compatibility
> See above

Well, above you only explain why it is harder to write portable
libraries in C++ than WM based languages. That does not explain why
many C++ library vendors tend to ignore all but one platform.

>> c) known cost
> ? What do you mean?

Only that if it comes with the compiler it becomes simpler to know. If
libraries or their interfaces are standardized as well, and there are
competing compiler/library vendors, it becomes harder to get caught in
the net of some commercial tie-up scheme.

>> d) lack of relevant support
> How is that different for Java etc.

Good point. I guess I was generalizing to much. There are of case
plenty of C++ libraries with excellent support in many shapes and forms.
It was not my intention to say otherwise. It is however much harder
to secure relevant support for a multitude of 3'rd party libraries in
C++, compared to if I could get it all from one vendor. I know for a
fact that this often disqualify otherwise excellent libraries.

>> e) risk related to future directions, continuation, or cost
> Even worse for many of the languages you listed. One high price for C++
> is the requirement for supporting legacy code.

Well that may be true, but my point was related to none standardized or
community libraries. E.i. third party commercial libraries in particular.

>> f) lack of legal entity responsible for intellectual property issues
> You are joking aren't you?

No, If I have nobody to blame for the stealing. Everybody would look at
me. If I use some library which happens, knowingly or not, to have
wrongfully used others intellectual property, then I may be liable for
those damages. The problem here is actually with some void entities
that are carefully crafted to avoid those issued. One example is Boost,
you can not make a lawsuit against Boost if some Boost library violates
your intellectual property. You could possibly attempt to go after the
author, but that is very unlikely to give high returns. The next option
is to go after the users. This is a scary scenario for many paranoid
legal departments of those potential users. These lawyers tend to be
listened to by unwise management of those potential users. More often
than they should, such potential users never become more than
potentials. The library is not accessible.

I use the word unwise here because the actual legal risk related to use
of libraries like Boost are extremely small compared to the benefits.
This is however a challenge, and anything we can do to make it simpler
to adapt the good C++ libraries out there need to be considered.

>> g) dependency is not desirable
> On what?

If a candidate library has dependency to other 3'rd party library which
again.... sometimes these never seems to end.

If a candidate library has dependency to other 3'rd party library with
some legal issue incompatible with our product.

If a candidate library has dependency to other 3'rd party library which
some other library we use depend on a different version of....

.... and many other scenarios.

>> h) dependency issues pushed on customer if project is a library
> ? explain

if I make a library. Then it is simpler, much simpler, to depend on
libraries I know comes with the compiler of my customer than to force my
customer to depend on 3'rd party libraries and the exact version of
those picked by me. Note also how I would cause issues in g) above for
my customer.

For open source libraries that can be configured and build by the user
dependency issues like those above can be worked around, but not without
a lot of added complexity.

>> i) conflicting use of names or versions of 3'rd party libs
> And that is different for languages like Java? C++ provides good tools
> for avoiding such problems in the first place (namespaces)

If I use a library that internally uses Boost 1.32.1 and I want to use
Boost 1.34.0. How can I be sure it will work. If I use libraries that
are not header-only it will surely not work. If too much is exposed in
headers, it may fail for other reasons.

Yes proper use of namespaces helps a lot. However better encapsulation
of symbols in modules are needed at the language level. I am hopeful
for this in upcoming C++0x.

Bj�rn Roald

[ See for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]