What's wrong with C++?

What's wrong with C++?

[KK6GM]

This is a serious question, seeking objective information.  I've
worked with C for many years and I have a very good understanding of
its weaknesses, which are many.  I haven't done nearly so much C++,
and what I have done was not very intensive (didn't use a great many C+
+ features), so I don't have a good understanding of its weaknesses.

So, without turning into a bash-fest, what are some general-consensus
weaknesses or failures or problems with C++?  Comparisons with Ada are
welcome but not required.  And my focus is in the embedded & real-time
arenas, FWIW.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/16/2011 12:37 PM, KK6GM wrote:
> This is a serious question, seeking objective information.

Don't you think it would be better to ask in a C++ newsgroup?

But to start the ball rolling, I'd say the worst problem is its
syntax. Since its standard library uses templates extensively,
code can become littered with very difficult to read types.
(This is being addressed in the next revision of the standard.)

There are also actual syntactic ambiguities where a construct
can be parsed in two ways and the correct one can be chosen only
by fiat from the standard.

E.g., in the following, what is the type of X?

     struct s { s(int) { } };
     extern double d;
     int main() { s X(int(d)); }

A second problem is that C++ leaves the order of evaluation of
subexpressions in an expression undefined, unlike Java.

A third is that it has no standard support for concurrent programming,
so such work must be done in an implementation-defined and non-portable
manner.

Re: What's wrong with C++?

[KK6GM]

On Feb 16, 9:58 am, Hyman Rosen <hyro...@mail.com> wrote:
> On 2/16/2011 12:37 PM, KK6GM wrote:
>
> > This is a serious question, seeking objective information.
>
> Don't you think it would be better to ask in a C++ newsgroup?

I'm not at all sure the question would be received and answered as
intended in such a group.  And besides, I am convinced that there are
some people here who are very knowledgeable in the field of language
design, and who can give objective and valid answers.  Some are even
employed by companies that write C++ compilers and related tools.

Thanks for your ball-rolling-start, and I'm sure you will stick around
to make sure any answers are more or less reasonable.

Re: What's wrong with C++?

[Pascal Obry]

Le 16/02/2011 18:37, KK6GM a �crit :
> This is a serious question, seeking objective information.  I've
> worked with C for many years and I have a very good understanding of
> its weaknesses, which are many.  I haven't done nearly so much C++,
> and what I have done was not very intensive (didn't use a great many C+
> + features), so I don't have a good understanding of its weaknesses.

For me C++ is a powerful language but not something I want to use (I 
have used in many projects though) because it is always on the un-secure 
side. Most constructs are dangerous and can corrupt the application. In 
contrast Ada try very hard to stay on the safe side, just have a look at 
Barnes book "Safe and Secure Software".

    http://www.adacore.com/home/ada_answers/ada_2005/safe_secure/

So I won't spot a particular point, C++ and Ada have just followed two 
very different paths.

I choose Ada every time I can because I do not want a language to waste 
my precious time. Some may well say that I'm not talented enough to use 
C++, maybe, or I'm just a human.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: What's wrong with C++?

[Hyman Rosen]

On 2/16/2011 1:32 PM, Pascal Obry wrote:
> just have a look at Barnes book "Safe and Secure Software".
> http://www.adacore.com/home/ada_answers/ada_2005/safe_secure/

I quickly found that it cheats:
<http://www.adacore.com/wp-content/uploads/
2008/04/02_safe_secure_ada_2005_safe_typing.pdf>

In the section where it discusses enumeration types,
it carefully limits itself to discussing C rather
than C++ although it discusses C++ elsewhere so that
it can make the more extreme comparison:

     ...an enumeration type in Ada truly is a different
     type and not a shorthand for an integer type.

In C++ an enumeration type is also a different type and
not a shorthand for an integer type, and its enumeration
literals are of that type.

Re: What's wrong with C++?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> A second problem is that C++ leaves the order of evaluation of
> subexpressions in an expression undefined, unlike Java.

Ada shares this flaw with C++.

The reason is to allow the compiler to choose the most efficient order.
But I think it's possible to design a language that gets the best
of both worlds (allow that sort of efficiency, without the portability
problems).

- Bob

Re: What's wrong with C++?

[KK6GM]

On Feb 16, 11:09 am, Hyman Rosen <hyman.ro...@gmail.com> wrote:
> On 2/16/2011 1:32 PM, Pascal Obry wrote:
>
> > just have a look at Barnes book "Safe and Secure Software".
> >http://www.adacore.com/home/ada_answers/ada_2005/safe_secure/
>
> I quickly found that it cheats:
> <http://www.adacore.com/wp-content/uploads/
> 2008/04/02_safe_secure_ada_2005_safe_typing.pdf>
>
> In the section where it discusses enumeration types,
> it carefully limits itself to discussing C rather
> than C++ although it discusses C++ elsewhere so that
> it can make the more extreme comparison:
>
>      ...an enumeration type in Ada truly is a different
>      type and not a shorthand for an integer type.
>
> In C++ an enumeration type is also a different type and
> not a shorthand for an integer type, and its enumeration
> literals are of that type.

Will a C++ compiler will reject this?

  enum {Red, Green, Blue};
  int x = Red + Green;

You might argue that this is a different issue, but I'm still curious.

Re: What's wrong with C++?

[Fritz Wuehler]

> On 2/16/2011 12:37 PM, KK6GM wrote:
> > This is a serious question, seeking objective information.

C++ and C are both butt-ugly and C++'s operator overloading is stupid. How's
that for some objective info ;)

> A third is that it has no standard support for concurrent programming,
> so such work must be done in an implementation-defined and non-portable
> manner.

The world is full of race conditions and buffer overflows because of those
two languages.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/16/2011 2:36 PM, KK6GM wrote:
> Will a C++ compiler will reject this?
>
>    enum {Red, Green, Blue};
>    int x = Red + Green;
>
> You might argue that this is a different issue, but I'm still curious.

No, it will not, and it is a different issue. The particular
issue here is that enumeration literals in C and C++ have
automatic conversion to integer (but not the other way in C++).

Also, enumerations in C were intended to represent bit masks
as well as sets of values, so in both C and C++ a variable
of enumeration type may correctly hold values that represent
the bitwise-or of any number (including 0) of the literals.
This is legal C++:

    struct DamageType {
        enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
    };

    DamageType::E what_my_dragon_can_do =
        DamageType::E( DamageType::Acid | DamageType::Poison );

    DamageType::E what_your_wimp_can_do = DamageType::E( 0 );

A plausible case can be made that the original incorporation of
enum into C should have distinguished between masks and sets, but
that opportunity is long gone.

Re: What's wrong with C++?

[Hyman Rosen]

On Feb 16, 3:03 pm, Fritz Wuehler
<fr...@spamexpire-201102.rodent.frell.theremailer.net> wrote:
> C++ and C are both butt-ugly and C++'s operator overloading is stupid. How's
> that for some objective info ;)

C++ is ugly; C is not. Operator overloading is extremely good and
useful.

Re: What's wrong with C++?

[Chris Moore]

On 16/02/2011 18:18, KK6GM wrote:
> On Feb 16, 9:58 am, Hyman Rosen <hyro...@mail.com> wrote:
>> On 2/16/2011 12:37 PM, KK6GM wrote:
>>
>>> This is a serious question, seeking objective information.
>>
>> Don't you think it would be better to ask in a C++ newsgroup?
> 
> I'm not at all sure the question would be received and answered as
> intended in such a group.  And besides, I am convinced that there are
> some people here who are very knowledgeable in the field of language
> design, and who can give objective and valid answers.  Some are even
> employed by companies that write C++ compilers and related tools.
> 
> Thanks for your ball-rolling-start, and I'm sure you will stick around
> to make sure any answers are more or less reasonable.

C baggage, lack of readability and threading model outside of the
language are probably the big three from my realtime embedded POV.  This
page also bought back some bad memories :
http://www.cpp-home.com/tutorials/244_1.htm

Re: What's wrong with C++?

[Hyman Rosen]

On Feb 16, 2:35 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Hyman Rosen <hyro...@mail.com> writes:
> > A second problem is that C++ leaves the order of evaluation of
> > subexpressions in an expression undefined, unlike Java.
>
> Ada shares this flaw with C++.
>
> The reason is to allow the compiler to choose the most efficient order.
> But I think it's possible to design a language that gets the best
> of both worlds (allow that sort of efficiency, without the portability
> problems).

I think this reason is misguided. Most expressions do not depend on
their
order of evaluation, so even if the language specified the order the
compiler
could still rearrange things as it wished. It is for those few others
where
consistency rather than efficiency is most important, else programs
stand
the risk of working "accidentally" and then failing mysteriously due
to a
change in environment.

Re: What's wrong with C++?

[Nasser M. Abbasi]

On 2/16/2011 10:32 AM, Pascal Obry wrote:

>
> I choose Ada every time I can because I do not want a language to waste
> my precious time. Some may well say that I'm not talented enough to use
> C++, maybe, or I'm just a human.
>
> Pascal.
>

The following below is probably one of the major problems
with C/C++ environment?

http://en.wikibooks.org/wiki/Ada_Programming/Packages

"Ada uses separate compilation (like Modula-2, Java and C#),
and not independent compilation (as C/C++ does), in which the
various parts are compiled with no knowledge of the other
compilation units with which they will be combined."


--Nasser

Re: What's wrong with C++?

[Hyman Rosen]

On Wednesday, February 16, 2011 3:49:25 PM UTC-5, Nasser M. Abbasi wrote:
> The following below is probably one of the major problems
> with C/C++ environment?
> 
> http://en.wikibooks.org/wiki/Ada_Programming/Packages
> 
> "Ada uses separate compilation (like Modula-2, Java and C#),
> and not independent compilation (as C/C++ does), in which the
> various parts are compiled with no knowledge of the other
> compilation units with which they will be combined."

It's not even clear what this means, let alone why it's a problem.

It sounds like a complaint that C++ requires source inclusion (directly or via preprocessor #include directives) of type and object declarations into a compilation unit, while other languages have syntax for requesting a type set (class, package, etc.) whose definition is then sought out by the compiler in an implementation-dependent way. Personally, I don't find the long strings of 'import ...;' or 'with ...; use ...;' statements any more appealing than '#include "header.h"', but I suppose it's "purer".

Re: What's wrong with C++?

[J-P. Rosen]

Le 16/02/2011 22:12, Hyman Rosen a �crit :
> On Wednesday, February 16, 2011 3:49:25 PM UTC-5, Nasser M. Abbasi wrote:
>> "Ada uses separate compilation (like Modula-2, Java and C#),
>> and not independent compilation (as C/C++ does), in which the
>> various parts are compiled with no knowledge of the other
>> compilation units with which they will be combined."
> 
> It's not even clear what this means, let alone why it's a problem.
> 

The huge difference is that you are not required to use #include in C or
C++. If you want to declare your own prototypes with totally different
types, the compiler will happily let you do it.

"but everybody does use #include!". Sure. But when it comes to safety
critical software, "everybody does it" is not enough. You need guarantees.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Hyman Rosen]

On 2/16/2011 6:07 PM, J-P. Rosen wrote:
> The huge difference is that you are not required to use #include in C or
> C++. If you want to declare your own prototypes with totally different
> types, the compiler will happily let you do it.

Since C++ supports function overloading, declaring a function
with a different prototype declares a different function. If
that function does not exist, the program will fail to build.
(Return types not always included, unfortunately.)

> "but everybody does use #include!". Sure. But when it comes to safety
> critical software, "everybody does it" is not enough. You need guarantees.

Most programmers don't work on safety-critical software, and most
programmers don't indulge in pathologically weird constructs just
for the sake of introducing odd errors into their code. And you
yourself pointed out that (whole) Ada is unsuitable for safety-critical
software!

Re: What's wrong with C++?

[Peter C. Chapin]

On Wed, 16 Feb 2011, Hyman Rosen wrote:

> A third is that it has no standard support for concurrent programming, so 
> such work must be done in an implementation-defined and non-portable 
> manner.

The new C++ standard has concurrency support and many paragraphs have been 
dedicated in the (draft) standard to describing the threading model. 
Something similar to std::thread is available now in Boost and can be used 
with older C++ compilers.

Peter

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/16/11 8:35 PM, Robert A Duff wrote:
> Hyman Rosen<hyrosen@mail.com>  writes:
>
>> A second problem is that C++ leaves the order of evaluation of
>> subexpressions in an expression undefined, unlike Java.
>
> Ada shares this flaw with C++.
>
> The reason is to allow the compiler to choose the most efficient order.
> But I think it's possible to design a language that gets the best
> of both worlds (allow that sort of efficiency, without the portability
> problems).

"As mentioned in the original overview of ParaSail, implicit
parallelism is at the heart of ParaSail (and of its name!).  Every
procedure/function call with multiple parameters involves implicit
parallelism, in that all of the parameters are evaluated in
parallel.  Handoff semantics is used for writable parameters,
meaning that a (non-concurrent) object that is writable by one
parameter evaluation, isn't available to any other parameter
evaluation.  Operations on concurrent objects are not ordered."

http://parasail-programming-language.blogspot.com/2009/10/parasails-implicit-parallelism.html

Re: What's wrong with C++?

[Peter C. Chapin]

On Wed, 16 Feb 2011, Hyman Rosen wrote:

> It sounds like a complaint that C++ requires source inclusion (directly or 
> via preprocessor #include directives) of type and object declarations into 
> a compilation unit, while other languages have syntax for requesting a 
> type set (class, package, etc.) whose definition is then sought out by the 
> compiler in an implementation-dependent way. Personally, I don't find the 
> long strings of 'import ...;' or 'with ...; use ...;' statements any more 
> appealing than '#include "header.h"', but I suppose it's "purer".

C++'s model of #include is a major project because the compiler does not 
really know what is going on and the preprocessor can do arbitrary editing 
of source code. For example

#include <someheader.h>
#include <someotherheader.h>

A macro defined in someheader.h might change the meaning of the declarations 
in someotherheader.h. I've had this happen to me many times... in headers 
that I did not write and over which I have no control. Often the problem can 
be fixed by rearranging the order of #includes or by selectively #undef 
certain macros. However, it's a problem that just shouldn't exist.

Peter

Re: What's wrong with C++?

[Shark8]

On Feb 16, 3:35 pm, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On Wed, 16 Feb 2011, Hyman Rosen wrote:
> > It sounds like a complaint that C++ requires source inclusion (directly or
> > via preprocessor #include directives) of type and object declarations into
> > a compilation unit, while other languages have syntax for requesting a
> > type set (class, package, etc.) whose definition is then sought out by the
> > compiler in an implementation-dependent way. Personally, I don't find the
> > long strings of 'import ...;' or 'with ...; use ...;' statements any more
> > appealing than '#include "header.h"', but I suppose it's "purer".
>
> C++'s model of #include is a major project because the compiler does not
> really know what is going on and the preprocessor can do arbitrary editing
> of source code. For example
>
> #include <someheader.h>
> #include <someotherheader.h>
>
> A macro defined in someheader.h might change the meaning of the declarations
> in someotherheader.h. I've had this happen to me many times... in headers
> that I did not write and over which I have no control. Often the problem can
> be fixed by rearranging the order of #includes or by selectively #undef
> certain macros. However, it's a problem that just shouldn't exist.
>
> Peter

Also, one can use precisely that behavior to crash the pre-processor:
//Test.h
#include <test.h>

Re: What's wrong with C++?

[Mike Sieweke]

 KK6GM <mjsilva@scriptoriumdesigns.com> wrote:

> So, without turning into a bash-fest, what are some general-consensus
> weaknesses or failures or problems with C++?  Comparisons with Ada are
> welcome but not required.  And my focus is in the embedded & real-time
> arenas, FWIW.

The flaws in C++ are too numerous for a newsgroup posting.
A bullet list would run into several pages.

You should read Ian Joyner's critique:
http://www.zechweb.de/Joyners_cpp_critique/

You should also read the C++ FQA (frequently questioned answers)
by Yossi Kreinin:
http://www.yosefk.com/c++fqa/index.html

Do a Google search for "dark side of C++" and you'll find
even more.  This one seems especially interesting:
http://port70.net/~nsz/16_c++.html

-- Mike Sieweke
-- "Just a bit of harmless brain alteration, that's all..."

Re: What's wrong with C++?

[Ludovic Brenta]

KK6GM wrote on comp.lang.ada:
> This is a serious question, seeking objective information.  I've
> worked with C for many years and I have a very good understanding of
> its weaknesses, which are many.  I haven't done nearly so much C++,
> and what I have done was not very intensive (didn't use a great many C+
> + features), so I don't have a good understanding of its weaknesses.
>
> So, without turning into a bash-fest, what are some general-consensus
> weaknesses or failures or problems with C++?  Comparisons with Ada are
> welcome but not required.  And my focus is in the embedded & real-time
> arenas, FWIW.

Besides the other flaws mentioned in this thread, C++ lacks the
equivalent of Ada's named access types.

type T is record
   null;
end record;

type T_Access_One is access T;
for T_Access_One'Storage_Pool use Pool_One;

type T_Access_Two is access T;
for T_Access_Two'Storage_Pool use Pool_Two;

In Ada, the two named access types are incompatible with one another;
they have no structural equivalence.  Also you can declare the access
types in a nested scope such that the compiler will detect any
pointers leaking out of that scope.

And don't get me started on the address arithmetic in C++...

(I don't like anonymous access types at all, neither in C++ nor in
Ada).

The ISO technical report TR 24772:2010 about programming language
vulnerabilities[1] should be the definitive reference.  The appendices
for Ada and SPARK are already complete and have been published in the
Ada User Journal[2] and in the SIGAda Letters.  I wonder what the
status of the C++ appendix is.  Does anyone here know?

[1] http://www.iso.org/iso/catalogue_detail.htm?csnumber=41542
[2] http://www.ada-europe.org/AUJ/index.html
The Ada appendix is in Volume 31, Issue 3 (September 2010)
The SPARK appendix is in Volume 31, Issue 4 (December 2010)

--
Ludovic Brenta.

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 00:31:52 -0800 (PST), Ludovic Brenta wrote:

> In Ada, the two named access types are incompatible with one another;
> they have no structural equivalence.

The flaw here is structural equivalence and, more generally, type
inference. Not everybody agree that type inference is bad. I do believe
that it is.

Note that Ada 95/2005/201x keep on moving towards more inference. I guess
that the reason for that is the easiness one could patch certain language
deficiencies per inference here and there, without reconsidering the
underlying [serious] problems.

> (I don't like anonymous access types at all, neither in C++ nor in
> Ada).

It puzzles me that nobody said anything in favor of anonymous access types,
yet they are here. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[J-P. Rosen]

Le 17/02/2011 00:35, Peter C. Chapin a �crit :
> A macro defined in someheader.h might change the meaning of the
> declarations in someotherheader.h. 
And especially the following one:
#define private public

Great for those who think that information hiding is a nuisance!

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Ludovic Brenta]

KK6GM wrote on comp.lang.ada:
> This is a serious question, seeking objective information.  I've
> worked with C for many years and I have a very good understanding of
> its weaknesses, which are many.  I haven't done nearly so much C++,
> and what I have done was not very intensive (didn't use a great many C+
> + features), so I don't have a good understanding of its weaknesses.
>
> So, without turning into a bash-fest, what are some general-consensus
> weaknesses or failures or problems with C++?  Comparisons with Ada are
> welcome but not required.  And my focus is in the embedded & real-time
> arenas, FWIW.

The keyword "virtual".

If you forget it, you get static dispatching instead of dynamic
dispatching and the compiler cannot tell you whether that's right or
wrong.  In Ada, any primitive operation of a tagged type is implicitly
and automatically "virtual", so you can't forget the keyword.  In C++,
one particular case of this language flaw is that you can forget to
make your destructors virtual; good luck debugging that later.

In C++, looking at the spec of a derived class, you can't tell which
methods are virtual (because they override an inherited virtual
method) and which are not.  You have to look at all the ancestor
classes to know.  In Ada, you can tell immediately without looking up
any ancestor types.

In C++, looking at a method call, you can't tell whether it dispatches
statically (non-virtual method) or dynamically (virtual method); you
must look it up in the declaration of the class *and* all its
ancestors.  In Ada, you can tell immediately: a call dispatches
statically if the actual parameter is of a specific type, and
dynamically if of a class-wide type.

In C++, you are required to use pointers or references to objects to
achieve dynamic dispatching.  This is wrong.  Pointers and references
should only be used for dynamic memory management and links between
objects, just like they are in Ada.  I find the following quite
confusing:

class C { virtual void foo(); };

C c;
c.foo(); // static dispatch
(&c)->foo(); // dynamic dispatch

The reason for this is that, in C++, all (implicitly declared) pointer
and reference types are (implicitly and always) class-wide, so always
dispatch dynamically; in contrast, objects are always of a specific
type, so cannot dispatch dynamically.  In Ada, the two concepts are
orthogonal; access types can be either specific or class-wide, and
types of objects can also be specific or class-wide.

--
Ludovic Brenta.

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/17/11 12:04 PM, J-P. Rosen wrote:
> Le 17/02/2011 00:35, Peter C. Chapin a �crit :
>> A macro defined in someheader.h might change the meaning of the
>> declarations in someotherheader.h.
> And especially the following one:
> #define private public
>
> Great for those who think that information hiding is a nuisance!

It is good to know that source code transformation
can change the meaning of source text.  I don't think
this argument will convince.  Is there substantial evidence
of programs that #define private to be public? Might be.
The change is a conventional trick to use with introspective
languages, and useful.

But anyway, the argument is easily refuted as by
firing this riposte:

procedure Safe is

     function "+" (Left, Right: Integer) return Integer is
     begin
         return 0;
     end "+";

     A : array (Integer range 1 .. 2) of Integer;
begin
     for K in A'Range loop
         A (A'First + K - 1) := 666;
     end loop;
end Safe;


Make "+" a little more obscure (if possible) and have
a proponent of Ada look for the error...


Or talk about the possibility (or not) of changing the
definition of Integer temporarily to a debugging version
of Integer whose operations we can trace.

Re: What's wrong with C++?

[Peter C. Chapin]

On Wed, 16 Feb 2011, Mike Sieweke wrote:

> The flaws in C++ are too numerous for a newsgroup posting.
> A bullet list would run into several pages.
>
> You should read Ian Joyner's critique:
> http://www.zechweb.de/Joyners_cpp_critique/

I have a lot of problems with that critique. I wouldn't recommend it to 
anyone. I don't think the author really understands C++ and thus is 
attacking a straw man created in his own mind.

I actually wrote a longish rebuttal to that document. I could post it 
somewhere if people care.

Peter

Re: What's wrong with C++?

[Peter C. Chapin]

On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote:

> The flaw here is structural equivalence and, more generally, type 
> inference. Not everybody agree that type inference is bad. I do believe 
> that it is.

Could you elaborate a little on why you think type inference is bad? In the 
functional languages that support it, type inference is completely type safe 
(for example: Haskell, OCaml, Scala). Perhaps you mean something different.

I do agree that type annotations can be useful documentation for the 
programmer trying to read the program, but a program won't "go wrong" 
because of type inference.

Peter

Re: What's wrong with C++?

[J-P. Rosen]

Le 17/02/2011 12:52, Georg Bauhaus a �crit :
> But anyway, the argument is easily refuted as by
> firing this riposte:
> 
> procedure Safe is
> 
>     function "+" (Left, Right: Integer) return Integer is
>     begin
>         return 0;
>     end "+";
> 
>     A : array (Integer range 1 .. 2) of Integer;
> begin
>     for K in A'Range loop
>         A (A'First + K - 1) := 666;
>     end loop;
> end Safe;
> 
> 
> Make "+" a little more obscure (if possible) and have
> a proponent of Ada look for the error...
> 
> 
> Or talk about the possibility (or not) of changing the
> definition of Integer temporarily to a debugging version
> of Integer whose operations we can trace.
> 
Of course, any feature can be misused. I once met in a program:
Thousand : constant := 10_000;

And of course, later there was:
   for I in 1..Thousand loop...

You could argue from this that named numbers should never be used.

Back to the point, the big difference is that with macros, you can't
assume the meaning of something at a given point of text. While in Ada,
you can always point to an entity, then "goto declaration" (assuming a
decent environment, like Emacs or GPS), and then you know the truth.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Hyman Rosen]

On 2/16/2011 10:41 PM, Mike Sieweke wrote:
> You should read Ian Joyner's critique:
> http://www.zechweb.de/Joyners_cpp_critique/

"C++ is bad because it isn't Eiffel."

> You should also read the C++ FQA (frequently questioned answers)
> by Yossi Kreinin:
> http://www.yosefk.com/c++fqa/index.html

"C++ is bad because it isn't Java."

> Do a Google search for "dark side of C++" and you'll find
> even more.  This one seems especially interesting:
> http://port70.net/~nsz/16_c++.html

"C++ is bad because it's C" (OK, not entirely, but I wanted
to keep up the pattern :-) Actually, this last one has:

     Paul Graham (2001)
     [..] Historically, languages designed for other people to
     use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good
     languages have been those that were designed for their own
     creators: C, Perl, Smalltalk, Lisp. [..]

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 08:38:25 -0500, Peter C. Chapin wrote:

> On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote:
> 
>> The flaw here is structural equivalence and, more generally, type 
>> inference. Not everybody agree that type inference is bad. I do believe 
>> that it is.
> 
> Could you elaborate a little on why you think type inference is bad? In the 
> functional languages that support it, type inference is completely type safe 
> (for example: Haskell, OCaml, Scala). Perhaps you mean something different.

The first notice is that inferred types cannot be safe per definition.
There is no additional information involved. What is inferred, already is.
To me safety is when some a-priori information unknown to the compiler (and
to the language designers) is used to detect sematic problems.

The second note is that if types are not the things from the problem space
(of which the compiler knows little or nothing), then what kind of stuff is
there in their place? I presume that nothing.

The third note is that if inferred, then why should we care of types?
Anything that goes automatically does not bother me. I should care of
something else: cryptic declarative language constructs of sematic, which
cannot be clearly recognized.

Now the main objection is computability and decidability. Only "simple"
things can be inferred. The compiler cannot solve problems beyond
Turing-completeness. The most problem spaces are out compiler's reach, and
if they weren't we would need to program anyway. Since there is a
programmer here, then how inference made by the compiler correlate with the
inference done by the program reader. Do they infer same things from same
code? I bet they don't if inference is non-trivial. How is it better than
hexadecimal code, anybody is free to infer whatever he wants from it. This
returns us to the second note. What is the metalanguage here if not the
language of types, expressing incomputable semantics?

> I do agree that type annotations can be useful documentation for the 
> programmer trying to read the program, but a program won't "go wrong" 
> because of type inference.

It won't, but maybe just because there is no way to determine what it
actually does. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 11:12 AM, Dmitry A. Kazakov wrote:
> On Thu, 17 Feb 2011 08:38:25 -0500, Peter C. Chapin wrote:
>> Could you elaborate a little on why you think type inference is bad?
>
>A variety of objections...

And your objections are wrong because there are plenty
of types that can usefully be inferred by the compiler
and which can be written by the programmer only with
difficulty (at least in C++). Iterators over containers
are a prime example. If I have a C++ map<string, int>
and I look something up, I have to declare
     map<string, int>::iterator i = my_map.find("hello");
But that's silly - the compiler knows what type that
function returns, and it has a better chance of getting
it right than I do:
     auto i = my_map.find("hello");
will be supported by soon-to-be-standard C++. For now,
people dedicated to not sprinkling their code with these
iterator types have to push to a type-inferring template:
     template <typename T> void do_something(T i);
     do_something(my_map.find("hello"));

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 9:30 AM, J-P. Rosen wrote:
> Of course, any feature can be misused.
...
> Back to the point, the big difference is that with macros, you can't
> assume the meaning of something at a given point of text.

There in a nutshell is what all language wars come to:
My favorite language has powerful features which could
be misused, but no one would do that. Your favorite
language has unfortunate features which render all
programs written in it unreliable and incomprehensible.

Re: What's wrong with C++?

[Peter C. Chapin]

On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote:

>> Could you elaborate a little on why you think type inference is bad? In 
>> the functional languages that support it, type inference is completely 
>> type safe (for example: Haskell, OCaml, Scala). Perhaps you mean 
>> something different.
>
> The first notice is that inferred types cannot be safe per definition.
> There is no additional information involved. What is inferred, already is.
> To me safety is when some a-priori information unknown to the compiler (and
> to the language designers) is used to detect sematic problems.

I understand this point. I believe you are saying that types are part of the 
program's design and thus asserting them in the program explicitly (and 
having the compiler check the resulting code) brings information from the 
design into the compiler's view.

> The second note is that if types are not the things from the problem space 
> (of which the compiler knows little or nothing), then what kind of stuff 
> is there in their place? I presume that nothing.

You can still define the types you need. Inference just means that you 
typically don't have to bother with explicit declarations: create the 
objects you need (of the types you need) and let the compiler work out the 
details.

> Now the main objection is computability and decidability. Only "simple" 
> things can be inferred. The compiler cannot solve problems beyond 
> Turing-completeness...

It sounds like you are taking "type inference" to mean that the compiler 
figures out pre-conditions, post-conditions, etc. I'm just talking about the 
compiler recovering type information based on how entities are used. For 
example, in OCaml:

let rec sum_items alist =
   match alist with
      [] -> 0
    | head::tail -> head + (sum_items tail)

The compiler infers that sum_items is a function taking a list of ints and 
returning an int. It does this by looking at what the code does: mylist is 
being matched against a list pattern. The head element of the list is an int 
because of its use with +. The branches of the match both agree in their 
type (int) which is the type returned by the function which is consistent 
with its use in the summation operation.

The algorithms for doing this are well understood and they are decidable. On 
the other hand there are undecidable type systems, it's true. I've heard it 
said that Scala's type system is undecidable. However, nobody much cares 
because the programs that force the type checker into nontermination are so 
weird that no normal developer would ever write them (so it is claimed).

Peter

Re: What's wrong with C++?

[Martin]

On Feb 17, 3:30 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 2/16/2011 10:41 PM, Mike Sieweke wrote:
>
> > You should read Ian Joyner's critique:
> >http://www.zechweb.de/Joyners_cpp_critique/
>
> "C++ is bad because it isn't Eiffel."
>
> > You should also read the C++ FQA (frequently questioned answers)
> > by Yossi Kreinin:
> >http://www.yosefk.com/c++fqa/index.html
>
> "C++ is bad because it isn't Java."
>
> > Do a Google search for "dark side of C++" and you'll find
> > even more.  This one seems especially interesting:
> >http://port70.net/~nsz/16_c++.html
>
> "C++ is bad because it's C" (OK, not entirely, but I wanted
> to keep up the pattern :-) Actually, this last one has:
>
>      Paul Graham (2001)
>      [..] Historically, languages designed for other people to
>      use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good
>      languages have been those that were designed for their own
>      creators: C, Perl, Smalltalk, Lisp. [..]


Sometimes though there is something better than opinion as to what
language produces more reliable systems...

...but I couldn't possibly comment on what language usually comes out
better! ;-)

-- Martin

Re: What's wrong with C++?

[Peter C. Chapin]

On Thu, 17 Feb 2011, Hyman Rosen wrote:

> There in a nutshell is what all language wars come to: My favorite 
> language has powerful features which could be misused, but no one would do 
> that. Your favorite language has unfortunate features which render all 
> programs written in it unreliable and incomprehensible.

Yes, you can write excellent software in any reasonable language and you can 
write bad software in any reasonable language. The rest is just details. :)

Peter

Re: What's wrong with C++?

[Paul Colin Gloster]

Fritz Wuehler sent:

|----------------------------------------------------------------------------|
|"[..]                                                                       |
|                                                                            |
|C++ and C are both butt-ugly"                                               |
|----------------------------------------------------------------------------|

Yes.

|----------------------------------------------------------------------------|
|" and C++'s operator overloading is stupid. [..]                            |
|[..]                                                                        |
|                                                                            |
|[..]"                                                                       |
|----------------------------------------------------------------------------|

Do you also dislike Ada's operator overloading?

Regards,
Paul Colin Gloster

Re: What's wrong with C++?

[Georg Bauhaus]

On 17.02.11 17:25, Hyman Rosen wrote:
> If I have a C++ map<string, int>
> and I look something up, I have to declare
>     map<string, int>::iterator i = my_map.find("hello");
> But that's silly - the compiler knows what type that
> function returns, and it has a better chance of getting
> it right than I do:
>     auto i = my_map.find("hello");

Can I have

   auto iterator i = ...;

too, assuming iterator denotes a common iterator type?
This will allow me to know what type i is without having
to do the inference myself!

Ada.Containers' Cursor doesn't have a centrally
declared interface, just like iterator; some have filed
complaints about this.  Why is it that, seemingly, everybody
in the compiler makers guild is so fond of omissions boiling
down to obfuscation or bragging about inferential skills?
Programming is neither selling small print nor omissions.
Or, wait!  Is it?

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 12:46 PM, Georg Bauhaus wrote:
> Can I have
>     auto iterator i = ...;
> too, assuming iterator denotes a common iterator type?
> This will allow me to know what type i is without having
> to do the inference myself!

No, but you can say
     auto map_iterator = my_map.find("x");
so your variable names will guide your understanding.
You do that in Ada anyway, since the variable can be
used far away from its declaration.

> Ada.Containers' Cursor doesn't have a centrally
> declared interface, just like iterator; some have filed
> complaints about this.  Why is it that, seemingly, everybody
> in the compiler makers guild is so fond of omissions boiling
> down to obfuscation or bragging about inferential skills?
> Programming is neither selling small print nor omissions.
> Or, wait!  Is it?

C++ is very susceptible to horrible runaway type names because
it does have automatic instantiation of templates, and especially
in the presence of template metaprogramming. Without automatic
instantiation and partial specialization, Ada has rather less need
for this. (Which does not mean C++ is bad, just different.)

In C++, expression templates can be used to build up parse trees
from expressions rather than having them be evaluated, and the
type of such an expression is a nested cascaded monstrosity that
is essentially impossible for a human to write correctly. Such
results can be held by a pointer or reference to a base class,
but the compiler can just infer the right type without need for
that.

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 11:25:13 -0500, Hyman Rosen wrote:

> On 2/17/2011 11:12 AM, Dmitry A. Kazakov wrote:
>> On Thu, 17 Feb 2011 08:38:25 -0500, Peter C. Chapin wrote:
>>> Could you elaborate a little on why you think type inference is bad?
>>
>>A variety of objections...
> 
> And your objections are wrong because there are plenty
> of types that can usefully be inferred by the compiler

Yes, some trivial subtypes like "in T", "out T", "in out T". But I want no
non-trivial inference. "access T" is already too much.

> and which can be written by the programmer only with
> difficulty (at least in C++). Iterators over containers
> are a prime example.

No need to have iterators, indices do the job. I want the index type
manifested when the container type is declared, just as Ada 83 does when an
array is declared.

> If I have a C++ map<string, int>
> and I look something up, I have to declare

I want an array here. STL was a wrong idea and I don't like Ada.Containers
following it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 12:27:11 -0500, Peter C. Chapin wrote:

> On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote:
> 
>> The second note is that if types are not the things from the problem space 
>> (of which the compiler knows little or nothing), then what kind of stuff 
>> is there in their place? I presume that nothing.
> 
> You can still define the types you need. Inference just means that you 
> typically don't have to bother with explicit declarations: create the 
> objects you need (of the types you need) and let the compiler work out the 
> details.

How the compiler may know that 1.7 is magnetic flux? I don't mean if the
compiler derive type constraints:

   Text : String := "abcd";

That is OK to me.

>> Now the main objection is computability and decidability. Only "simple" 
>> things can be inferred. The compiler cannot solve problems beyond 
>> Turing-completeness...
> 
> It sounds like you are taking "type inference" to mean that the compiler 
> figures out pre-conditions, post-conditions, etc. I'm just talking about the 
> compiler recovering type information based on how entities are used.

I doubt this were possible in a rich type system where types are
consistently cloned. E.g. in Ada:

   type My_Integer is new Integer;

The properties of both types are same. The above is a typical case of
reuse. It seems that reuse is incompatible with inference. There is nothing
that tells us that two things are indeed same or not. Maybe the same would
be inferred from both, maybe not, how do I know?

BTW, inference is incompatible with information hiding and modularity. In
order to infer you have to lay everything open, not a good software
engineering practice. Even if you say that inferring were optional. Let
some part of the system rely on that "optional" inference. That
automatically makes it mandatory. What happens if in the process of
maintenance inferring stop working because of small incremental changes?

> The algorithms for doing this are well understood and they are decidable.

Maybe, like pattern matching is, decidable but incomprehensive. It is
impossible for the reader to guess the language matched by given pattern.
The program shall be understandably by small incremental efforts on the
reader side. Non-trivial inference requires qualitative jumps, either you
can infer what the compiler does or not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Wed, 16 Feb 2011 21:07:02 +0100, Hyman Rosen <hyman.rosen@gmail.com> a  
écrit:
> This is legal C++:
>
>     struct DamageType {
>         enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
>     };
>
>     DamageType::E what_my_dragon_can_do =
>         DamageType::E( DamageType::Acid | DamageType::Poison );

I forget C++ for long I am not aware of its updates since this time. Does  
what you wrote mean C++ can restict the possible value of an enumeration ?  
Can derive subsets ?

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 04:41:10 +0100, Mike Sieweke <msieweke@ix.netcom.com>  
a écrit:

>  KK6GM <mjsilva@scriptoriumdesigns.com> wrote:
>
>> So, without turning into a bash-fest, what are some general-consensus
>> weaknesses or failures or problems with C++?  Comparisons with Ada are
>> welcome but not required.  And my focus is in the embedded & real-time
>> arenas, FWIW.
>
> The flaws in C++ are too numerous for a newsgroup posting.
> A bullet list would run into several pages.
>
> You should read Ian Joyner's critique:
> http://www.zechweb.de/Joyners_cpp_critique/
>
> You should also read the C++ FQA (frequently questioned answers)
> by Yossi Kreinin:
> http://www.yosefk.com/c++fqa/index.html
>
> Do a Google search for "dark side of C++" and you'll find
> even more.  This one seems especially interesting:
> http://port70.net/~nsz/16_c++.html
>
> -- Mike Sieweke
> -- "Just a bit of harmless brain alteration, that's all..."

At least, we could reasonably admit there is not so much literatures about  
Ada miss-conceptions (or may one could argue that's only because Ada is  
less popular than C++ ?).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Ludovic Brenta]

Yannick Duchêne writes on comp.lang.ada:
> Le Wed, 16 Feb 2011 21:07:02 +0100, Hyman Rosen
> <hyman.rosen@gmail.com> a écrit:
>> This is legal C++:
>>
>>     struct DamageType {
>>         enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
>>     };
>>
>>     DamageType::E what_my_dragon_can_do =
>>         DamageType::E( DamageType::Acid | DamageType::Poison );
>
> I forget C++ for long I am not aware of its updates since this
> time. Does what you wrote mean C++ can restict the possible value of
> an enumeration ?  Can derive subsets ?

No, it only means that enumerations in C++ really are integers and not
enumerations.  Otherwise, how could the value Acid | Poison be in the
set { Fire, Acid, Lightning, Poison } ?

Hyman explained that enum values can be "promoted" automatically to int,
but now he's just shown that ints such as the result of the bitwise OR
of two enum values can also be "promoted" automatically to an enum type.

Blech.

-- 
Ludovic Brenta.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 16:30:25 +0100, Hyman Rosen <hyrosen@mail.com> a écrit:
>      Paul Graham (2001)
>      [..] Historically, languages designed for other people to
>      use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good
>      languages have been those that were designed for their own
>      creators: C, Perl, Smalltalk, Lisp. [..]

Actually, Lisp was not designed for its creator; it was the result of a  
formalisation, directly inspired by something similar to what Ada Lovelace  
did ;) It comes with curryfication also, which is really a formal thing,  
not a kind of language sugar.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 19:53:17 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> No, it only means that enumerations in C++ really are integers and not
> enumerations.  Otherwise, how could the value Acid | Poison be in the
> set { Fire, Acid, Lightning, Poison } ?
OK, thanks. I was foolished by the syntax, and though the notation meant a  
set of two items. So this was the bitwise-or only.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 10:02:58 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> The flaw here is structural equivalence and, more generally, type
> inference. Not everybody agree that type inference is bad. I do believe
> that it is.

I personally believe type inference (within a typed language), is good  
when that is used to tersely write models of an application. That is what  
(S)ML en derivatives do.

> Note that Ada 95/2005/201x keep on moving towards more inference. I guess
> that the reason for that is the easiness one could patch certain language
> deficiencies per inference here and there, without reconsidering the
> underlying [serious] problems.

On the contrary, I will not expect Ada to be of that kind : it should  
remain an efficient and safe implementation language.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 14:38:25 +0100, Peter C. Chapin <PChapin@vtc.vsc.edu>  
a écrit:

> In the functional languages that support it, type inference is  
> completely type safe (for example: Haskell, OCaml, Scala). Perhaps you  
> mean something different.

Right; as an example, SML was formally proven to be consistent [*]... and  
it is strongly typed with type inference.

[*] SML was formally specified even before its first implementation (I  
believe Bertrand Meyer had enjoyed such a statu). The first document about  
SML was that formal proof, even prior to the second document specifying it  
in a more human readable way.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 17:12:37 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> The first notice is that inferred types cannot be safe per definition.
> There is no additional information involved. What is inferred, already  
> is.

You are confused between safe by readability and safe by predictability ;)

I agree type inference may leads to less readable texts, and that is why I  
prefer this to be used for formal modeling only. But this is still safe,  
although not from a most common human point of view.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 17:12:37 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> The third note is that if inferred, then why should we care of types?
No, you have to care, and you still define types. You just don't have to  
be so much redundant as you would be with, say, Ada. This is required with  
functional language where you do not use side-effect (there may be some  
side effect in SML which is not stricly pure, but you may not use side  
effects as long as you don't want), where function returns rather complex  
types and get numerous parameters which are as much complexes. Without  
type inference... functional program texts would simply be an unreadable  
mess (:-))

> Now the main objection is computability and decidability. Only "simple"
> things can be inferred. The compiler cannot solve problems beyond
> Turing-completeness.
Actually, SML interpreters are required to complain if ever that occurs,  
and the program will not start at all. So there is nothing like such a  
problem.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 1:48 PM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 16 Feb 2011 21:07:02 +0100, Hyman Rosen <hyman.rosen@gmail.com> a écrit:
>> This is legal C++:
>>
>> struct DamageType {
>> enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
>> };
>>
>> DamageType::E what_my_dragon_can_do =
>> DamageType::E( DamageType::Acid | DamageType::Poison );
>
> I forget C++ for long I am not aware of its updates since this time.
 > Does what you wrote mean C++ can restict the possible value of an
 > enumeration ? Can derive subsets ?

The standard says in 7.2/6:
     For an enumeration where emin is the smallest enumerator and emax
     is the largest, the values of the enumeration are the values of the
     underlying type in the range bmin to bmax, where bmin and bmax are,
     respectively, the smallest and largest values of the smallest bit-
     field that can store emin and emax. (On a two's-complement machine,
     bmax is the smallest value greater than or equal to
     max(abs(emin)-1,abs(emax)) of the form 2^M-1; bmin is zero if emin
     is non-negative and -(bmax+1) otherwise.)

The implementation is not required to check for out of range values (of
course) and you cannot derive subsets in the way of Ada subtypes.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 1:53 PM, Ludovic Brenta wrote:
> No, it only means that enumerations in C++ really are integers
 > and not enumerations.

This was a choice made by the people who incorporated enumerations
into C. They felt it important that enumerations should be usable
in the style of bitmasks. And what does it mean for something to be
"really an integer"? Ada 'Pos and 'Val attributes certainly give
the illusion that Ada enumerators are integers too!

Re: What's wrong with C++?

[Ludovic Brenta]

Hyman Rosen <hyrosen@mail.com> writes:
> On 2/17/2011 1:53 PM, Ludovic Brenta wrote:
>> No, it only means that enumerations in C++ really are integers
>> and not enumerations.
>
> This was a choice made by the people who incorporated enumerations
> into C. They felt it important that enumerations should be usable
> in the style of bitmasks. And what does it mean for something to be
> "really an integer"?

Simple: integers have arithmetic, enumeration values don't.

> Ada 'Pos and 'Val attributes certainly give the illusion that Ada
> enumerators are integers too!

If you mean to say that Ada provides features for unsafe programming,
then if course we all knew that.  Ada also has overlays and machine code
insertions that allow the programmer to do anything they please.

Now try this and see your "illusion" shattered by reality:

type E is (A, B, C);
B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error

In this respect like in many others, Ada is safe by default and unsafe
if the programmer really wants that.

-- 
Ludovic Brenta.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 2:55 PM, Ludovic Brenta wrote:
> Hyman Rosen<hyrosen@mail.com>  writes:
>> And what does it mean for something to be
>> "really an integer"?
>
> Simple: integers have arithmetic, enumeration values don't.

C and C++ enumerations don't have arithmetic.
They do convert automatically to integers, but
they don't automatically convert back.

>> Ada 'Pos and 'Val attributes certainly give the illusion that Ada
>> enumerators are integers too!
>
> If you mean to say that Ada provides features for unsafe programming,

Not at all, merely that it's easy within the language to
convert back and forth between enumerations and integers.
Nothing unsafe about it.

> Now try this and see your "illusion" shattered by reality:
> type E is (A, B, C);
> B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error

What illusion? I certainly know that Ada checks and C doesn't!

Oh, and don't Ada implementers go insane because enumerations
are supposed to provide the illusion of being consecutive even
in the face of representation clauses which give them arbitrary
underlying values?

Also, I don't know if you did this intentionally or not, but
you redefine the name B as a variable when it is already an
enumeration literal. Do I recall correctly that this works
because enumeration literals are "really" functions returning
their value, and functions can be overloaded?

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 20:38:04 +0100, Hyman Rosen <hyrosen@mail.com> a écrit:
> Ada 'Pos and 'Val attributes certainly give
> the illusion that Ada enumerators are integers too!
That's Universal Integer, which is not the same as Integer.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 3:32 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 20:38:04 +0100, Hyman Rosen <hyrosen@mail.com> a écrit:
>> Ada 'Pos and 'Val attributes certainly give
>> the illusion that Ada enumerators are integers too!
> That's Universal Integer, which is not the same as Integer.

I didn't say "Integer", I said "integers". I'm not case-insensitive.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 12:51:14 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> In Ada, the two concepts are
> orthogonal; access types can be either specific or class-wide, and
> types of objects can also be specific or class-wide.
Yes. And that makes the difference between classes and types clear  
(another point some languages theoreticians had probably enjoyed).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/17/11 8:19 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 10:02:58 +0100, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit:
>> The flaw here is structural equivalence and, more generally, type
>> inference. Not everybody agree that type inference is bad. I do believe
>> that it is.
>
> I personally believe type inference (within a typed language), is good when that is used to tersely write models of an application. That is what (S)ML en derivatives do.

Oddly enough, it is good practice to *not* play the inference
game when creating "models" in ML languages:  when ML programmers
describe a structure or type, they use type names explicitly.
Every function is written in terms of its (typed) profile,
not just the names.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 00:07:50 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:
> "but everybody does use #include!". Sure. But when it comes to safety
> critical software, "everybody does it" is not enough. You need  
> guarantees.
A question on margin: did C++ really dropped implicit declarations ? I  
heard to say so, while I'm not sure it is (and I don't remember neither,  
because I never enjoyed implicit declarations so never played with these).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Ludovic Brenta]

Hyman Rosen <hyrosen@mail.com> writes:
> On 2/17/2011 2:55 PM, Ludovic Brenta wrote:
>> Hyman Rosen<hyrosen@mail.com>  writes:
>>> And what does it mean for something to be
>>> "really an integer"?
>>
>> Simple: integers have arithmetic, enumeration values don't.
>
> C and C++ enumerations don't have arithmetic.
> They do convert automatically to integers, but
> they don't automatically convert back.

Actually they do in the example you provided:

    struct DamageType {
        enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
    };

    DamageType::E what_my_dragon_can_do =
        DamageType::E( DamageType::Acid | DamageType::Poison );

In this example, the two enumeration values are automatically promoted
to integer (which has arithmetic) ORed, then the result is automatically
converted back to the type DamageType::E.  Except that the value of
what_my_dragon_can_do is not one of the values defined in the type.

>>> Ada 'Pos and 'Val attributes certainly give the illusion that Ada
>>> enumerators are integers too!
>>
>> If you mean to say that Ada provides features for unsafe programming,
>
> Not at all, merely that it's easy within the language to convert back
> and forth between enumerations and integers.  Nothing unsafe about it.

Actually, there is something unsafe about it.  Ada programmers have both
integers and enumerations; they choose enumerations when arithmetic does
not make sense.  Converting enumerations to integers provides
arithmetic, which is unsafe for these types.  Actually, the only really
dangerous part is converting back to the enumeration type using 'Val.

>> Now try this and see your "illusion" shattered by reality:
>> type E is (A, B, C);
>> B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error
>
> What illusion? I certainly know that Ada checks and C doesn't!

I meant the intentional illusion that you can treat enumerated values
like integers; you can't.

> Oh, and don't Ada implementers go insane because enumerations are
> supposed to provide the illusion of being consecutive even in the face
> of representation clauses which give them arbitrary underlying values?

The consecutiveness is embedded in the operations 'Pred and 'Succ, not
by 'Pos and 'Val.  It is true that validity checking is much more
difficult when the set of valid values is disjoint.  But it is a good
thing that compilers provide this functionality, instead of programmers
having to re-implement it each time.

> Also, I don't know if you did this intentionally or not, but you
> redefine the name B as a variable when it is already an enumeration
> literal. Do I recall correctly that this works because enumeration
> literals are "really" functions returning their value, and functions
> can be overloaded?

That was not intentional; my code doesn't compile.  Thanks for pointing
that out.

-- 
Ludovic Brenta.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 04:35:46 +0100, Shark8 <onewingedshark@gmail.com> a  
écrit:
> Also, one can use precisely that behavior to crash the pre-processor:
> //Test.h
> #include <test.h>
If I'm not wrong, this is implementation specific, and GCC's preprocessor  
reject circular dependencies.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 3:51 PM, Yannick Duchêne (Hibou57) wrote:
> A question on margin: did C++ really dropped implicit declarations ?

Yes.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 12:04:00 +0100, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 17/02/2011 00:35, Peter C. Chapin a écrit :
>> A macro defined in someheader.h might change the meaning of the
>> declarations in someotherheader.h.
> And especially the following one:
> #define private public
>
> Great for those who think that information hiding is a nuisance!

I am not joking here : at the time I learned C/C++, I hired a book from a  
library, which was proudly stating C/C++ macros are so much powerful (sic)  
that one may "#define BEGIN {", "#define END }" and so on, so as to  
happily write BASIC in C/C++ ! And that was not a book playing the fool on  
C/C++, that book was promoting C/C++.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 12:52:53 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> But anyway, the argument is easily refuted as by
> firing this riposte:
>
> procedure Safe is
>
>      function "+" (Left, Right: Integer) return Integer is
>      begin
>          return 0;
>      end "+";
>
>      A : array (Integer range 1 .. 2) of Integer;
> begin
>      for K in A'Range loop
>          A (A'First + K - 1) := 666;
>      end loop;
> end Safe;
>
>
> Make "+" a little more obscure (if possible) and have
> a proponent of Ada look for the error...

Here, Ada 2012's pre-post-conditions comes in the playground ;)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 3:51 PM, Ludovic Brenta wrote:
> Hyman Rosen<hyrosen@mail.com>  writes:
>> C and C++ enumerations don't have arithmetic.
>> They do convert automatically to integers, but
>> they don't automatically convert back.
>
> Actually they do in the example you provided:
>
>      struct DamageType {
>          enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
>      };
>
>      DamageType::E what_my_dragon_can_do =
>          DamageType::E( DamageType::Acid | DamageType::Poison );
>
> In this example, the two enumeration values are automatically promoted
> to integer (which has arithmetic) ORed, then the result is automatically
> converted back to the type DamageType::E.

How is that automatic? It is explicitly converted back through
     DamageType::E( expression )

> Except that the value of what_my_dragon_can_do is not one of the
 > values defined in the type.

Once again, this is a design decision made by those who brought
enumerations into C. The value an enumeration may take is not
restricted to being one of the enumerators because the language
wants to support using enumeration literals as bitmasks. You may
not like it, but this use is correct C++.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 17:29:15 +0100, Hyman Rosen <hyrosen@mail.com> a écrit:
> There in a nutshell is what all language wars come to:
> My favorite language has powerful features which could
> be misused, but no one would do that. Your favorite
> language has unfortunate features which render all
> programs written in it unreliable and incomprehensible.

While this assertion is true, it lacks measurements. That one thing may  
occurs, tells nothing about it occurrence probability. And statistical  
studies already promoted in this Usenet, tends to say miss-uses are less  
likely to be an issue in audited Ada texts than it is in C++ texts.

Yes, there may be snow in April, but this is less likely to occurs than  
during December.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Jeffrey Carter]

On 02/17/2011 12:55 PM, Ludovic Brenta wrote:
>
> type E is (A, B, C);
> B : E := E'Val (E'Pos (A) + E'Pos (C)); -- Constraint_Error

Not quite. A = E'First, and E'Pos (E'First) = 0, so this yields C. However, 
using B and C will raise Constraint_Error (once once corrects the error of the 
variable being named B).

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 21:50:20 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> Oddly enough, it is good practice to *not* play the inference
> game when creating "models" in ML languages:  when ML programmers
> describe a structure or type, they use type names explicitly.
> Every function is written in terms of its (typed) profile,
> not just the names.
Not sure I've understood. Could you give a short example ?


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Ludovic Brenta]

Hyman Rosen writes on comp.lang.ada:
> On 2/17/2011 3:51 PM, Ludovic Brenta wrote:
>> Hyman Rosen<hyrosen@mail.com>  writes:
>>> C and C++ enumerations don't have arithmetic.
>>> They do convert automatically to integers, but
>>> they don't automatically convert back.
>>
>> Actually they do in the example you provided:
>>
>>      struct DamageType {
>>          enum E { Fire = 1, Acid = 2, Lightning = 4, Poison = 8 };
>>      };
>>
>>      DamageType::E what_my_dragon_can_do =
>>          DamageType::E( DamageType::Acid | DamageType::Poison );
>>
>> In this example, the two enumeration values are automatically promoted
>> to integer (which has arithmetic) ORed, then the result is automatically
>> converted back to the type DamageType::E.
>
> How is that automatic? It is explicitly converted back through
>     DamageType::E( expression )

Because, unless my C++ is really rusty, this is not a conversion.  It is
an explicit call to the (implicitly defined) copy constructor

DamageType::E (DamageType::E&)

where the parameter, of type int, is automatically converted to
DamageType::E&.

An explicit type conversion would look like:

  (DamageType::E) expression

>> Except that the value of what_my_dragon_can_do is not one of the
>> values defined in the type.
>
> Once again, this is a design decision made by those who brought
> enumerations into C. The value an enumeration may take is not
> restricted to being one of the enumerators because the language wants
> to support using enumeration literals as bitmasks. You may not like
> it, but this use is correct C++.

Agreed.  That was my point: C++ is a dangerous language, by design.

-- 
Ludovic Brenta.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 4:32 PM, Ludovic Brenta wrote:
> Hyman Rosen writes on comp.lang.ada:
>> How is that automatic? It is explicitly converted back through
>>      DamageType::E( expression )
>
> Because, unless my C++ is really rusty, this is not a conversion.  It is
> an explicit call to the (implicitly defined) copy constructor
>
> DamageType::E (DamageType::E&)
>
> where the parameter, of type int, is automatically converted to
> DamageType::E&.
>
> An explicit type conversion would look like:
>
>    (DamageType::E) expression

Sorry, but your C++ is really rusty. The two forms are equivalent.
5.2.3/1 says
     A simple-type-specifier (7.1.5) followed by a parenthesized
     expression-list constructs a value of the specified type given
     the expression list. If the expression list is a single
     expression, the type conversion expression is equivalent (in
     definedness, and if defined in meaning) to the corresponding
     cast expression (5.4).




>
>>> Except that the value of what_my_dragon_can_do is not one of the
>>> values defined in the type.
>>
>> Once again, this is a design decision made by those who brought
>> enumerations into C. The value an enumeration may take is not
>> restricted to being one of the enumerators because the language wants
>> to support using enumeration literals as bitmasks. You may not like
>> it, but this use is correct C++.
>
> Agreed.  That was my point: C++ is a dangerous language, by design.
>

Re: What's wrong with C++?

[Shark8]

On Feb 17, 12:54 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Thu, 17 Feb 2011 04:35:46 +0100, Shark8 <onewingedsh...@gmail.com> a  
> écrit:> Also, one can use precisely that behavior to crash the pre-processor:
> > //Test.h
> > #include <test.h>
>
> If I'm not wrong, this is implementation specific, and GCC's preprocessor  
> reject circular dependencies.
>
> --
> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
> les chiens.
>
> “I am fluent in ASCII” [Warren 2010]

Really? The machine I tested it on (a Solaris) accepted it w/o
complaint and, I believe that it was using GCC. {It certainly had it
installed; though, to be fair, it could have been using g++ to try to
compile it.}

Re: What's wrong with C++?

[J-P. Rosen]

Le 17/02/2011 17:29, Hyman Rosen a �crit :
> There in a nutshell is what all language wars come to:
> My favorite language has powerful features which could
> be misused, but no one would do that. Your favorite
> language has unfortunate features which render all
> programs written in it unreliable and incomprehensible.
This is not fair: in any language, you can have misleading names. On
this point, Ada is just like all other ones. But macro-processing was
forbidden by the requirements for Ada - for good reasons.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[J-P. Rosen]

Le 17/02/2011 20:38, Hyman Rosen a écrit :
> On 2/17/2011 1:53 PM, Ludovic Brenta wrote:
>> No, it only means that enumerations in C++ really are integers
>> and not enumerations.
> 
> This was a choice made by the people who incorporated enumerations
> into C. They felt it important that enumerations should be usable
> in the style of bitmasks. And what does it mean for something to be
> "really an integer"? Ada 'Pos and 'Val attributes certainly give
> the illusion that Ada enumerators are integers too!
Definitely not. They are just gateways between integers and enums, but
enums are not integers. For one thing, the 'Pos may be different from
the internal representation in the presence of representation clauses.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/17/11 10:00 PM, Yannick Duchêne (Hibou57) wrote:

>> Make "+" a little more obscure (if possible) and have
>> a proponent of Ada look for the error...
>
> Here, Ada 2012's pre-post-conditions comes in the playground ;)

Not really.  Which "+" is it that the post-condition is mentioning?

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 5:50 PM, J-P. Rosen wrote:
> Le 17/02/2011 17:29, Hyman Rosen a �crit :
>> There in a nutshell is what all language wars come to:
>> My favorite language has powerful features which could
>> be misused, but no one would do that. Your favorite
>> language has unfortunate features which render all
>> programs written in it unreliable and incomprehensible.
> This is not fair: in any language, you can have misleading names. On
> this point, Ada is just like all other ones.

Well, you could forbid rebinding names from the standard library,
or even any already-bound name. Wouldn't that be safer?

> But macro-processing was forbidden by the requirements for Ada -
 > for good reasons.

You should find this amusing, then: <http://russp.org/Ada-syntax.html>

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 5:54 PM, J-P. Rosen wrote:
> Le 17/02/2011 20:38, Hyman Rosen a écrit :
>> On 2/17/2011 1:53 PM, Ludovic Brenta wrote:
>>> No, it only means that enumerations in C++ really are integers
>>> and not enumerations.
>>
>> This was a choice made by the people who incorporated enumerations
>> into C. They felt it important that enumerations should be usable
>> in the style of bitmasks. And what does it mean for something to be
>> "really an integer"? Ada 'Pos and 'Val attributes certainly give
>> the illusion that Ada enumerators are integers too!
> Definitely not. They are just gateways between integers and enums, but
> enums are not integers. For one thing, the 'Pos may be different from
> the internal representation in the presence of representation clauses.

Yes, that's why I said they can give the illusion of being integers.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 5:54 PM, J-P. Rosen wrote:
> For one thing, the 'Pos may be different from
> the internal representation in the presence of
 > representation clauses.

It also occurs to me that the ability to control their internal
representation makes them seem an awful lot like integers!

Re: What's wrong with C++?

[J-P. Rosen]

Le 18/02/2011 00:00, Hyman Rosen a �crit :
> Well, you could forbid rebinding names from the standard library,
> or even any already-bound name. Wouldn't that be safer?
AdaControl can do that (sorry, this was too tempting an opportunity for
a shameless plug)

>> But macro-processing was forbidden by the requirements for Ada -
>> for good reasons.
> 
> You should find this amusing, then: <http://russp.org/Ada-syntax.html>
:-)
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[J-P. Rosen]

Le 18/02/2011 00:03, Hyman Rosen a écrit :
> It also occurs to me that the ability to control their internal
> representation makes them seem an awful lot like integers!
I think you might be missing a fundamental point about the typing model
of Ada here.

There are two levels: an abstract type that pertains to the problem
domain, and an internal representation (which eventually boils down to
bits). In Ada, you work in the problem domain, independently of the
representation.

Normally, the compiler chooses the internal representation for you.
However, if you need a certain representation, you can impose it on the
compiler; nevertheless, you still work in the abstract domain.

A typical example of this is what we discussed about the 'Pos attribute:
it is defined as the relative position of an enum in the list where it
is defined. It has nothing to do whatsoever with its internal
representation (although, for efficiency reasons, they are the same /by
default/).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Hyman Rosen]

On 2/17/2011 6:17 PM, J-P. Rosen wrote:
> Le 18/02/2011 00:03, Hyman Rosen a écrit :
>> It also occurs to me that the ability to control their internal
>> representation makes them seem an awful lot like integers!
> I think you might be missing a fundamental point about the typing model
> of Ada here.
>
> There are two levels: an abstract type that pertains to the problem
> domain, and an internal representation (which eventually boils down to
> bits). In Ada, you work in the problem domain, independently of the
> representation.
>
> Normally, the compiler chooses the internal representation for you.
> However, if you need a certain representation, you can impose it on the
> compiler; nevertheless, you still work in the abstract domain.
>
> A typical example of this is what we discussed about the 'Pos attribute:
> it is defined as the relative position of an enum in the list where it
> is defined. It has nothing to do whatsoever with its internal
> representation (although, for efficiency reasons, they are the same /by
> default/).

I do understand. I don't know Ada, but I would assume that controlling
internal representation is generally used to match object layout (not
value) against external requirements. (Or to make your arrays of booleans
be arrays of bits, I guess.) It seems more unusual, when you want your
enumerators to have specific internal values, to also claim that they're
not "really" integers.

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/17/11 10:08 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 21:50:20 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit:
>> Oddly enough, it is good practice to *not* play the inference
>> game when creating "models" in ML languages: when ML programmers
>> describe a structure or type, they use type names explicitly.
>> Every function is written in terms of its (typed) profile,
>> not just the names.
> Not sure I've understood. Could you give a short example ?

For example in OCaml's standard library everything has
an interface.

val copy : string -> string
(** Return a copy of the given string. *)

To me, this seems to represent the modeling part; the implementation
would be the real thing, not the model.
More importantly, programmers wishing to just use the string (model)
would look at the interface.  No type inference so far.

ML is similar. It has signatures for its structs.

Haskell definitions are frequently prefixed with function
type, every major (model) definition states its type explicitly.

Here is a quote from the prelude.

class  (Eq a, Show a) => Num a  where
     (+), (-), (*)    :: a -> a -> a

Thus if you want to know what (*) stands for in Haskell, you will find
it here.  "Generic" type /a/ is explicitly a Num and an instance of
Eq and Show.

Specifying types explicitly also helps early error detection:

let f1 = function x -> function y -> x +. y ;;
let f2 = function (x : int) -> function (y : int) -> x +. y ;;

let test1 = f1 3 4 ;;
let test2 = f2 3 4 ;;

Both f2 and test1 trigger a diagnostic message.
test1 finds the mistake in the definition of f1,
but arguably, that's too late!
f2's error is detected immediately when it has been read.

So, apparently, type inference is used by programmars when writing
small local things, but not to replace explicit type annotations.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Thu, 17 Feb 2011 23:55:09 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:

> On 2/17/11 10:00 PM, Yannick Duchêne (Hibou57) wrote:
>
>>> Make "+" a little more obscure (if possible) and have
>>> a proponent of Ada look for the error...
>>
>> Here, Ada 2012's pre-post-conditions comes in the playground ;)
>
> Not really.  Which "+" is it that the post-condition is mentioning?

Should be the mathematical one.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Mike Sieweke]

"Peter C. Chapin" wrote:

> On Wed, 16 Feb 2011, Mike Sieweke wrote:
> 
> > The flaws in C++ are too numerous for a newsgroup posting.
> > A bullet list would run into several pages.
> >
> > You should read Ian Joyner's critique:
> > http://www.zechweb.de/Joyners_cpp_critique/
> 
> I have a lot of problems with that critique. I wouldn't recommend it to 
> anyone. I don't think the author really understands C++ and thus is 
> attacking a straw man created in his own mind.

It's a really long paper (about 60 pages of text), and
it covers a lot of ground.  To say he attacks a single
straw man grossly oversimplifies the critique.

> I actually wrote a longish rebuttal to that document. I could post it 
> somewhere if people care.

I would be interested to read your rebuttal.


-- Mike Sieweke
-- "Just a bit of harmless brain alteration, that's all..."

Re: What's wrong with C++?

[Chuck]

(I am reading and responding to this thread in reverse-chronological 
order, FYI.)

Hyman Rosen wrote:

> C++ is very susceptible to horrible runaway type names because
> it does have automatic instantiation of templates, and especially
> in the presence of template metaprogramming. Without automatic
> instantiation and partial specialization, Ada has rather less need
> for this. (Which does not mean C++ is bad, just different.)
>

I don't use templates because of the auto-instantiation, but I would be 
remiss to say that I am 100% sure that auto-generation from templates is 
not sometimes a good thing (I haven't evolved my own methods in the 
proverbial "large-scale development" scene, but isn't that an exception 
(NPI)?). In general, I find myself too removed from what's going on when 
there is auto-generation. So, I agree with your thumbs down of that. I 
think "template metaprogramming" is for those with way too much time on 
their hands (or something like that). In fact, I've seen that someone 
coined the phrase "stupid template tricks" already.

Re: What's wrong with C++?

[Chuck]

Dmitry A. Kazakov wrote:
> On Thu, 17 Feb 2011 00:31:52 -0800 (PST), Ludovic Brenta wrote:
>
>> In Ada, the two named access types are incompatible with one another;
>> they have no structural equivalence.
>
> The flaw here is structural equivalence and, more generally, type
> inference. Not everybody agree that type inference is bad. I do
> believe that it is.

How so? If it means a more robust type system, great. If it means lazy 
programmers writing 'auto' everywhere instead of documenting what is 
going on, then it's decidedly a BIG loss (uncomprehensible code is 
useless code). Personally, when I think of  'auto'-likeness, I think of 
Visual Basic, and "real" programmers don't need or like that.

>
> Note that Ada 95/2005/201x keep on moving towards more inference.

Internally that would be good (though I don't know compiler internals 
enough to know that it isn't already saturated there and that you are 
talking then strictly of programmerland).

Re: What's wrong with C++?

[Chuck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

Georg Bauhaus wrote:
> On 2/17/11 8:19 PM, Yannick Duchêne (Hibou57) wrote:
>> Le Thu, 17 Feb 2011 10:02:58 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>> The flaw here is structural equivalence and, more generally, type
>>> inference. Not everybody agree that type inference is bad. I do
>>> believe that it is.
>>
>> I personally believe type inference (within a typed language), is
>> good when that is used to tersely write models of an application.
>> That is what (S)ML en derivatives do.
>
> Oddly enough, it is good practice to *not* play the inference
> game when creating "models" in ML languages:  when ML programmers
> describe a structure or type, they use type names explicitly.
> Every function is written in terms of its (typed) profile,
> not just the names.

I've seen a LOT of interjection of promotion of functional language 
concepts. I don't think it's going anywhere fast or ever (it's a niche 
just like logic languages, I Guess). Academia still pushing this? Do 
tell, how do you come to know ML and such? (email is fine as it is an 
off-topic tangent, but you have to request here to do that). 

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:

> You can still define the types you need. Inference just means that you
> typically don't have to bother with explicit declarations: create the
> objects you need (of the types you need) and let the compiler work
> out the details.

And the the MAINTAINER try to figure out WTF is going on with the 
UNREADABLE code! Uncomprehensible code is useless code.

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Thu, 17 Feb 2011, Dmitry A. Kazakov wrote:
>
>> The flaw here is structural equivalence and, more generally, type
>> inference. Not everybody agree that type inference is bad. I do
>> believe that it is.
>
> Could you elaborate a little on why you think type inference is bad?
> In the functional languages that support it, type inference is
> completely type safe (for example: Haskell, OCaml, Scala). Perhaps
> you mean something different.
> I do agree that type annotations can be useful documentation for the
> programmer trying to read the program, but a program won't "go wrong"
> because of type inference.
>

"Can be useful"? Understatement of the century I think! "auto": one step 
away from 
POINTNCLICKYOURSELFTOPROGRAMMINGNIRVANNA-GUI-WHIZZIWIGBANG-WEGOTYABYTHEBALLSNOWPROGRAMMERWANTEDTOBE. 

Re: What's wrong with C++?

[Chuck]

Hyman Rosen wrote:
> On 2/17/2011 11:12 AM, Dmitry A. Kazakov wrote:
>> On Thu, 17 Feb 2011 08:38:25 -0500, Peter C. Chapin wrote:
>>> Could you elaborate a little on why you think type inference is bad?
>>
>> A variety of objections...
>
> And your objections are wrong because there are plenty
> of types that can usefully be inferred by the compiler
> and which can be written by the programmer only with
> difficulty (at least in C++). Iterators over containers
> are a prime example. If I have a C++ map<string, int>
> and I look something up, I have to declare
>     map<string, int>::iterator i = my_map.find("hello");
> But that's silly - the compiler knows what type that
> function returns, and it has a better chance of getting
> it right than I do:
>     auto i = my_map.find("hello");
> will be supported by soon-to-be-standard C++. For now,
> people dedicated to not sprinkling their code with these
> iterator types have to push to a type-inferring template:
>     template <typename T> void do_something(T i);
>     do_something(my_map.find("hello"));

I forsee a division of roles: programmer and templater (In C++ land). 

Re: What's wrong with C++?

[Chuck]

Mike Sieweke wrote:
> KK6GM <mjsilva@scriptoriumdesigns.com> wrote:
>
>> So, without turning into a bash-fest, what are some general-consensus
>> weaknesses or failures or problems with C++?  Comparisons with Ada
>> are welcome but not required.  And my focus is in the embedded &
>> real-time arenas, FWIW.
>
> The flaws in C++ are too numerous for a newsgroup posting.

No they aren't.

> A bullet list would run into several pages.

Sure, if you flatten everything to one level. There are major and minor 
deficits at the least. This is USENET, don't try to put one over on 
anyone, because these people are very smart.

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Wed, 16 Feb 2011, Mike Sieweke wrote:
>
>> The flaws in C++ are too numerous for a newsgroup posting.
>> A bullet list would run into several pages.
>>
>> You should read Ian Joyner's critique:
>> http://www.zechweb.de/Joyners_cpp_critique/
>
> I have a lot of problems with that critique. I wouldn't recommend it
> to anyone. I don't think the author really understands C++ and thus is
> attacking a straw man created in his own mind.
>
> I actually wrote a longish rebuttal to that document. I could post it
> somewhere if people care.

Yeah, post the link, I'll put it in a folder. That said, summarize the 
major objections you have and opinions you have please.

Re: What's wrong with C++?

[Chuck]

Mike Sieweke wrote:
> "Peter C. Chapin" wrote:
>
>> On Wed, 16 Feb 2011, Mike Sieweke wrote:
>>
>>> The flaws in C++ are too numerous for a newsgroup posting.
>>> A bullet list would run into several pages.
>>>
>>> You should read Ian Joyner's critique:
>>> http://www.zechweb.de/Joyners_cpp_critique/
>>
>> I have a lot of problems with that critique. I wouldn't recommend it
>> to anyone. I don't think the author really understands C++ and thus
>> is attacking a straw man created in his own mind.
>
> It's a really long paper (about 60 pages of text), and
> it covers a lot of ground.  To say he attacks a single
> straw man grossly oversimplifies the critique.

Could not one abstract into one "class", all the C++ gurus of 
comp.lang.c++ ?

Re: What's wrong with C++?

[Chuck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Yannick Duch�ne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 04:41:10 +0100, Mike Sieweke
> <msieweke@ix.netcom.com> a écrit:
>
>>  KK6GM <mjsilva@scriptoriumdesigns.com> wrote:
>>
>>> So, without turning into a bash-fest, what are some
>>> general-consensus weaknesses or failures or problems with C++? 
>>> Comparisons with Ada are welcome but not required.  And my focus is
>>> in the embedded & real-time arenas, FWIW.
>>
>> The flaws in C++ are too numerous for a newsgroup posting.
>> A bullet list would run into several pages.
>>
>> You should read Ian Joyner's critique:
>> http://www.zechweb.de/Joyners_cpp_critique/
>>
>> You should also read the C++ FQA (frequently questioned answers)
>> by Yossi Kreinin:
>> http://www.yosefk.com/c++fqa/index.html
>>
>> Do a Google search for "dark side of C++" and you'll find
>> even more.  This one seems especially interesting:
>> http://port70.net/~nsz/16_c++.html
>>
>> -- Mike Sieweke
>> -- "Just a bit of harmless brain alteration, that's all..."
>
> At least, we could reasonably admit there is not so much literatures
> about Ada miss-conceptions (or may one could argue that's only
> because Ada is less popular than C++ ?).

Would anyone really want to develop a programming language for a military 
or a goverment? Ada is historical. 

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Thu, 17 Feb 2011, Hyman Rosen wrote:
>
>> There in a nutshell is what all language wars come to: My favorite
>> language has powerful features which could be misused, but no one
>> would do that. Your favorite language has unfortunate features which
>> render all programs written in it unreliable and incomprehensible.
>
> Yes, you can write excellent software in any reasonable language and
> you can write bad software in any reasonable language. The rest is
> just details. :)

Next cliche wins??? AGE CHECK!!! 

Re: What's wrong with C++?

[J-P. Rosen]

Le 18/02/2011 00:27, Hyman Rosen a écrit :
> I do understand. I don't know Ada, but I would assume that controlling
> internal representation is generally used to match object layout (not
> value) against external requirements. (Or to make your arrays of booleans
> be arrays of bits, I guess.) It seems more unusual, when you want your
> enumerators to have specific internal values, to also claim that they're
> not "really" integers.
"Integers" means you want to do arithmetic with them. When interfacing
with devices, it often happens that you have specific bit patterns, and
you want to give them a name.

Remember: for me, a bit pattern is not necessarily an integer ;-)
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a déménagé / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: What's wrong with C++?

[Chuck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Yannick Duch�ne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 17:29:15 +0100, Hyman Rosen <hyrosen@mail.com> a
> écrit:
>> There in a nutshell is what all language wars come to:
>> My favorite language has powerful features which could
>> be misused, but no one would do that. Your favorite
>> language has unfortunate features which render all
>> programs written in it unreliable and incomprehensible.
>
> While this assertion is true, it lacks measurements. That one thing
> may occurs, tells nothing about it occurrence probability. And
> statistical studies already promoted in this Usenet, tends to say
> miss-uses are less likely to be an issue in audited Ada texts than it
> is in C++ texts.

Your "point" is unfounded: I am psychic.

>
> Yes, there may be snow in April, but this is less likely to occurs
> than during December.

And this perplexes you? ("Who's on first?"). I can't help you, but you 
can "help" yourself (i.e., if you need and want some of that, not that 
help is bad and not that it is bad to seek help, it may be a long and 
arduous time). Else shut up and go to barroomchat.yourinnerself.real. 
(And buy me a drink please!). 

Re: What's wrong with C++?

[Chuck]

J-P. Rosen wrote:

> This is not fair [...]

> [...] Ada is just like all other ones.

> But macro-processing was
> forbidden by the requirements for Ada - for good reasons.

They killed people like Jesus and even "lesser" for "good reasons"? Maybe 
they were "Verboten"? 

Re: What's wrong with C++?

[Chuck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Yannick Duch�ne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 12:04:00 +0100, J-P. Rosen <rosen@adalog.fr> a
> écrit:
>> Le 17/02/2011 00:35, Peter C. Chapin a écrit :
>>> A macro defined in someheader.h might change the meaning of the
>>> declarations in someotherheader.h.
>> And especially the following one:
>> #define private public
>>
>> Great for those who think that information hiding is a nuisance!
>
> I am not joking here : at the time I learned C/C++, I hired a book
> from a library,

Seriously dude, you don't "hire" a book from a library unless you are way 
stupid (no offense, you are not my problem).

> which was proudly stating C/C++ macros are so much
> powerful (sic) that one may "#define BEGIN {", "#define END }" and so
> on, so as to happily write BASIC in C/C++ ! And that was not a book
> playing the fool on C/C++, that book was promoting C/C++.

I use that mechanism for "templates". It may not be scalable, but I don't 
need a driver's license to drive. AGE CHECK! 

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Wed, 16 Feb 2011, Hyman Rosen wrote:
>
>> It sounds like a complaint that C++ requires source inclusion
>> (directly or via preprocessor #include directives) of type and
>> object declarations into a compilation unit, while other languages
>> have syntax for requesting a type set (class, package, etc.) whose
>> definition is then sought out by the compiler in an
>> implementation-dependent way. Personally, I don't find the long
>> strings of 'import ...;' or 'with ...; use ...;' statements any more
>> appealing than '#include "header.h"', but I suppose it's "purer".
>
> C++'s model of #include is a major project because the compiler does
> not really know what is going on and the preprocessor can do
> arbitrary editing of source code. For example
>
> #include <someheader.h>
> #include <someotherheader.h>
>
> A macro defined in someheader.h might change the meaning of the
> declarations in someotherheader.h. I've had this happen to me many
> times... in headers that I did not write and over which I have no
> control. Often the problem can be fixed by rearranging the order of
> #includes or by selectively #undef certain macros. However, it's a
> problem that just shouldn't exist.

So solve it or shut up. I spewed on another channel about the value of 
headers. Maybe I'm wrong. Maybe I'd pay you as a consultant and then find 
out that you raped me for money about common knowledge. Then I would hate 
hate you. (Lest you think I don't have this "problem" solved, I assure 
you it a trivial issue and you should keep your taxicab). 

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Wed, 16 Feb 2011, Hyman Rosen wrote:
>
>> It sounds like a complaint that C++ requires source inclusion
>> (directly or via preprocessor #include directives) of type and
>> object declarations into a compilation unit, while other languages
>> have syntax for requesting a type set (class, package, etc.) whose
>> definition is then sought out by the compiler in an
>> implementation-dependent way. Personally, I don't find the long
>> strings of 'import ...;' or 'with ...; use ...;' statements any more
>> appealing than '#include "header.h"', but I suppose it's "purer".
>
> C++'s model of #include is a major project

Proof please. Exemplify in actuality. Include examples of the proverbial 
"large scale development", and also of the "lone" developer. Sell me, I 
dare you, and I am receptive audience to your advertisement, not clinch 
it. Sell me something. I dare you.

Re: What's wrong with C++?

[Chuck]

Peter C. Chapin wrote:
> On Wed, 16 Feb 2011, Hyman Rosen wrote:
>
>> It sounds like a complaint that C++ requires source inclusion
>> (directly or via preprocessor #include directives) of type and
>> object declarations into a compilation unit, while other languages
>> have syntax for requesting a type set (class, package, etc.) whose
>> definition is then sought out by the compiler in an
>> implementation-dependent way. Personally, I don't find the long
>> strings of 'import ...;' or 'with ...; use ...;' statements any more
>> appealing than '#include "header.h"', but I suppose it's "purer".
>
> C++'s model of #include is a major project because the compiler does
> not really know what is going on and the preprocessor can do
> arbitrary editing of source code. For example
>

For the viewer audience: Peter was trying to make a minor a major. (Huh, 
Peter). 

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Fri, 18 Feb 2011 07:12:34 +0100, Chuck <chuckmacdonald@nospam.me> a  
écrit:
> I've seen a LOT of interjection of promotion of functional language
> concepts. I don't think it's going anywhere fast or ever (it's a niche
> just like logic languages, I Guess).
There is actually nothing like a "logic languages" in the place. Prolog is  
unification based only (which in turns is used to simulate logic), with  
the addition of backtracking or parallelism, depending on the  
implementation.

> Academia still pushing this? Do
OCaml is widely used in industries.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 20:29:05 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 17 Feb 2011 17:12:37 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> The first notice is that inferred types cannot be safe per definition.
>> There is no additional information involved. What is inferred, already  
>> is.
> 
> You are confused between safe by readability and safe by predictability ;)

No, I just consider type safety as, citing Wikipedia,

"Safety is the state of being "safe" (from French sauf), the condition of
being protected against physical, social, spiritual, financial, political,
emotional, occupational, psychological, educational or other types or
consequences of failure, damage, error, accidents, harm or any other event
which could be considered non-desirable."

When types are inferred they are in only one possible state. So it is
meaningless to consider them safe or not. But in connection to the
application domain they are definitely not safe.

> I agree type inference may leads to less readable texts, and that is why I  
> prefer this to be used for formal modeling only. But this is still safe,  
> although not from a most common human point of view.

Yes, C++ is a perfect language, although a bit inhumane...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[Georg Bauhaus]

On 2/18/11 4:09 AM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 17 Feb 2011 23:55:09 +0100, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit:
>
>> On 2/17/11 10:00 PM, Yannick Duchêne (Hibou57) wrote:
>>
>>>> Make "+" a little more obscure (if possible) and have
>>>> a proponent of Ada look for the error...
>>>
>>> Here, Ada 2012's pre-post-conditions comes in the playground ;)
>>
>> Not really. Which "+" is it that the post-condition is mentioning?
>
> Should be the mathematical one.

Which one?

Re: What's wrong with C++?

[Dmitry A. Kazakov]

On Thu, 17 Feb 2011 20:34:03 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 17 Feb 2011 17:12:37 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> The third note is that if inferred, then why should we care of types?
> No, you have to care, and you still define types. You just don't have to  
> be so much redundant as you would be with, say, Ada.

I didn't mean redundancy, I did a meta language that binds the program to
its application domain. In Ada it is largely the type system. Without types
what takes its place?

> This is required with  
> functional language where you do not use side-effect (there may be some  
> side effect in SML which is not stricly pure, but you may not use side  
> effects as long as you don't want), where function returns rather complex  
> types and get numerous parameters which are as much complexes. Without  
> type inference... functional program texts would simply be an unreadable  
> mess (:-))

And with type inference they still are. (:-))

>> Now the main objection is computability and decidability. Only "simple"
>> things can be inferred. The compiler cannot solve problems beyond
>> Turing-completeness.
> Actually, SML interpreters are required to complain if ever that occurs,

Occurs what? The point is that you fundamentally cannot infer some things,
and there is no way even to infer that these things exist or need to be
inferred. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What's wrong with C++?

[richard]

On Feb 17, 3:52 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
> On2/17/11 12:04 PM, J-P. Rosen wrote:
>
> > Le 17/02/2011 00:35, Peter C. Chapin a crit :
> >> A macro defined in someheader.h might change the meaning of the
> >> declarations in someotherheader.h.
> > And especially the following one:
> > #define private public
>
> > Great for those who think that information hiding is a nuisance!
>
> It is good to know that source code transformation
> can change the meaning of source text.  I don't think
> this argument will convince.  Is there substantial evidence
> of programs that #define private to be public? Might be.
> The change is a conventional trick to use with introspective
> languages, and useful.
>
> But anyway, the argument is easily refuted as by
> firing this riposte:
>
> procedure Safe is
>
>      function "+" (Left, Right: Integer) return Integer is
>      begin
>          return 0;
>      end "+";
>
>      A : array (Integer range 1 .. 2) of Integer;
> begin
>      for K in A'Range loop
>          A (A'First + K - 1) := 666;
>      end loop;
> end Safe;
>
> Make "+" a little more obscure (if possible) and have
> a proponent of Ada look for the error...
>
> Or talk about the possibility (or not) of changing the
> definition of Integer temporarily to a debugging version
> of Integer whose operations we can trace.
We do not use predefined type integer in production code.  If you
define your own constrained integer type, this is not likely to be a
problem.

Re: What's wrong with C++?

[Georg Bauhaus]

On 18.02.11 12:34, richard wrote:

>> Make "+" a little more obscure (if possible) and have
>> a proponent of Ada look for the error...
>>
>> Or talk about the possibility (or not) of changing the
>> definition of Integer temporarily to a debugging version
>> of Integer whose operations we can trace.
> We do not use predefined type integer in production code.  If you
> define your own constrained integer type, this is not likely to be a
> problem.

I take that as an example of why neither C++ nor Ada can be used
without additional rules made to prevent dangerous situations
from occurring.  However, the rules might differ, in quantity and
in quality.

To me, a more interesting question concerns less hypostatized
circumstances: Given real world programming capacity,
measurable in terms of cost, degree of success, etc.,
what are the effects, as measured in projects using either
language, of:

- given rule set
- programmer education
- language facilities
- actual/idiomatic/dominant use?

Re: What's wrong with C++?

[richard]

On Feb 18, 3:56 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On18.02.11 12:34, richard wrote:
>
> >> Make "+" a little more obscure (if possible) and have
> >> a proponent of Ada look for the error...
>
> >> Or talk about the possibility (or not) of changing the
> >> definition of Integer temporarily to a debugging version
> >> of Integer whose operations we can trace.
> > We do not use predefined type integer in production code.  If you
> > define your own constrained integer type, this is not likely to be a
> > problem.
>
> I take that as an example of why neither C++ nor Ada can be used
> without additional rules made to prevent dangerous situations
> from occurring.  However, the rules might differ, in quantity and
> in quality.
>
> To me, a more interesting question concerns less hypostatized
> circumstances: Given real world programming capacity,
> measurable in terms of cost, degree of success, etc.,
> what are the effects, as measured in projects using either
> language, of:
>
> - given rule set
> - programmer education
> - language facilities
> - actual/idiomatic/dominant use?
Your reply does not correspond to the statement in my post.

Re: What's wrong with C++?

[Peter C. Chapin]

On Fri, 18 Feb 2011, Chuck wrote:

>> You can still define the types you need. Inference just means that you 
>> typically don't have to bother with explicit declarations: create the 
>> objects you need (of the types you need) and let the compiler work out 
>> the details.
>
> And the the MAINTAINER try to figure out WTF is going on with the
> UNREADABLE code! Uncomprehensible code is useless code.

I agree that rampant type inference isn't good for readibility. But as has 
been mentioned here elsewhere, even languages that support aggressive type 
inference typically require type annotations in interfaces (aka 
specifications). Anyway, I like the way Scala does type inference. You do 
have to annotate parameter types of methods but the compiler can infer the 
types on locals and also on function literals that are embedded inside other 
expressions. For instance:

def simpleMethod(counters: List[Int]) =
   counters filter { _ > 1 }

In this trivial example the compiler infers the type of the function literal 
as Int => Boolean based on its use as a argument to the filter method as 
applied to a list of integers. The return type of simpleMethod is also 
inferred as a list of integers as well (the result of filter).

The fact that you have to annotate the parameter types and yet don't have to 
bother annotating all the local types seems like a good compromise between 
documentation and conciseness.

In any case, functional languages are becoming industrially significant. 
Microsoft is fully supporting F# (an OCaml dialect) and Scala is doing well 
in the Java ecosystem. I think we will see more of this sort of thing in the 
future rather than less.

Peter

Re: What's wrong with C++?

[Georg Bauhaus]

On 18.02.11 14:26, richard wrote:
> On Feb 18, 3:56 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
>> On18.02.11 12:34, richard wrote:
>>
>>>> Make "+" a little more obscure (if possible) and have
>>>> a proponent of Ada look for the error...
>>
>>>> Or talk about the possibility (or not) of changing the
>>>> definition of Integer temporarily to a debugging version
>>>> of Integer whose operations we can trace.
>>> We do not use predefined type integer in production code.  If you
>>> define your own constrained integer type, this is not likely to be a
>>> problem.
>>
>> I take that as an example of why neither C++ nor Ada can be used
>> without additional rules made to prevent dangerous situations
>> from occurring.  However, the rules might differ, in quantity and
>> in quality.
>>
>> To me, a more interesting question concerns less hypostatized
>> circumstances: Given real world programming capacity,
>> measurable in terms of cost, degree of success, etc.,
>> what are the effects, as measured in projects using either
>> language, of:
>>
>> - given rule set
>> - programmer education
>> - language facilities
>> - actual/idiomatic/dominant use?
> Your reply does not correspond to the statement in my post.

If I define my "own constrained integer type, this is not likely to be a
problem", provided there is a rule to "not use predefined type Integer in
production code".

My original example was intended to show how generalizations
do not work when comparing languages (since generalizations is
what language warriors often use).

I hope that talking about either of

- #define private public
- function "+" (Left, Right: Integer) return Integer;

is simply not so relevant to the discussion of respective
language merits, for two reasons:

(a) anyone writing these lines or similarly disruptive source text
knows what he or she is doing (for example, not causing a problem)

(b) judging a language by considering corner cases (or even single cases)
without a demonstration of their real impact seems void.

Comparing languages would, I think, have to start from substantial
evidence about the utility of a feature; delighted as I am about hearing
that a real project is not using predefined type Integer (neither String?),
this finding will not stop language warriors from shooting arrows into
the (duly) neglected corners of either language.  Showing that the
arrows won't do any harm to their target is effort that, I think, could be
directed towards more profitable uses in language comparisons.

Such as the apparent simplicity, for example, with which work-sharing,
work-seeking and work-stealing algorithms for general use have only
recently been written in plain old Ada on occasion of a huge effort
to add a concurrency library to Java.  (The Paraffin and Magpie
libraries.)  Has there an equally simple idea for adding similar support
to the upcoming C++?

Re: What's wrong with C++?

[Paul Colin Gloster]

Chuck <chuckmacdonald@nospam.me> sent on February 18th, 2011:

|-------------------------------------------------------------------------|
|"Yannick Duch?ne (Hibou57) wrote:                                        |
|[..]                                                                     |
|> I am not joking here : at the time I learned C/C++, I hired a book     |
|> from a library,                                                        |
|                                                                         |
|Seriously dude, you don't "hire" a book from a library unless you are way|
|stupid (no offense, you are not my problem).                             |
|                                                                         |
|[..]"                                                                    |
|-------------------------------------------------------------------------|

Chuck MacDonald,

Please be nice. Yannick did not learn English as a primary
language. He managed to convey the point.

Yours sincerely,
Paul Colin Gloster

Re: What's wrong with C++?

[Paul Colin Gloster]

Chuck <chuckmacdonald@nospam.me> sent on February 18th, 2011:
|-------------------------------------------------------------------|
|"Dmitry A. Kazakov wrote:                                          |
|[..]                                                               |
|> The flaw here is structural equivalence and, more generally, type|
|> inference. Not everybody agree that type inference is bad. I do  |
|> believe that it is.                                              |
|                                                                   |
|How so? [..]                                                       |
|[..]                                                               |
|                                                                   |
|[..]"                                                              |
|-------------------------------------------------------------------|

Type inference is bad. I do not want a typo of assigning minus three
meters per second to a variable which is supposed to denote the
quantity of passengers to be accepted by a compiler.

Re: What's wrong with C++?

[Edward Fish]

On Feb 17, 3:27 pm, Hyman Rosen <hyro...@mail.com> wrote:
> It seems more unusual, when you want your
> enumerators to have specific internal values, to also claim that they're
> not "really" integers.

Really?
Type Permissions is ( Read, Write );

Doesn't look like integers to me.
Even with
For Permissions use record
  Read  => 2#0001#,
  Write => 2#0010#
end record;

it doesn't.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/18/2011 2:58 PM, Edward Fish wrote:
> Doesn't look like integers to me.

There's none so blind as they that won't see.

Re: What's wrong with C++?

[Edward Fish]

On Feb 18, 12:04 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 2/18/2011 2:58 PM, Edward Fish wrote:
>
> > Doesn't look like integers to me.
>
> There's none so blind as they that won't see.

But there's nothing that says bit pattern 0010 is Decimal 2.

Re: What's wrong with C++?

[Hyman Rosen]

On 2/18/2011 3:10 PM, Edward Fish wrote:
> But there's nothing that says bit pattern 0010 is Decimal 2.

If you want to associate your literals with bit patterns,
you could do, similar to the 83 Rationale suggestion
<http://archive.adaic.com/standards/83rat/html/ratl-15-05.html#15.5>:
(I don't know Ada, so pardon if this isn't quite right).

     PermissionsPatterns: constant array(Permissions) of Integer :=
         (Read => 2#0001#, Write => 2#0010#);

But when you go around telling the compiler that it should
actually represent Read as 2#0001# and Write as 2#0010#,
you're not going to convince me that this isn't treating
enumerations as if they are integers.

Hey, can I do this? If not, why?

     Type Constants is ( Pi, E, Phi );
     For Constants use record
         Pi  => 3.141592654,
         E   => 2.718281828,
         Phi => 1.618033989
     end record;

Re: What's wrong with C++?

[Edward Fish]

On Feb 18, 12:27 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 2/18/2011 3:10 PM, Edward Fish wrote:
>
> > But there's nothing that says bit pattern 0010 is Decimal 2.
>
> If you want to associate your literals with bit patterns,
> you could do, similar to the 83 Rationale suggestion
> <http://archive.adaic.com/standards/83rat/html/ratl-15-05.html#15.5>:
> (I don't know Ada, so pardon if this isn't quite right).
>
>      PermissionsPatterns: constant array(Permissions) of Integer :=
>          (Read => 2#0001#, Write => 2#0010#);
>
> But when you go around telling the compiler that it should
> actually represent Read as 2#0001# and Write as 2#0010#,
> you're not going to convince me that this isn't treating
> enumerations as if they are integers.

What's wrong with that?
If the bits are, for example, directly tied to hardware trace-lines
then 2#0010# is sending a voltage (or lack thereof, if one is using a
platform where '0' is represented by a voltage and '1' by a lack
thereof) then there isn't any correlation between that bit-pattern and
an integer.

Another way to represent this idea would be something like:
CONTROLLER_ADDRESS : Constant Address:= [wherever the address happens
to be];

Type Commands is record
  Read, Write, Reset, Lock : Boolean;
end record;

For Commands use record
  Read   At 0 Range 0..0,
  Write  At 0 Range 1..1,
  Reset  At 0 Range 2..2,
  Lock   At 0 Range 3..3
end record;

Controller : Commands;
Fore Controller'Address Use CONTROLLER_ADDRESS;

Is *THAT* an integer? At all?

>
> Hey, can I do this? If not, why?
>
>      Type Constants is ( Pi, E, Phi );
>      For Constants use record
>          Pi  => 3.141592654,
>          E   => 2.718281828,
>          Phi => 1.618033989
>      end record;

Sure you *could* do that... but why?

Re: What's wrong with C++?

[Marco]

"
Use "=" rather than ":=" for assignment. Virtually all of the most popular programming languages use "=" for assignment, which is simpler and perfectly adequate.
"
  Yuck - this was one of the C mistakes - "==" is so goofy - I do a lot of programming in C and still think it was a mistake - Algol used := in 1960 so no excuses - saving key strokes is a stupid reason to do it the FORTRAN way but now we are stuck with it 

Re: What's wrong with C++?

[Frank J. Lhota]

On 2/19/2011 10:24 AM, Marco wrote:
> "
> Use "=" rather than ":=" for assignment. Virtually all of the most popular programming languages use "=" for assignment, which is simpler and perfectly adequate.
> "
>    Yuck - this was one of the C mistakes - "==" is so goofy - I do a lot of programming in C and still think it was a mistake - Algol used := in 1960 so no excuses - saving key strokes is a stupid reason to do it the FORTRAN way but now we are stuck with it

The best symbol I've seen for assignment the left arrow used in APL and 
early versions of Smalltalk. It's just as short as the C/C++ "=", it 
quite nicely expresses what assignment does (moves the value on the 
right into the variable on the left), and it would never be confused 
with testing for equality. It's a pity that ASCII does not have a left 
arrow character.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for this one to come home!"
- Mr. Wizard from "Tooter Turtle"

Re: What's wrong with C++?

[Nasser M. Abbasi]

On 2/19/2011 8:39 AM, Frank J. Lhota wrote:
> On 2/19/2011 10:24 AM, Marco wrote:
>> "
>> Use "=" rather than ":=" for assignment. Virtually all of the most popular programming languages
>  use "=" for assignment, which is simpler and perfectly adequate.
>> "
>>     Yuck - this was one of the C mistakes - "==" is so goofy - I do a lot of programming in
>  C and still think it was a mistake - Algol used := in 1960 so no excuses - saving key
>  strokes is a stupid reason to do it the FORTRAN way but now we are stuck with it
>


> The best symbol I've seen for assignment the left arrow used in APL and
> early versions of Smalltalk. It's just as short as the C/C++ "=", it
> quite nicely expresses what assignment does (moves the value on the
> right into the variable on the left), and it would never be confused
> with testing for equality. It's a pity that ASCII does not have a left
> arrow character.
>

I do not like <-

I like code that looks clean. Using <- all over the place,
makes the code looks little more ugly than using :=

I think ":=" and "="  is a better choice than "=" and "==" myself,
for readability purposes if nothing else.

That is why I do not like Fortran choice of a comment line, which is "!"

A very ugly symbol for a very common operation.

Ada's "--" is much more pleasing to look at, more smooth indicator of
a comment line and is not sore to the eye to look at it like ! is.

I have no idea who selected ! for comment in fortran, I think it was
bad choice, IMNSHO.

--Nasser

Re: What's wrong with C++?

[Anonymous]

> That is why I do not like Fortran choice of a comment line, which is "!"

Actually the FORTRAN (all CAPS) choice of a comment line is "C" not "!"!

> I have no idea who selected ! for comment in fortran, I think it was
> bad choice, IMNSHO.

You missed the first 40 years of FORTRAN development. I have no idea if/when
anybody started using "!" but I never saw it.

Anyway it's alot of fun to argue about C/C++ operators like == when C/C++
butchers other operators. == is the smallest of its problems.

Re: What's wrong with C++?

[Nasser M. Abbasi]

On 2/19/2011 2:36 PM, Anonymous wrote:

>> That is why I do not like Fortran choice of a comment line, which is "!"
>

> Actually the FORTRAN (all CAPS) choice of a comment line is "C" not "!"!
>
>> I have no idea who selected ! for comment in fortran, I think it was
>> bad choice, IMNSHO.
>
> You missed the first 40 years of FORTRAN development. I have no idea if/when
> anybody started using "!" but I never saw it.
>

It is Fortran, not FORTRAN.

You mean you did not look at any fortran code for the last 21 years?

"!" is the fortran comment since fortran 1990.  C comment is long dead.

May be you should try to look at some Fortran code? :)

An example,

http://www.gnu.org/software/emacs/manual/html_node/emacs/Fortran-Comments.html

"Fortran mode can also handle the Fortran 90 comment syntax where comments start with �!� and can follow other text."

http://www.cs.mtu.edu/~shene/COURSES/cs201/NOTES/chap01/comment.html

> Anyway it's alot of fun to argue about C/C++ operators like == when C/C++
> butchers other operators. == is the smallest of its problems.
>

--Nasser
  

Re: What's wrong with C++?

[Nomen Nescio]

> It is Fortran, not FORTRAN.

No amount of snot-nosed kids writing their own standards can change the fact
that FORTRAN is FORTRAN. It will never be Fortran, not if we have to bomb
them into eternity!

> You mean you did not look at any fortran code for the last 21 years?

I did, but not FORTRAN that was written on a PC ;)

> "!" is the fortran comment since fortran 1990.  C comment is long dead.

No it's not and I have the IBM FORTRAN compilers from 1968 and 1974 to prove
it. It's still supported until today on IBM FORTRAN.

> May be you should try to look at some Fortran code? :)

Maybe you should have some respect for your elders ;)

Re: What's wrong with C++?

[Nasser M. Abbasi]

On 2/19/2011 4:55 PM, Nomen Nescio wrote:

>
> Maybe you should have some respect for your elders ;)
>

You are right there, one should always respect their elders,
even when they are dead wrong ;)

--Nasser

Re: What's wrong with C++?

[Chuck]

"Peter C. Chapin" <PChapin@vtc.vsc.edu> wrote in message 
news:alpine.WNT.2.00.1102180828190.5260@WHIRLWIND...

> In any case, functional languages are becoming industrially 
> significant. Microsoft is fully supporting F# (an OCaml dialect) and 
> Scala is doing well in the Java ecosystem. I think we will see more of 
> this sort of thing in the future rather than less.
>

Yes, I noticed MS suggesting, with their F#, that functional languages 
have a potential market. Makes me wonder what I'd do with my free time if 
functional languages took over from the imperative language. 

Re: What's wrong with C++?

[Chuck]

"Paul Colin Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message 
news:alpine.LNX.2.00.1102181714020.7358@Bluewhite64.example.net...
> Chuck <chuckmacdonald@nospam.me> sent on February 18th, 2011:
>
> |-------------------------------------------------------------------------|
> |"Yannick Duch?ne (Hibou57) wrote: 
> |
> |[..] 
> |
> |> I am not joking here : at the time I learned C/C++, I hired a book 
> |
> |> from a library, 
> |
> | 
> |
> |Seriously dude, you don't "hire" a book from a library unless you are 
> way|
> |stupid (no offense, you are not my problem). 
> |
> | 
> |
> |[..]" 
> |
> |-------------------------------------------------------------------------|
>
> Chuck MacDonald,
>
> Please be nice. Yannick did not learn English as a primary
> language. He managed to convey the point.
>

I wasn't me, it was the Tequilla! :/ 

Re: What's wrong with C++?

[Chuck]

KK6GM wrote:
> This is a serious question, seeking objective information.  I've
> worked with C for many years and I have a very good understanding of
> its weaknesses, which are many.  I haven't done nearly so much C++,
> and what I have done was not very intensive (didn't use a great many
> C+ + features), so I don't have a good understanding of its
> weaknesses.
>
> So, without turning into a bash-fest, what are some general-consensus
> weaknesses or failures or problems with C++?  Comparisons with Ada are
> welcome but not required.  And my focus is in the embedded & real-time
> arenas, FWIW.

What wrong with C++? It may be better to ask what is wrong with the other 
2! Anyway, the list of what is right with C++ is much, much shorter, so 
by process of elimination, what is not on the good list, is on the bad 
list. Here's my list of good things:

  Uses curly-braces, mostly effectively.

I'll add to this list as I think of any more things.

Re: What's wrong with C++?

[Chuck]

KK6GM wrote:
> On Feb 16, 9:58 am, Hyman Rosen <hyro...@mail.com> wrote:
>> On 2/16/2011 12:37 PM, KK6GM wrote:
>>
>>> This is a serious question, seeking objective information.
>>
>> Don't you think it would be better to ask in a C++ newsgroup?
>
> I'm not at all sure the question would be received and answered as
> intended in such a group.

Of course it wouldn't. You go to the C++ to get the C++ dogma. Go to the 
Ada group to get the Ada dogma. Etc.

> And besides, I am convinced that there are
> some people here who are very knowledgeable in the field of language
> design, and who can give objective and valid answers.  Some are even
> employed by companies that write C++ compilers and related tools.

That would have been a stronger thought if you didn't put "C++" in it. 
But since you did put it in, it relegates the statement pretty 
meaningless since has been postulated that to be a C++ compiler writer 
puts you on the gravy train.

Re: What's wrong with C++?

[Chuck]

Chris Moore wrote:
> On 16/02/2011 18:18, KK6GM wrote:
>> On Feb 16, 9:58 am, Hyman Rosen <hyro...@mail.com> wrote:
>>> On 2/16/2011 12:37 PM, KK6GM wrote:
>>>
>>>> This is a serious question, seeking objective information.
>>>
>>> Don't you think it would be better to ask in a C++ newsgroup?
>>
>> I'm not at all sure the question would be received and answered as
>> intended in such a group.  And besides, I am convinced that there are
>> some people here who are very knowledgeable in the field of language
>> design, and who can give objective and valid answers.  Some are even
>> employed by companies that write C++ compilers and related tools.
>>
>> Thanks for your ball-rolling-start, and I'm sure you will stick
>> around to make sure any answers are more or less reasonable.
>
> C baggage,

Definitely, but C++ would not exist without that baggage, so it is kind 
of a moot point. Basically, to say that is to say that what is wrong with 
C++ is that it is C++, which is of course true, but pretty much ends the 
thread then.

Re: What's wrong with C++?

[Vinzent Hoefler]

Nasser M. Abbasi wrote:

> On 2/19/2011 4:55 PM, Nomen Nescio wrote:
>
>> Maybe you should have some respect for your elders ;)
>
> You are right there, one should always respect their elders,
> even when they are dead wrong ;)

But you are the one being wrong and you even know it.

<http://en.wikipedia.org/wiki/Fortran#cite_note-0>:

|The names of earlier versions of the language through FORTRAN 77 were
|conventionally spelled in all-caps (FORTRAN 77 was the version in which
|the use of lowercase letters in keywords was strictly nonstandard). The
|capitalization has been dropped in referring to newer versions beginning
|with Fortran 90.


Vinzent.

-- 
You know, we're sitting on four million pounds of fuel, one nuclear weapon,
and a thing that has 270,000 moving parts built by the lowest bidder.
Makes you feel good, doesn't it?
   --  Rockhound, "Armageddon"

Re: What's wrong with C++?

[Brian Drummond]

On Sat, 19 Feb 2011 22:41:46 -0600, "Chuck" <chuckmacdonald@nospam.me> wrote:

>KK6GM wrote:
>> This is a serious question, seeking objective information.  I've
>> worked with C for many years and I have a very good understanding of
>> its weaknesses, which are many.  I haven't done nearly so much C++,
>> and what I have done was not very intensive (didn't use a great many
>> C+ + features), so I don't have a good understanding of its
>> weaknesses.
>>
>> So, without turning into a bash-fest, what are some general-consensus
>> weaknesses or failures or problems with C++?  Comparisons with Ada are
>> welcome but not required.  And my focus is in the embedded & real-time
>> arenas, FWIW.
>
>What wrong with C++? It may be better to ask what is wrong with the other 
>2! Anyway, the list of what is right with C++ is much, much shorter, so 
>by process of elimination, what is not on the good list, is on the bad 
>list. Here's my list of good things:
>
>  Uses curly-braces, mostly effectively.
>
>I'll add to this list as I think of any more things.

Demolishes the argument that Ada is too complex for anyone to learn?

- Brian

Re: What's wrong with C++?

[Britt Snodgrass]

On Feb 19, 10:41 pm, "Chuck" <chuckmacdon...@nospam.me> wrote:

> What wrong with C++? It may be better to ask what is wrong with the other
> 2! Anyway, the list of what is right with C++ is much, much shorter, so
> by process of elimination, what is not on the good list, is on the bad
> list. Here's my list of good things:
>
>   Uses curly-braces, mostly effectively.
>
> I'll add to this list as I think of any more things.

No, "uses curly-braces" is an item for the bad list, unless one enjoys
using their editor's match-brace function and scrolling up/down a lot.

- Britt

Re: What's wrong with C++?

[Martin Krischik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.02.11 18:39, schrieb Paul Colin Gloster:

> Do you also dislike Ada's operator overloading?

No. I think the problem is that C++ has set some bad example of operator
overloading. Like << and >>. They are supposed to be shift operators but
not when IO is involved. Missuse is the problem here.

And speaking of Ada: whenever the unary + is used for type conversion in
gives me creeps. Because that is precisely what you should not do.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNbRYnijwKaHyem9cRAsKGAJ0Sh4fkj6pnRTJx1kzienJ6GLCJAgCfZHo+
SaUQ3mSKi8+8fTqijQxEE04=
=CWN8
-----END PGP SIGNATURE-----

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Wed, 16 Feb 2011 18:37:12 +0100, KK6GM <mjsilva@scriptoriumdesigns.com>  
a écrit:

> This is a serious question, seeking objective information.  I've
> worked with C for many years and I have a very good understanding of
> its weaknesses, which are many.  I haven't done nearly so much C++,
> and what I have done was not very intensive (didn't use a great many C+
> + features), so I don't have a good understanding of its weaknesses.
>
> So, without turning into a bash-fest, what are some general-consensus
> weaknesses or failures or problems with C++?

Here is an easy to read interesting answer to that question, from a C++  
user, reporting about a C++ conference he attended to.

http://cpptruths.blogspot.com/2005/10/whats-wrong-with-c.html


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 22:51:29 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Here is an easy to read interesting answer to that question, from a C++  
> user, reporting about a C++ conference he attended to.
>
> http://cpptruths.blogspot.com/2005/10/whats-wrong-with-c.html

Quoted from a comment in the above link

> "One of the big issues was the extreme difficulty of parsing C++."
>
> It is ___provably___ impossible to write a correct C++ parser which
> will complete compilation with either success of failure because the
> C++ template system is Turing complete. This means that code generation
> is based on a turing complete program. Code generation in C++ isn't
> based on a program description, but an actual turing complete program.
>
> As such, it is subject to the halting problem. Therefore, it is
> unknowable whether a compilation will complete, and unknowable if
> you are looking at a valid C++ program.

So OK, it is formally proved that is not even sure a given C++ source file  
can really be compiled or not. That's big, ouch.

That achieve to prove that along with the domain troubles and  
difficulties, you are also in as great troubles with the source it self.

May be C++ would need to go beyond of Ada SPARK or Ada design by contract  
(tm), and add stuff to prove a C++ source is correct and can be compiled,  
before any attempt to prove what it will compiled is correct (oops).


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Peter C. Chapin]

On Tue, 04 Oct 2011 23:00:20 +0200, Yannick Duchêne (Hibou57) wrote:

> So OK, it is formally proved that is not even sure a given C++ source
> file can really be compiled or not. That's big, ouch.

I don't think this is a big deal. It's an interesting theoretical 
observation with little practical significance. For one thing, I doubt 
any reasonably normal looking program would invoke this behavior. A 
broken program might, I suppose, but non-termination of the compiler is 
not much different than a compile error. Nobody is injured by the program 
it didn't create; it's only an inconvenience to the programmer who has to 
adjust the source.

C++ isn't alone with this problem either. I understand that Scala's type 
system is also Turing complete. It is possible, apparently, to write a 
Scala program for which type checking never terminates. Again it's an 
interesting theoretical observation but I don't think anyone really cares.

In our work at VTC on translating some NASA software to SPARK we 
encountered a situation where the SPARK simplifier took an "infinitely" 
long time to execute... well, okay, it only took about an hour. Yes it 
did terminate but it took so long that development was impractical (no 
different, really, than true non-termination). Our response: fix the 
source.

Peter

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Wed, 05 Oct 2011 03:53:28 +0200, Peter C. Chapin <PChapin@vtc.vsc.edu>  
a écrit:
> I don't think this is a big deal. It's an interesting theoretical
> observation with little practical significance.
Bad theoretical background is no good (at least, it matters to me, to me,  
it is a base of trustability).

> Nobody is injured by the program
> it didn't create; it's only an inconvenience to the programmer who has to
> adjust the source.
Except the comment which follows the one I quoted, says

> oops, the C++ spec allows implementations to terminate compilesif they  
> recurse too deeply. Nevermind.
That's no good again. After that, a compiler, may produce invalid output.

> C++ isn't alone with this problem either. I understand that Scala's type
> system is also Turing complete.
Did not learned Scala yet (you recalled me to do it a future day, thanks  
for that)

> It is possible, apparently, to write a
> Scala program for which type checking never terminates. Again it's an
> interesting theoretical observation but I don't think anyone really  
> cares.
Really, I do, this really frighten me. I could not trust such a language.

> In our work at VTC on translating some NASA software to SPARK we
> encountered a situation where the SPARK simplifier took an "infinitely"
> long time to execute... well, okay, it only took about an hour. Yes it
> did terminate but it took so long that development was impractical (no
> different, really, than true non-termination). Our response: fix the
> source.
That's not the same. When a Prolog program does not terminates, this  
means: “nothing proved”, “don't known”, “uninterpretable”. If you stop it  
after some time because you don't even know if it gonna ever terminates,  
that's the same, “uninterpretable”. And for you, it did terminates, it did  
not stop after a too much deep recursion, then proudly asserting, “OK  
guys, that's fine, your VC is proved”. Or did it ?

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Jeffrey Carter]

On 10/04/2011 07:13 PM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 05 Oct 2011 03:53:28 +0200, Peter C. Chapin <PChapin@vtc.vsc.edu> a écrit:
>> I don't think this is a big deal. It's an interesting theoretical
>> observation with little practical significance.
> Bad theoretical background is no good (at least, it matters to me, to me, it is
> a base of trustability).

Most people misunderstand the halting problem, thinking it proves that it is 
impossible to prove whether a program halts. In fact, it says it's impossible to 
write a program that, in finite time, can say whether any possible program halts 
for all inputs. It does not say it's impossible to write a program that can say 
whether a specific program halts for all inputs, or whether a subset of programs 
halt for all inputs.

In fact, there are programs now that can prove whether most sequential programs 
halt for all inputs. See the article "Proving Program Termination" by Cook, 
Podelski, and Rybalchenko in the 2011 May /Communications of the ACM/ for an 
overview of current work on this subject. These programs can, in finite time, 
return Terminates, Doesn't Terminate, or Unknown, on real code of reasonable 
size, with Unknown returned infrequently enough that the programs are useful in 
practice.

So I agree that the Turing completeness of C++ templates is unlikely to be a 
problem for real-world programs.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: What's wrong with C++?

[Niklas Holsti]

On 11-10-05 04:13 , Yannick Duchêne (Hibou57) wrote:
> Le Wed, 05 Oct 2011 03:53:28 +0200, Peter C. Chapin
> <PChapin@vtc.vsc.edu> a écrit:
>> I don't think this is a big deal. It's an interesting theoretical
>> observation with little practical significance.
> Bad theoretical background is no good (at least, it matters to me, to
> me, it is a base of trustability).

Doesn't Ada have a similar theoretical problem with the elaboration 
order? I seem to remember that finding a valid elaboration order for an 
arbitrary Ada program is rather difficult, in general, and compilers are 
allowed to give up on it.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Wed, 05 Oct 2011 06:48:43 +0200, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> Most people misunderstand the halting problem, thinking it proves that  
> it is impossible to prove whether a program halts. In fact, it says it's  
> impossible to write a program that, in finite time, can say whether any  
> possible program halts for all inputs. It does not say it's impossible  
> to write a program that can say whether a specific program halts for all  
> inputs, or whether a subset of programs halt for all inputs.
Yes

> In fact, there are programs now that can prove whether most sequential  
> programs halt for all inputs. See the article "Proving Program  
> Termination" by Cook, Podelski, and Rybalchenko in the 2011 May  
> /Communications of the ACM/ for an overview of current work on this  
> subject.
Thanks for the reference

> So I agree that the Turing completeness of C++ templates is unlikely to  
> be a problem for real-world programs.
Still does not change anything about the background. At least, if C++  
embeds a meta-programming language to such a level, then there should be  
two distinct languages, which should be executed separately. This should  
be required to at least be able to trace execution of both. So here, you  
have execution of a program: how do you trace its execution if ever needed  
? How do you prove it's correct if ever required ? I am not opposed to  
meta-programming (I am even in favor of it), but this should belong to  
specific layers, each. If I understand this blog paper, that is not the  
case (the time I used C++, I've never heard of something like this).


With that, you have the macro language which is a powerful way to scatter  
the source in any silly ways you want, and now, you have a meta-language  
merged into the language. I don't believe that help to trust your  
understanding of the source you are reading.

I agree this may be usable, just like the rest of C++ is usable, if you  
conscientiously keep track of traps you have to avoid (yes, I know there  
may be some traps with Ada too, like mutable records are from some point  
of views, except there are probably far few, and nothing comparable to  
that).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Wed, 05 Oct 2011 07:13:16 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> Doesn't Ada have a similar theoretical problem with the elaboration  
> order? I seem to remember that finding a valid elaboration order for an  
> arbitrary Ada program is rather difficult, in general, and compilers are  
> allowed to give up on it.
I am not aware enough of the techniques used there, and not a compiler  
implementor, but I guess this is a divide-and-conquer strategy. I suppose  
this end to be solving a graph route problem, not a Turing complete  
language interpretation.

You raised a good question anyway, I'm curious to know (may be an answer  
in some GNAT design papers, or some answers from Randy).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Jeffrey Carter]

On 10/04/2011 11:21 PM, Yannick Duchêne (Hibou57) wrote:
>
> With that, you have the macro language which is a powerful way to scatter the
> source in any silly ways you want, and now, you have a meta-language merged into
> the language. I don't believe that help to trust your understanding of the
> source you are reading.

I'm not saying that it's a good thing. Simply that it's unlikely to be a problem 
in practice. There are plenty of other reasons not to use C++; we shouldn't 
emphasize something that isn't a problem in practice when pointing out its problems.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: What's wrong with C++?

[Jeffrey Carter]

On 10/04/2011 11:33 PM, Yannick Duchêne (Hibou57) wrote:
> I am not aware enough of the techniques used there, and not a compiler
> implementor, but I guess this is a divide-and-conquer strategy. I suppose this
> end to be solving a graph route problem, not a Turing complete language
> interpretation.

I think Duff has some ideas about elaboration, which he posted here a few years 
ago. His proposal, IIRC, is that elaboration dependencies form a partially 
ordered acyclic directed graph. At some points there are groups of units which 
may be elaborated in any order. He proposes imposing an arbitrary ordering 
within those groups, such that the whole thing becomes fully ordered and defines 
a correct elaboration order. He suggested using the lexical order of the unit 
names as the arbitrary ordering.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: What's wrong with C++?

[Peter C. Chapin]

On Wed, 05 Oct 2011 04:13:22 +0200, Yannick Duchêne (Hibou57) wrote:

>> oops, the C++ spec allows implementations to terminate compiles if they
>> recurse too deeply. Nevermind.
> That's no good again. After that, a compiler, may produce invalid
> output.

The C++ compilers I've used where I've seen this happen (mostly while 
experimenting with metaprogramming) all produced an error message about 
"template instantiation depth exceeded" or something like that. None of 
them silently produced incorrect code.

Peter

Re: What's wrong with C++?

[Hyman Rosen]

On 10/6/2011 9:19 AM, Peter C. Chapin wrote:
> On Wed, 05 Oct 2011 04:13:22 +0200, Yannick Duchêne (Hibou57) wrote:
> The C++ compilers I've used where I've seen this happen (mostly while
> experimenting with metaprogramming) all produced an error message about
> "template instantiation depth exceeded" or something like that. None of
> them silently produced incorrect code.

I have unfortunately had the opposite experience with an older
version of Sun CC for Sparc. I was doing a kind of template
"recursion" as in the following code:

     struct Nil { };

     template <class First, class Rest>
     struct Cons { First first; Rest rest; };

     template <class T> void do_something(T) { }

     inline void apply_do_something(Nil) { }

     template <class First, class Rest>
     inline void apply_do_something(Cons<First, Rest> object)
     {
         do_something(object.first);
         apply_do_something(object.rest);
     }

The idea is that you build up a nested Cons structure of the
types you want to store, and then calling iterate on an object
of that type generates an inline expansion resulting in an
unrolled call of the do_something method on each field of the
structure, with no actual recursion at runtime.

Unfortunately, when my structure got nested too deeply, the
compiler silently terminated the recursion with an 'int'! It
took some strenuous debugging to figure that out, and I had to
abandon this approach altogether.

Re: What's wrong with C++?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

"Peter C. Chapin" <PChapin@vtc.vsc.edu> wrote in message 
news:EeadnV_UDMIFJRbT4p2dnAA@giganews.com...
> On Tue, 04 Oct 2011 23:00:20 +0200, Yannick Duch�ne (Hibou57) wrote:
>
>> So OK, it is formally proved that is not even sure a given C++ source
>> file can really be compiled or not. That's big, ouch.
...
> In our work at VTC on translating some NASA software to SPARK we
> encountered a situation where the SPARK simplifier took an "infinitely"
> long time to execute... well, okay, it only took about an hour. Yes it
> did terminate but it took so long that development was impractical (no
> different, really, than true non-termination). Our response: fix the
> source.

But isn't that a really terrible error message? When I've had compiler bugs 
that caused infinite loops, I've often spent many hours trying to find a 
work-around, and only trial-and-error works (there being no information at 
all as to the cause). And I've had a great advantage to the vast majority of 
programmers in that I have access to the compiler source and a good 
knowledge of how the compiler works internally. The vast majority of 
programmers would have no such advantages (and probably could not wait for 
compiler support to bail them out, either).

So a language design which has a significantly >0% chance of having this 
happen is potentially a time-bomb in your development schedules. (Such bugs 
have stopped my work cold until a work-around could be found.) That seems 
bad (how bad depends on the likelyhood of it happening).

                               Randy.

Re: What's wrong with C++?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.v2u8hzeyule2fv@index.ici...
>e Wed, 05 Oct 2011 07:13:16 +0200, Niklas Holsti 
><niklas.holsti@tidorum.invalid> a �crit:
>> Doesn't Ada have a similar theoretical problem with the elaboration 
>> order? I seem to remember that finding a valid elaboration order for an 
>> arbitrary Ada program is rather difficult, in general, and compilers are 
>> allowed to give up on it.
>I am not aware enough of the techniques used there, and not a compiler 
>implementor, but I guess this is a divide-and-conquer strategy. I suppose 
>this end to be solving a graph route problem, not a Turing complete 
>language interpretation.
>
>You raised a good question anyway, I'm curious to know (may be an answer 
>in some GNAT design papers, or some answers from Randy).

I implemented that a long, long time ago, and haven't had to fix anything in 
it in a long time, so my memory may be wrong, but here's a short 
explanation:

Janus/Ada uses a trial-and-error approach. I figured this was only run once 
per program, and the number of units involved is usually not that large, so 
a quadratic algorithm isn't a problem.

Essentially, the algorithm checks the entire list of units (parts, spec and 
bodies are different), with all of the dependencies included, for one all of 
whose dependencies are already elaborated. As soon as it finds one, it 
elaborates that, and then starts over from the beginning. If at any point, 
there is no such unit available, it then gives up trying and produces an 
error message (the program must not have any consistent elaboration order).

The algorithm is complicated by needing to elaborate pure/preelaborated 
units first, by attempting to keep specs and bodies together when possible, 
and by elaboration pragmas. These are resolved by having various "soft" 
dependencies; if no unit can be found that do not violate any of the 
dependencies, the algorithm tries again looking for units that have all of 
their hard dependencies loaded.

I don't know of any real problem with elaboration given the Ada rules; the 
usual problem comes when someone tries to change those rules from dynamic to 
static rules (as GNAT does). Janus/Ada doesn't attempt that.

                                 Randy.

Re: What's wrong with C++?

[Niklas Holsti]

On 11-10-08 03:36 , Randy Brukardt wrote:
> "Yannick Duch�ne (Hibou57)"<yannick_duchene@yahoo.fr>  wrote in message
> news:op.v2u8hzeyule2fv@index.ici...
>> e Wed, 05 Oct 2011 07:13:16 +0200, Niklas Holsti
>> <niklas.holsti@tidorum.invalid>  a �crit:
>>> Doesn't Ada have a similar theoretical problem with the elaboration
>>> order? I seem to remember that finding a valid elaboration order for an
>>> arbitrary Ada program is rather difficult, in general, and compilers are
>>> allowed to give up on it.
>> I am not aware enough of the techniques used there, and not a compiler
>> implementor, but I guess this is a divide-and-conquer strategy. I suppose
>> this end to be solving a graph route problem, not a Turing complete
>> language interpretation.
>>
>> You raised a good question anyway, I'm curious to know (may be an answer
>> in some GNAT design papers, or some answers from Randy).
>
> I implemented that a long, long time ago, and haven't had to fix anything in
> it in a long time,...
   [snip]
> I don't know of any real problem with elaboration given the Ada rules; the
> usual problem comes when someone tries to change those rules from dynamic to
> static rules (as GNAT does). Janus/Ada doesn't attempt that.

Thanks for your explanation, Randy.

I think the problem I remembered was to find an elaboration order such 
that the program would be certain not to call a non-elaborated 
subprogram, that is, that it would not raise Program_Error because of a 
failed Elaboration_Check (LRM 3.11). So it requires more than finding an 
order that is valid according to the LRM dependency rules.

Having now re-read some of the GNAT User Guide chapter on elaboration, 
my understanding is that in general such an elaboration order may not 
exist, and it is unsolvable to decide if it exist, and unsolvable to 
find it, if it does exist. But if you follow the static rules suggested 
in the GNAT UG, the compiler either finds a such an order, or tells you 
why it can't.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: What's wrong with C++?

[Peter C. Chapin]

On 2011-10-07 21:24, Randy Brukardt wrote:

> But isn't that a really terrible error message? When I've had compiler bugs
> that caused infinite loops, I've often spent many hours trying to find a
> work-around, and only trial-and-error works (there being no information at
> all as to the cause).

You're right, of course, that the "error message" is not very helpful 
when the compiler just fails to terminate. In our case it wasn't too bad 
because we were doing frequent builds so the amount of material under 
suspicion was not large.

The problem was due to a subprogram with a large number of overly 
complicated expressions... a relatively well isolated construct. The 
SPARK simplifier appeared to hang while processing that subprogram (it 
was nice that it outputs a message each time it moves on to a different 
one) so it was pretty obvious what the problem was once we looked at the 
offending code and at the massive collection of VCs the Examiner had 
created for that code. We also learned an important lesson about SPARK: 
keep it simple.

Peter

Re: What's wrong with C++?

[Jeffrey Carter]

On 10/08/2011 06:14 AM, Peter C. Chapin wrote:
>
> We also learned animportant lesson about SPARK: keep it simple.

That's an important lesson for SW in general.

-- 
Jeff Carter
"I didn't squawk about the steak, dear. I
merely said I didn't see that old horse
that used to be tethered outside here."
Never Give a Sucker an Even Break
103

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Sat, 08 Oct 2011 03:36:23 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> I don't know of any real problem with elaboration given the Ada rules;  
> the usual problem comes when someone tries to change those rules from  
> dynamic to static rules (as GNAT does). Janus/Ada doesn't attempt that.
>
>                                  Randy.

Nice to know that, interesting. This also underline how important it is to  
have multiple implementation of the same thing, and not just a single one.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Sat, 08 Oct 2011 15:14:15 +0200, Peter C. Chapin <PChapin@vtc.vsc.edu>
a écrit:
> We also learned an important lesson about SPARK: keep it simple.
>
> Peter

Although I enjoy the principle of SPARK, I had to drop the idea to use it  
as something common, precisely due to the fact it is not easy to guess if  
something is simple enough for SPARK or not. I get it running for some  
very long time too, except this was with simple things to me. Designing  
proof which “should” be OK is one thing, mastering SPARK enough is real  
life, another (note: my intent is not to reprimand SPARK at all, it's too  
much valuable, and there is no ready accessible alternatives).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: What's wrong with C++?

[Paul Colin Gloster]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 374 bytes --]

Yannick Duchêne (Hibou57) <yannick_duchene@Yahoo.Fr> sent on October 9th, 2011:
|-------------------------------------|
|"[..]                                |
|[..] SPARK [..] and there is no ready|
|accessible alternatives)."           |
|-------------------------------------|

There are many alternatives, but they lack built-in
integration with Ada by default.

Re: What's wrong with C++?

[Yannick Duchêne (Hibou57)]

Le Mon, 10 Oct 2011 15:31:21 +0200, Paul Colin Gloster  
<Colin_Paul_Gloster@acm.org> a écrit:

> Yannick Duchêne (Hibou57) <yannick_duchene@Yahoo.Fr> sent on October  
> 9th, 2011:
> |-------------------------------------|
> |"[..]                                |
> |[..] SPARK [..] and there is no ready|
> |accessible alternatives)."           |
> |-------------------------------------|
>
> There are many alternatives, but they lack built-in
> integration with Ada by default.

Yes, it has too infer value ranges and other implicit validity conditions  
automatically, without explicit specifications from the author (will have  
a look at Alt-Ergo a future day, and an even farer future day, will have  
some personal experiments with something).

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

SPARK and other provers (Was: Re: What's wrong with C++?)

[Phil Thornley]

On Oct 11, 8:45 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 10 Oct 2011 15:31:21 +0200, Paul Colin Gloster  
> <Colin_Paul_Glos...@acm.org> a écrit:
>
> > Yannick Duchêne (Hibou57) <yannick_duch...@Yahoo.Fr> sent on October  
> > 9th, 2011:
> > |-------------------------------------|
> > |"[..]                                |
> > |[..] SPARK [..] and there is no ready|
> > |accessible alternatives)."           |
> > |-------------------------------------|
>
> > There are many alternatives, but they lack built-in
> > integration with Ada by default.
>
> Yes, it has too infer value ranges and other implicit validity conditions  
> automatically, without explicit specifications from the author (will have  
> a look at Alt-Ergo a future day, and an even farer future day, will have  
> some personal experiments with something).
>

If you are considering using Alt-Ergo with SPARK you may be interested
in this result from an experiment.

Using some code that was already proved using the Simplifier (and
which required a number of user rules) I let Alt-Ergo have a go at all
the VCs that the Simplifer was unable to prove directly (i.e. without
user rules).

The first discovery was that the default proof steps limit (set to
5000 in GPS) is way too high (at least for my desktop - Core
i5/750@2.67GHz).  I had to bring it down to the 300-500 range.

Secondly the Victor driver (the interface to Alt-Ergo) supplied with
SPARK (and used by GPS) is very inflexible:
- It enforces the option that all conclusions of a VC are 'fused' - so
that failure to prove any one conclusion means that none of the
conclusions are reported as proved - and there seems to be no way to
find out which conclusion(s) are/are not provable.
- There is no way for the user to supply any user rules to Alt-Ergo.
This is essential if Alt-Ergo is going to have any chance of proving
VCs that reference proof functions.
(These restrictions can be easily worked round by some simple mods to
the victor driver program.)

Using the victor driver from the command line would also get round
these problems, but the documentation provides no help with this.

With these changes, the figures from the POGS summary are (omitting
columns with all zeros):

Total VCs by type:
                       -----------Proved By Or Using-----------
                Total  Spark   Simp (User) ViCToR
Assert/Post       118      0    100(   36)     18
Precondition       45      0     36(    3)      9
Check stmnt.      222      0    206(  154)     16
Runtime check     195      0    195             0
Refinem. VCs        6      5      1(    1)      0
Inherit. VCs        0      0      0             0
=================================================
Totals:           586      5    538(  194)     43
%Totals:                  1%    92%(  33%)     7%

So Alt-Ergo completes the proof of 43 out of 237 VCs that are not
directly proved by the Simplifier.

That's one data point - does anyone else have any others?

Cheers,

Phil