Re: why learn C?

Re: why learn C?

[Marc Boyer]

Le 23-02-2007, Default User <defaultuserbr@yahoo.com> a �crit�:
> Marc Boyer wrote:
>
>> Le 22-02-2007, arnuld <geek.arnuld@gmail.com> a �crit�:
>> >> > 1. C gives you a strong base of Procedural style of programming
>> which >> > forms the basis of learning other paradigms e.g OOP
>> > 
>> >>   I am not sure that C gives better 'strong base' than Ada.
>> > 
>> > OK, 1st have to Google for Ada as i never came across some
>> > Ada-code. i never even read about its design-goals and/or any
>> > articles related to it.
>> 
>>   comp.lang.ada
>> 
>> > BTW, your "summary of Ada" can be useful for me, if you can.
>> 
>>   In a very few words, Ada is a modern Pascal. 
>
> That's way too few. 

  If you have time to give a long definition of Ada, just do it.

> Ada was a language created from scratch for
> high-safety programming, commissioned by the US Department of Defense.
> It's based on Pascal, but no more a "modern Pascal" than C++ is a
> "modern C".

  I agree.

>> And Ada 83 
>> is, to me, a very good langage to learn procedural programming.
>
> It used to be difficult to find free Ada compilers (or even any that
> didn't cost a fortune). A brief bit of searching seems to indicate that
> that's not so much the case anymore.

   What about GNAT ?

Marc Boyer

Re: why learn C?

[adaworks]

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message >
>
>  If you have time to give a long definition of Ada, just do it.
>
Definition is not a word that would apply when one is seeking
a deeper understanding of a subject.   One could provide a
definition of calculus, quantum mechanics, or the word, virus,
but a definition would not provide a deep insight into those
subjects.

Ada is a language designed to maximize the amount of error detection
as early in the development process as possible, and throughout each
subsequent step of that process.

Ada provides the developer with more engineering tools and idioms
for the development of software than one finds in a lot of other
languages.   A source code model, in the form of Ada package
specifications, can be created long before anyone writes any
algorithmic code.   The entire design can be structured and tested
prior to committing too much to small details.   For a large project,
where many thousands of lines of code are required, that project
can be decomposed and distributed over several programming
teams without excessive worry about whether the resulting
code will conform to the design.

Unlike the C family of languages, which are generally no help at all,
an Ada compiler frequently eliminates the need for extensive debugging
of silly errors; e.g., the kind that originate from case-sensitivity, wrong
order of arguments to parameters, improper spacing, missing curly-braces,
and the plethora of language "features" that plague those who have
chosen to use any member of the C family of languages.

It has always seemed rather odd to me that people who are as intelligent
as programmers, rarely question the silliness of using tools such as C
and C++ for serious work.  They simply take for granted that the kind
of errors that are so common in those languages are somehow akin to
the laws of nature.  Java inherits many of those same properties and
is not much better.   It is taken as an article of faith that programming
involves heavy use of debuggers.  Instead of asking why this is so, they
simply believe it is a fundamental law of programming -- mainly because
the languages they have chosen make it so.

Ada is a programming language that makes it easier to focus on the design
before dealing with the details of that design.  Then, Ada  makes it easier to
ensure that the details conform to the design.  I wonder why that is such
a difficult concept for so many.

Richard Riehle

     It always amazes me that someone would choose an error-prone
     programming language such as C++ and expect error-free programs.

Re: why learn C?

[Maciej Sobczak]

adaworks@sbcglobal.net wrote:

> Unlike the C family of languages,

I presume you mean C, C++, D, Java, C#.

> which are generally no help at all,

That's indeed "generally".

> an Ada compiler frequently eliminates the need for extensive debugging
> of silly errors; e.g., the kind that originate from case-sensitivity

Tha last time I made case-sensitivity error the compiler helped me.

> wrong
> order of arguments to parameters

I can do this error in Ada quite easily.

Yes, there are named parameters in Ada. And structures with named 
components in other languages.

> improper spacing,

Please provide an example of code where improper spacing leads to 
extensive debugging.

> missing curly-braces,

The last time I missed the curly brace the compiler told me that.

(for the sake of this discussion let's forget about the fact that in any 
self-respecting programmer's editor missing curly-brace is plain 
impossible, because braces are part of text formatting rules)

> and the plethora of language "features" that plague those who have
> chosen to use any member of the C family of languages.

Any language (from any family) older than one version has "features".

> It has always seemed rather odd to me that people who are as intelligent
> as programmers, rarely question the silliness of using tools such as C
> and C++ for serious work.

Maybe because they are intelligent and can reasonably balance pros and 
cons of various technology choices.

> They simply take for granted that the kind
> of errors that are so common in those languages are somehow akin to
> the laws of nature.

That's a good point and indeed a significant fraction of the community 
takes errors as part of the game. But I wouldn't attribute it only to 
the language choice (although that's an important factor indeed), also 
to the massive approach to education ("learn programming in 24 hours now!").
Teach millions to program in Ada and you get tons of crappy code.

> Java inherits many of those same properties and
> is not much better.

True.

> It is taken as an article of faith that programming
> involves heavy use of debuggers.

Not necessarily. The advocates of test-driven development (TDD for 
short) openly say good bye to debuggers, at least in blogs.

> Ada is a programming language that makes it easier to focus on the design
> before dealing with the details of that design.

Yes, but Ada is not unique here. In C++ or Java you can do a lot of 
design before actual implementation starts.

> Then, Ada  makes it easier to
> ensure that the details conform to the design.

Yes, but Ada is not unique here. There are differences in what is the 
scope and precision of design expression, of course, and this is where 
Ada shines. But conformance between the details and the design (specs) 
is ensured in every static language.

> I wonder why that is such
> a difficult concept for so many.

It isn't. Only the tradeoffs change.

>      It always amazes me that someone would choose an error-prone
>      programming language such as C++ and expect error-free programs.

It always amazes me that someone would choose a language that has no 
measurable user base such as Ada and expect to build a successful team.

The missing user base is one of two major problems that prevent me from 
starting an Ada project, whether at work or in my free time.
The other is the lack of *free* Ada compiler on one of my target 
platforms (LynxOS).

"There are just two kinds of languages: the ones everybody complains 
about and the ones nobody uses." - Bjarne Stroustrup.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: why learn C?

[Alexander E. Kopilovich]

>It has always seemed rather odd to me that people who are as intelligent
>as programmers, rarely question the silliness of using tools such as C
>and C++ for serious work.

Well, which work is "serious", and which is not?

And even if some project as a whole is commonly agreed as "serious", does
this imply that every piece of it (perhaps easily replaceble), every
subcontracted supply for it, and every tool used (directly or indirectly)
for it - is "serious" also?

>  They simply take for granted that the kind
>of errors that are so common in those languages are somehow akin to
>the laws of nature.

They simply see that too many programmers that participate (directly or
indirectly) in very many projects - including big projects - do not posses
understanding of what they are doing, and actually quite often aren't much
interested in it.

It should be only too clear for every "intelligent programmer" that widespread
(and ever-increasing) use of hordes of low-paid half-educated programmers
matters much more than a particular choice of programming language.

And indeed, it may be well possible that in such circumstances C/C++ is really
better choice than Ada for many reasons, including the languages attitudes 
that are more congenial to the mentality of the vast majority of developers.

Re: why learn C?

[Martin Krischik]

Maciej Sobczak schrieb:

>> missing curly-braces,
> 
> The last time I missed the curly brace the compiler told me that.

The editor to fix deficiencies of the language - great!

> (for the sake of this discussion let's forget about the fact that in any 
> self-respecting programmer's editor missing curly-brace is plain 
> impossible, because braces are part of text formatting rules)

I guess he speaks of

if (X=1)
   A=2;
   B=2;

and

if (X=1);
   A=2;

i.E. you forget the both - in which case no editor will help you.


>> and the plethora of language "features" that plague those who have
>> chosen to use any member of the C family of languages.
> 
> Any language (from any family) older than one version has "features".

But if you start with too few features and a foundation to weak to build 
on (in version 1) then add on features are a greater problem (in version 
3). In the end worse is not better.

>> It has always seemed rather odd to me that people who are as intelligent
>> as programmers, rarely question the silliness of using tools such as C
>> and C++ for serious work.
> 
> Maybe because they are intelligent and can reasonably balance pros and 
> cons of various technology choices.

I did and after 10+ years of C/C++ the scale finally tilted and I 
switched to Ada. Recently I went to an Weblogic course with lots of Java 
in it - yuck!

> "There are just two kinds of languages: the ones everybody complains 
> about and the ones nobody uses." - Bjarne Stroustrup.

:-\

Martin

Re: why learn C?

[Dmitry A. Kazakov]

On Wed, 21 Mar 2007 09:07:30 +0100, Maciej Sobczak wrote:

> "There are just two kinds of languages: the ones everybody complains 
> about and the ones nobody uses." - Bjarne Stroustrup.

Looks that he isn't much satisfied with his life work?

To me C++ has too much aftertaste, like a sticky candy found in a pocket of
your old coat...

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

Re: why learn C?

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10qp8zioik6f5$.11yljhdfb5t44$.dlg@40tude.net...
> On Wed, 21 Mar 2007 09:07:30 +0100, Maciej Sobczak wrote:
>
>> "There are just two kinds of languages: the ones everybody complains
>> about and the ones nobody uses." - Bjarne Stroustrup.
>
> Looks that he isn't much satisfied with his life work?
>
> To me C++ has too much aftertaste, like a sticky candy found in a pocket of
> your old coat...
>
Or like peanut brittle.  It can initially taste good, but it eventually
helps rot your teeth (or program), and breaks easily.

Richard Riehle 

Re: why learn C?

[Georg Bauhaus]

On Wed, 2007-03-21 at 10:48 -0800, adaworks@sbcglobal.net wrote:
> "Maciej Sobczak" <no.spam@no.spam.com> wrote in message 

> > Yes, there are named parameters in Ada. And structures with named components 
> > in other languages.
> >
> This is not even an option in C/C++/Java/ or other of the C family.

C99 has finally got named components, though. Consistent with the
language, it doesn't seem necessary to give a value to all components
of C's equivalent of aggregates:

struct foo
{
  int real_part;
  int surreal_part;
};

typedef struct foo Foo;

Foo plus(Foo a, Foo b)
{
  const Foo result =
    {
      .real_part = a.real_part + b.real_part,
      // .surreal_part = a.surreal_part + b.surreal_part // fine?
    };
  return result;
}

Re: why learn C?

[adaworks]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:etqp42$4g6$1@cernne03.cern.ch...
> adaworks@sbcglobal.net wrote:
>
>> Unlike the C family of languages,
>
> I presume you mean C, C++, D, Java, C#.
>
Actually, D and C# seem a little better than the others
you named.   In fact, there are some features of C#
I quite like, especially when one compares Java.
>
> Tha last time I made case-sensitivity error the compiler helped me.
>
But C/C++/Java compilers are not consistent in this respect, and one
would be foolish to rely on them for that.
>
>> wrong order of arguments to parameters
>
> I can do this error in Ada quite easily.
>
Unless you use named association and avoid the use of
predefined types.
>
> Yes, there are named parameters in Ada. And structures with named components 
> in other languages.
>
This is not even an option in C/C++/Java/ or other of the C family.
>
> Please provide an example of code where improper spacing leads to extensive 
> debugging.
>
Another responder dealt with this.
>
>> missing curly-braces,
>
> The last time I missed the curly brace the compiler told me that.
>
It is not the absence of a single curly-brace, but the occasional absence
of a pair of them that sometimes leads to long and entertaining sessions
of debugging.  This would not happen in Ada.
>
> (for the sake of this discussion let's forget about the fact that in any 
> self-respecting programmer's editor missing curly-brace is plain impossible, 
> because braces are part of text formatting rules)
>
As noted, the problem is not a single missing curly brace.  Further,
misplacement of a curly-brace can also be highly entertaining.  Units
in Ada, including declare blocks (which ought to be used minimally)
have the option of being named.  I use this option consistently.  I don't
have that option in any of the C family of languages.
>
>> and the plethora of language "features" that plague those who have
>> chosen to use any member of the C family of languages.
>
> Any language (from any family) older than one version has "features".
>
And some have more "features" than others.
>
>> It has always seemed rather odd to me that people who are as intelligent
>> as programmers, rarely question the silliness of using tools such as C
>> and C++ for serious work.
>
> Maybe because they are intelligent and can reasonably balance pros and cons of 
> various technology choices.
>
I rather think not.   With all the advantages of Ada over the C family of
languages, it simply makes no sense to choose one of those languages
for any reason other than their availability.  It is somewhat like going to
a fast-food restaurant instead of a restaurant where one would get better
quality food.   The fast food restaurants are quite popular, but they are
not especially beneficial froma dietary perspective.
>
>> They simply take for granted that the kind
>> of errors that are so common in those languages are somehow akin to
>> the laws of nature.
>
> That's a good point and indeed a significant fraction of the community takes 
> errors as part of the game. But I wouldn't attribute it only to the language 
> choice (although that's an important factor indeed), also to the massive 
> approach to education ("learn programming in 24 hours now!").
> Teach millions to program in Ada and you get tons of crappy code.
>
I take your point.   No language by itself can eliminate stupidity.   However,
choosing good tools can make a difference.   Ada is not the right tool for
everything.  I like some of the languages such as Python and Ruby that have
recently come on the scene.  However, those languages are not suitable for
every kind of problem.   We always want to choose the right tool for the
right job.

This discussion centers around the idea of debugging.   Even crappy Ada
is less likely to lead to the onerous level of debugging found in C or C++.

>> Java inherits many of those same properties and  is not much better.
>
> True.
>
>> It is taken as an article of faith that programming
>> involves heavy use of debuggers.
>
> Not necessarily. The advocates of test-driven development (TDD for short) 
> openly say good bye to debuggers, at least in blogs.
>
I am quite aware of TDD.  I am not a fan.   While many of the claims of
the TDD advocates have some virtue, it is a fact that not all errors in a
program can be detected through testing.   Further, as Dijkstra notes, "We
can test for the presence of errors, but not for their absence."   TDD can
be a good technique for augmenting the correctness of a design and its
implementation, but it is no substitute for other methods.  Reliance on
TDD exclusively seems a bit foolhardy, just as reliance on type-safety
alone, inspection alone, exception handling alone, or any of the other
popular approaches to software dependability.
>
Too many TDD advocates seem to reject the importance of developing
rigorous software requirements prior to beginning the programming process.
The notion that the tests are the requirements is naive, at best.  This might
work for smaller software projects where the domain is well-understood,
but it is not appropriate for large-scale software systems where dependability
is life or mission critical.
>
>> Ada is a programming language that makes it easier to focus on the design
>> before dealing with the details of that design.
>
> Yes, but Ada is not unique here. In C++ or Java you can do a lot of design 
> before actual implementation starts.
>
The design of Java fails to encourage good design.   This is, in part, due
to the tight relationship between all of its parts within a single library and
compilation unit.   C++, while supporting a model of separate compilation,
does not support it well.  The relationship between the specification and
the implementation in C++ is sloppy, at best.
>
>> Then, Ada  makes it easier to ensure that the details conform to the design.
>
> Yes, but Ada is not unique here. There are differences in what is the scope 
> and precision of design expression, of course, and this is where Ada shines. 
> But conformance between the details and the design (specs) is ensured in every 
> static language.
>
Well, this is not the case unless one jumps through a lot of hoops to
make sure it is.   It is certainly not the case in C++.   Consider the
requirement for #IFNDEF and other bits of fluff that a C++ programmer
must provide to ensure that all the pieces are where they ought to be.

Ada provides the developer with options that make it much more likely
that everything will snap together as expected.   It gives more of an
engineering flavor of the design and development process.  While it
is true that an Ada developer need not use the options that provide
this capability, those options are not even available in C, C++, Java,
D, or C#.

If I have a torque wrench available and fail to use it, the twisting of
the head from the bolt is my fault.  If, however, I use the torque
wrench correctly, I have a greater chance of doing the job right.
Ada is like a torque wrench in software.  I can measure the level
of torque more easily than I can simply using any old long handled
wrench.  C and C++ are like a long-handled wrench. I can do the
job, but I have little hope of getting it right, and I don't know I've
gotten it wrong until it breaks.

That is one of things I find so fascinating about modern programming:
that programmers take for granted that they cannnot know how good
their program is until something breaks.  With Ada (and also with Eiffel),
one can know much more about what might break, can prevent such
breakage before it happens, and can set the limits for breakages so
they are less probable at testing time and deployment time.
>
>> I wonder why that is such a difficult concept for so many.
>
> It isn't. Only the tradeoffs change.
>
>>      It always amazes me that someone would choose an error-prone
>>      programming language such as C++ and expect error-free programs.
>
> It always amazes me that someone would choose a language that has no 
> measurable user base such as Ada and expect to build a successful team.
>
Again.  I would rather eat at a good restaurant than at a popular fast-food
restaurant, even though such restaurants are not as abudant.
>
> The missing user base is one of two major problems that prevent me from 
> starting an Ada project, whether at work or in my free time.
> The other is the lack of *free* Ada compiler on one of my target platforms 
> (LynxOS).
>
One must live with the limitations imposed.  If there is no compiler for the
platform, the choices are not as happy.  Also, as I noted earlier, Ada is
not the only good tool and is not the right tool in every case.   However,
from my perspective, C++ ought to be the tool of last resort.
>
> "There are just two kinds of languages: the ones everybody complains about and 
> the ones nobody uses." - Bjarne Stroustrup.
>
Dr. Stroustrup did a remarkable design within a boundary that imposed a
lot of restrictions that, even he admits, were not ideal.  Given the constraints
at the time C++ was designed, no one can fault him or criticize him for his
work.   It was brilliant.   However, I am reminded of a TV show called
McGiver where the hero, also highly intelligent and innovative, was able to
invent solutions with a minimum of resources at hand.   Even the most
brilliant of minds, when constrained by an context that limits the options
for a design, will produce a solution that is less than ideal.

The Pythagoreans fell short of their goal of making "number" the universal
foundation for an enduring religion.   They simply did not have everything
they needed to make that happen.   Renes Descartre could not quite bring
himself to recognize negative coordinates.  Many brilliant people over the
millennia have made significant contributions within the constraints of their
environment and context.

C++ was a brilliant piece of design.  It is just not good enough when one
considers the other options currently available.

Richard Riehle 

Re: why learn C?

[Dmitry A. Kazakov]

On Wed, 21 Mar 2007 10:48:45 -0800, adaworks@sbcglobal.net wrote:

> "Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
> news:etqp42$4g6$1@cernne03.cern.ch...

>> Not necessarily. The advocates of test-driven development (TDD for short) 
>> openly say good bye to debuggers, at least in blogs.
>>
> I am quite aware of TDD.  I am not a fan.   While many of the claims of
> the TDD advocates have some virtue, it is a fact that not all errors in a
> program can be detected through testing.   Further, as Dijkstra notes, "We
> can test for the presence of errors, but not for their absence."

I don't think that this is the main weakness of "spinal driven" design. A
more fundamental problem I see in TDD, is that it does not define what is
the goal to achieve [by means of programming]. Dijkstra's critique presumes
existence of some stated correct program behavior. But TDD does not have
it. The target is moving, and all but visible. That is supposed to be a
strength of the approach. But as a consequence the very word "correct"
looses any meaning. Does TDD converge? If it does, what are the properties
of what it would to? What about metrics? etc. In short, I don't trust in
"tests as specifications."

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

Use of declare blocks

[Randy Brukardt]

<adaworks@sbcglobal.net> wrote in message
news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net...
...
>Units
> in Ada, including declare blocks (which ought to be used minimally)
> have the option of being named.

While I generally agree with Richard, I certainly don't agree on the "ought
to be used minimally" here.

I use declare blocks extensively to reduce the scope of temporary variables
in subprograms. They're especially important when the object exists just to
take an unused out parameter, because they greatly reduce the need to come
up with names for the objects. I often have code like:

    declare
            Junk : Index;
    begin
            Insert_Something (..., Result => Junk);
    end;

where the result isn't needed by the following code. (Sure, one could argue
that the underlying library should be improved to avoid the need for this,
but that isn't always possible and in any case changes to widely used
specifications shouldn't be made lightly. And this is just one example, any
sort of temporary has these sorts of requirements.)

The advantage is that if in the future you find that you no longer need the
temporary, you can remove it without heavy code analysis: it is used only in
the one place and there is no worries that it might be reused, or have a
side-effect, or the like.

                        Randy.

Re: Use of declare blocks

[Gautier]

They are also pretty useful for make a relatively comfortable
use of strings with the fixed-length type String, when you don't
want to begin using Unbounded_String and conversions from and
towards the type String - IHMO.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Use of declare blocks

[Gautier]

They are also pretty useful for making a relatively comfortable
use of strings with the fixed-length type String, when you don't
want to begin using Unbounded_String and conversions from and
towards the type String - IHMO.
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Use of declare blocks

[Niklas Holsti]

Randy Brukardt wrote:

> I use declare blocks extensively to reduce the scope of temporary variables
> in subprograms. They're especially important when the object exists just to
> take an unused out parameter, because they greatly reduce the need to come
> up with names for the objects. I often have code like:
> 
>     declare
>             Junk : Index;
>     begin
>             Insert_Something (..., Result => Junk);
>     end;
> 
> where the result isn't needed by the following code.

How about a language extension to omit unused out parameters, for example

    Insert_Something (..., Result => <>);

Perhaps even allowing declaration of optional out parameters, as in

    procedure Insert_Something (..., Result : out Index := <>);

and then a call of Insert_Something could omit Result entirely.

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

Re: Use of declare blocks

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@nospam.please> wrote in message
news:460198f2$0$24601$39db0f71@news.song.fi...
> Randy Brukardt wrote:
>
> > I use declare blocks extensively to reduce the scope of temporary
variables
> > in subprograms. They're especially important when the object exists just
to
> > take an unused out parameter, because they greatly reduce the need to
come
> > up with names for the objects. I often have code like:
> >
> >     declare
> >             Junk : Index;
> >     begin
> >             Insert_Something (..., Result => Junk);
> >     end;
> >
> > where the result isn't needed by the following code.
>
> How about a language extension to omit unused out parameters, for example
>
>     Insert_Something (..., Result => <>);
>
> Perhaps even allowing declaration of optional out parameters, as in
>
>     procedure Insert_Something (..., Result : out Index := <>);
>
> and then a call of Insert_Something could omit Result entirely.

I think both of these would be a tough sell. I'm sure some people would feel
that having an out parameter that you don't need is a design flaw, and we
shouldn't be encouraging design flaws. They come up a lot of foreign library
interfaces, and I suppose the argument would be that they should be wrapped
and hidden (even if that is too expensive for the particular usage).

After all, once of the good things about Ada is that you have to do
something explicit to ignore returned values (including error returns). If
they're mapped as out parameters, you have to write code to discard them
(like the above). If they're mapped as exceptions, you have to handle and
ignore (with a null handler) the exception (or all exceptions). Both of
these are obvious when reading the code. It's a lot harder to detect an
error of omission than an error of commission.

This is similar in some ways to the arguments against out parameters in
functions, where the possibility of unnoticed order dependencies and tricky
expressions makes some people uncomfortable.

                           Randy.

Re: Use of declare blocks

[Adam Beneschan]

On Mar 21, 1:25 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> <adawo...@sbcglobal.net> wrote in message
>
> news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net...
> ...
>
> >Units
> > in Ada, including declare blocks (which ought to be used minimally)
> > have the option of being named.
>
> While I generally agree with Richard, I certainly don't agree on the "ought
> to be used minimally" here.
>
> I use declare blocks extensively to reduce the scope of temporary variables
> in subprograms. They're especially important when the object exists just to
> take an unused out parameter, because they greatly reduce the need to come
> up with names for the objects. I often have code like:
>
>     declare
>             Junk : Index;
>     begin
>             Insert_Something (..., Result => Junk);
>     end;
>
> where the result isn't needed by the following code.

The thing I don't like about this is that it breaks up the algorithm.
If you have a sequence of statements that implements some sort of
algorithm, or a sequence of steps for getting what you want, I'd
prefer to have all the statements together instead of being
interrupted by lines with just keywords or declarations that I don't
care about and that don't add to my understanding of the program.
Having to skip over that stuff is harder on my eyes.  But this is IMHO
strictly a matter of personal preference and taste; there's certainly
nothing wrong with your style and you have good reasons for it.

                              -- Adam

Re: Use of declare blocks

[Adam Beneschan]

On Mar 21, 2:29 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> "Niklas Holsti" <niklas.hol...@nospam.please> wrote in message

> > >     declare
> > >             Junk : Index;
> > >     begin
> > >             Insert_Something (..., Result => Junk);
> > >     end;
>
> > > where the result isn't needed by the following code.
>
> > How about a language extension to omit unused out parameters, for example
>
> >     Insert_Something (..., Result => <>);
>
> > Perhaps even allowing declaration of optional out parameters, as in
>
> >     procedure Insert_Something (..., Result : out Index := <>);
>
> > and then a call of Insert_Something could omit Result entirely.
>
> I think both of these would be a tough sell.

Not to me.  Well, maybe the second one would be.  But the first one,
the ability to call a procedure with a "please discard this" syntax
for an OUT parameter, is something I've often considered suggesting
too.  Of course, it's just syntactic sugar so it's not all that
important, which is one reason why I never bothered to send a proposal
to Ada-Comment.  But I think it would be a cool feature.  I'd use it.


> After all, once of the good things about Ada is that you have to do
> something explicit to ignore returned values (including error returns). If
> they're mapped as out parameters, you have to write code to discard them
> (like the above). If they're mapped as exceptions, you have to handle and
> ignore (with a null handler) the exception (or all exceptions). Both of
> these are obvious when reading the code. It's a lot harder to detect an
> error of omission than an error of commission.

I'm guessing that you meant this argument to apply only to Niklas's
second suggestion, which would allow the out parameter to be
eliminated entirely from the procedure call; having something like
"Result => <>" in a procedure call seems to satisfy your requirement
that you'd have to write code to discard the parameter.

                                -- Adam

Re: why learn C?

[Maciej Sobczak]

Martin Krischik wrote:

>>> missing curly-braces,
>>
>> The last time I missed the curly brace the compiler told me that.
> 
> The editor to fix deficiencies of the language - great!

There is no word "editor" above. I said "compiler".

> I guess he speaks of
> 
> if (X=1)
>   A=2;
>   B=2;
> 
> and
> 
> if (X=1);
>   A=2;
> 
> i.E. you forget the both - in which case no editor will help you.

My editor will help me. I have a coding standard that prevents me from 
writing if (same with while, for, etc.) without any braces, so the above 
will not even go to the compilation stage.
You can call it "fixing the defficiencies of the language", I call it 
"extending the static tool-chain which is already multiphase anyway". 
The final effect - which is really the only thing that matters - is that 
I *don't* have these problems.

But I agree that the bare possibility (standard-wise) to do the above is 
a bad thing.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Use of declare blocks

[Dmitry A. Kazakov]

On Wed, 21 Mar 2007 22:43:58 +0200, Niklas Holsti wrote:

> Randy Brukardt wrote:
> 
>> I use declare blocks extensively to reduce the scope of temporary variables
>> in subprograms. They're especially important when the object exists just to
>> take an unused out parameter, because they greatly reduce the need to come
>> up with names for the objects. I often have code like:
>> 
>>     declare
>>             Junk : Index;
>>     begin
>>             Insert_Something (..., Result => Junk);
>>     end;
>> 
>> where the result isn't needed by the following code.
> 
> How about a language extension to omit unused out parameters, for example
> 
>     Insert_Something (..., Result => <>);

Unused function results are even more offending. I would like to see:

   null <expression>;

instead of

   declare
      Dummy : Guess_What;
   begin
      Dummy := <expression>;
   end;

> Perhaps even allowing declaration of optional out parameters, as in
> 
>     procedure Insert_Something (..., Result : out Index := <>);
>
> and then a call of Insert_Something could omit Result entirely.

That could be difficult because of discriminants. Consider:

   procedure Insert_Something (..., Result : in out String (1..80) := <>);
   procedure Insert_Something (..., Result : in out String (<>) := <>);
  ...

I guess if optional [in] out parameters weren't better solvable with lazy
expressions. If the latter were supported one could provide a non-intrusive
default for outs without magical stuff like <>.

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

Re: Use of declare blocks

[adaworks]

When I say they "ought to be used minimally," I am speaking
from the experience of seeing programmers at former client
sites who used them maximally.

There are several problems with declare blocks.

           1)  They often lead to ad hoc designs,
           2)  They often become long passages of code
                 extending over many pages,
           3)  They look like procedures

It is quite easy in Ada to promote a declare block to a
subprogram and in-line it.  This often has the effect of
inspiring the designer of that declare block to think it
through a bit more carefully.   Sometimes it results in
improving the overall design of the final set of programs.

I recall one aerospace user of Ada in California where the
programmers sprinkled declare blocks all through their code,
almost in a stream-of-consciousness fashion.

When used by someone such as Randy, a programmer who
uses every construct with care and intelligence, the declare
block is not a primay design structure but a way of bringing
subtle refinement to an already good design.

When used in place of careful planning, as it often is, or as an
afterthought, as it often is, the declare block can do more to
muddle the understanding of a piece of code than to improve it.

That being said, Ada blocks, including declare blocks, do have the
virtue that they are well-bounded, can be named, are rigorous in
their obedience to the underlying rules of the language, and useful
in those rare circumstances where they make sense.

Finally.   I have noticed over the past forty + years of being a
programmer that the people who make up rules for programmers
tend to be people who no longer write programs, or, in some cases,
never have written any programs.  I would not want anyone to think
I am making up a rule about declare blocks.  I do maintain my
view that they need to be used sparingly, and sometimes
promoted to in-lined procedures -- but this is not a rule.

Richard Riehle

================================================

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:ets49o$m8j$1@jacob-sparre.dk...
> <adaworks@sbcglobal.net> wrote in message
> news:4eeMh.16400$bb1.2557@newssvr17.news.prodigy.net...
> ...
>>Units
>> in Ada, including declare blocks (which ought to be used minimally)
>> have the option of being named.
>
> While I generally agree with Richard, I certainly don't agree on the "ought
> to be used minimally" here.
>
> I use declare blocks extensively to reduce the scope of temporary variables
> in subprograms. They're especially important when the object exists just to
> take an unused out parameter, because they greatly reduce the need to come
> up with names for the objects. I often have code like:
>
>    declare
>            Junk : Index;
>    begin
>            Insert_Something (..., Result => Junk);
>    end;
>
> where the result isn't needed by the following code. (Sure, one could argue
> that the underlying library should be improved to avoid the need for this,
> but that isn't always possible and in any case changes to widely used
> specifications shouldn't be made lightly. And this is just one example, any
> sort of temporary has these sorts of requirements.)
>
> The advantage is that if in the future you find that you no longer need the
> temporary, you can remove it without heavy code analysis: it is used only in
> the one place and there is no worries that it might be reused, or have a
> side-effect, or the like.
>
>                        Randy.
>
>
>
> 

Re: Use of declare blocks

[Randy Brukardt]

<adaworks@sbcglobal.net> wrote in message
news:bByMh.11141$P47.10468@newssvr22.news.prodigy.net...
...
> When used by someone such as Randy, a programmer who
> uses every construct with care and intelligence, the declare
> block is not a primay design structure but a way of bringing
> subtle refinement to an already good design.

Richard, thanks for the vote of confidence. But I have to admit that the
above gave me a good laugh. My code tends to look just like the things you
describe you don't like (especially in the Janus/Ada compiler), especially
in regards to long subprograms. Part of that comes from the nature of
compiling: it's impossible to usefully shorten case statements with dozens
of branches. And I'm sure another part comes from Janus/Ada having started
as a university project, where things like naming and encapsulation weren't
used consistently (the latter because separate compilation was very weak in
our early tools). I just looked a couple of favorites: Gen_Name (which
generates the code for Ada "names") is 950 lines long, and it is mostly made
up of calls to other things. The root semantic routine is 2700 lines long
(it's a just a giant case statement with 378 whens at this writing: it
decides what to do with each grammar production as it is recognized).

Anyway, I do understand the readability concerns, but I think they're
overblown. If you have to look 5 pages away to find a variable declaration,
the readability of the code it is used in isn't necessarily enhanced: you're
still flipping back and forth. Moreover, trying to come up with good names
for code that are made into subprograms just to keep the code "short" is
hard, and I know I'm not good at it. These supposed helpers are a real
headache during maintenance, because its rarely obvious what they do! How do
that help readability??

                                   Randy.

Re: Use of declare blocks

[Randy Brukardt]

<adaworks@sbcglobal.net> wrote in message
news:%CIMh.1791$rj1.394@newssvr23.news.prodigy.net...
>
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:etveau$g29$1@jacob-sparre.dk...
> >
> > Anyway, I do understand the readability concerns, but I think they're
> > overblown. If you have to look 5 pages away to find a variable
declaration,
> > the readability of the code it is used in isn't necessarily enhanced:
you're
> > still flipping back and forth. Moreover, trying to come up with good
names
> > for code that are made into subprograms just to keep the code "short" is
> > hard, and I know I'm not good at it. These supposed helpers are a real
> > headache during maintenance, because its rarely obvious what they do!
How do
> > that help readability??
> >
> Actually, you make my point for me.  We certainly do not want to look
> all over the place for the name of a variable.   On reason I like to use
> in-lined procedures instead of declare blocks is the ease of grouping
> like things together.   Consider this contrived example:
>
>           case X is
>               when C1  =>  declare
>                                            xxxxxx
>                                      begin
>                                             -- fifty lines of code
>                                      end;
>               when C2 =>   declare
>                                              zzzzzzzz
>                                      begin
>                                             - twenty lines of code
>                                      end;
>               when ...
>           end case;
>
> Even when we label the declare blocks, which I tend to do,
> this can get to be difficult to read and difficult to maintain.  I
> might do this:
>
>            procedure some_unit_name is
>                  procedure C1_Process is ... end C1_Process;
>                  pragma Inline (C1_Process);
>                  procedure C2_Process is ... end C2_Process;
>                  pragma Inline (C2_Process);
>                  -- more procedures as needed
>           begin
>                  -- set up stuff
>
>                  case X is
>                       when C1  =>  C1_Process;
>                       when C2 =>   C2_Process;
>                       when ...
>                  end case;
>            end some_unit_name;

Ahhh, but this is unrealistic, for a couple of reasons.

First, you have to access the local variables and parameters of
Some_Unit_Name from the xx_Process routines. (I don't want to think about
routines that only use global variables!) Those necessarily will be far
away, and not even in the same scope (especially if you succeed in compiling
these separately - in which case they'll be in a different file. You can
pass them all as parameters, but then you're adding to the clutter that
you're supposedly reducing.

Second, you're not taking into account the likelyhood that some of the
processing is the same in several of these branches. That argues for making
that similar processing into a subprogram, too, and pretty soon you have
dozens of subprograms doing small parts of the processing.

And I'm not even going to point out that naming these "sub" routines is very
hard, because they tend to be only part of the processing (especially if
some action for all of the cases happens afterwards, which is common). You
can make it a bit easier sometimes by splitting the code into even more
subprograms, but all of the "noise" of a subprogram isn't going to
necessarily improve the readability.

...
> In your case, you and the small number of programmers who work
> with you are intimately familiar with the code.

That's no excuse for using a bad organization. I know how hard it is to go
back to code you haven't touched in a couple of years. It doesn't matter if
you wrote it originally: you won't remember much about it.

> One of the benefits of
> Ada is that it makes it easier to manage turnover, reassignments, and
> all the other personnel movements that occur in a large software
> organization.   I have seen declare blocks used in an ad hoc manner
> where the lack of documentation created difficulties for newcomers
> to a project.  Giving something a specific, meaningful name can help,
> especially when it is the name of a procedure along with good names
> for the local variables used to make it work.

True enough; but good names are very hard to come up with. (We never
succeeded at that for maybe 50% of the routines in Janus/Ada. Quick: tell me
the difference between "Base_Type" and "Formal_Base_Type" and
"Almost_Base_Type" and "Matching_Base_Type"! :-)

And it's almost a waste of effort to come up with names for throw-aways,
much less good names. I still often use the Fortran "I" for the loop
parameter of a for loop. The name is nearly irrelevant a lot of the time
(and the need for it is really a deficiency of the language -- I want to do
something to all of the components of an array; naming each one in turn is
not really necessary for that purpose). [I do try to use a better name if
the loop is going to longer than a few lines.]

Anyway, declare blocks are so close to subprograms that there isn't that
much difference between them. Surely naming is more important than that??

> I suppose we simply use the coding style most appropriate to the context
> in which we are working.   As I noted, I am not opposed to declare blocks,
> but I am uncomfortable when large systems are designed so they rely
heavily
> on them.   Most organizations don't have the luxury of a stable workforce.

I don't find small blocks to matter much at all - they just serve to narrow
the scope of objects as much as possible, which is important if you're not
going to use something anymore (let it get cleaned up).

I also use locks extensively in some code; those are always controlled
objects so they work properly when an exception propagates. The only way to
control the locking time is with a declare block, and it provides a nice
visual bracket for this use.

                                        Randy.

Re: Use of declare blocks

[adaworks]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:etveau$g29$1@jacob-sparre.dk...
>
> Anyway, I do understand the readability concerns, but I think they're
> overblown. If you have to look 5 pages away to find a variable declaration,
> the readability of the code it is used in isn't necessarily enhanced: you're
> still flipping back and forth. Moreover, trying to come up with good names
> for code that are made into subprograms just to keep the code "short" is
> hard, and I know I'm not good at it. These supposed helpers are a real
> headache during maintenance, because its rarely obvious what they do! How do
> that help readability??
>
Actually, you make my point for me.  We certainly do not want to look
all over the place for the name of a variable.   On reason I like to use
in-lined procedures instead of declare blocks is the ease of grouping
like things together.   Consider this contrived example:

          case X is
              when C1  =>  declare
                                           xxxxxx
                                     begin
                                            -- fifty lines of code
                                     end;
              when C2 =>   declare
                                             zzzzzzzz
                                     begin
                                            - twenty lines of code
                                     end;
              when ...
          end case;

Even when we label the declare blocks, which I tend to do,
this can get to be difficult to read and difficult to maintain.  I
might do this:

           procedure some_unit_name is
                 procedure C1_Process is ... end C1_Process;
                 pragma Inline (C1_Process);
                 procedure C2_Process is ... end C2_Process;
                 pragma Inline (C2_Process);
                 -- more procedures as needed
          begin
                 -- set up stuff

                 case X is
                      when C1  =>  C1_Process;
                      when C2 =>   C2_Process;
                      when ...
                 end case;
           end some_unit_name;

In the aerospace example, cited earlier, this is exactly how the code
was rewritten to make it easier to read as well as easier to keep
current.   Originally, when I did not know better, we considered
trying to make the nested procedures separate, but that did not
work under the rules of Ada.  I did hear that someone later worked
this up into a package body and was able to do something using
separate at the library level.   I am not sure about that since I did
not get to see the subsequent code.

In your case, you and the small number of programmers who work
with you are intimately familiar with the code.  One of the benefits of
Ada is that it makes it easier to manage turnover, reassignments, and
all the other personnel movements that occur in a large software
organization.   I have seen declare blocks used in an ad hoc manner
where the lack of documentation created difficulties for newcomers
to a project.  Giving something a specific, meaningful name can help,
especially when it is the name of a procedure along with good names
for the local variables used to make it work.

I suppose we simply use the coding style most appropriate to the context
in which we are working.   As I noted, I am not opposed to declare blocks,
but I am uncomfortable when large systems are designed so they rely heavily
on them.   Most organizations don't have the luxury of a stable workforce.

Richard Riehle 

Re: Use of declare blocks

[Georg Bauhaus]

On Fri, 2007-03-23 at 00:15 -0500, Randy Brukardt wrote:
> <adaworks@sbcglobal.net> wrote in message

> > In your case, you and the small number of programmers who work
> > with you are intimately familiar with the code.
> 
> That's no excuse for using a bad organization. I know how hard it is to go
> back to code you haven't touched in a couple of years. It doesn't matter if
> you wrote it originally: you won't remember much about it.

In this situation I have started pushing and forcing myself to write
one line of comment above each meaningful group of statements,
even when their meaning seemed obvious to me. In particular, when their
meaning seemed obvious. As you say, it won't stay obvious, and
the programmer's knowledge at the time of writing is lost with
the missing comment and has to be regained.
"What's next" style comments provide the problem and solution
context necessary for better understanding the LOC made for
solving the problem. This context information is much harder
to extract from the context that the program text might provide
by following formal implication chains.

I wish we could again have a language (not tool) whose definition
honestly adds the requirement that there be an utterance of
the programmer about the intent of his lines.
It might be a cultural change well worth it, in any sense
of the word. Algol 60 impressed me with its «comment» symbol,
and a rule where to place it: after a «begin» symbol.

commenting, was Re: Use of declare blocks

[tmoran]

> even when their meaning seemed obvious to me. In particular, when their
> meaning seemed obvious. As you say, it won't stay obvious, and
> the programmer's knowledge at the time of writing is lost with
> the missing comment and has to be regained.
    I'd like comments that are fuller as the code gets older.
    I've long wanted a system that each day would find those files that
are, say, two days old and it would ask me to either delete or give a
(very) short description (but longer than an 8.3 file name!).  Files that
haven't been accessed in two weeks would either be deleted or it would
require me to give a somewhat longer description.  Similarly after two
months, with a description that would make sense two years from now.
This would have to be system-enforced, since I can't bring myself to
do it manually (and sometimes it isn't clear how long certain files
will continue to exist anyway).
It would be nice to do something similar with source code and comments.

Re: commenting, was Re: Use of declare blocks

[adaworks]

I once wrote a program that enabled files of comments
to be inserted in the program wherever I wanted them.

I wrote it for a client, but I am not sure I still have the
source code.  However, it would be easy to write.

Wherever I wanted to be able to expand the source code
with additional documentation, I included a

       --{file-name}

Then, we could print the source file with all the comments embedded
or not, depending on the option in the print routine. Actually, this program
included several other printing options, as well.

Maybe I need to find it and make it available in the source code repository.

Richard Riehle
====================================================
<tmoran@acm.org> wrote in message 
news:pqednfl5KJ4GhpnbnZ2dnUVZ_v2knZ2d@comcast.com...
>> even when their meaning seemed obvious to me. In particular, when their
>> meaning seemed obvious. As you say, it won't stay obvious, and
>> the programmer's knowledge at the time of writing is lost with
>> the missing comment and has to be regained.
>    I'd like comments that are fuller as the code gets older.
>    I've long wanted a system that each day would find those files that
> are, say, two days old and it would ask me to either delete or give a
> (very) short description (but longer than an 8.3 file name!).  Files that
> haven't been accessed in two weeks would either be deleted or it would
> require me to give a somewhat longer description.  Similarly after two
> months, with a description that would make sense two years from now.
> This would have to be system-enforced, since I can't bring myself to
> do it manually (and sometimes it isn't clear how long certain files
> will continue to exist anyway).
> It would be nice to do something similar with source code and comments. 

Re: commenting, was Re: Use of declare blocks

[tmoran]

> Wherever I wanted to be able to expand the source code
> with additional documentation, I included a
>
>        --{file-name}
  My problem is that I don't go back to yesterday's code that wasn't
throw-away after all and comment it, or go back to last month's library
routine that was easily readable by anyone working in last month's
context, and expand on its comments.  I would have to be forced,
or at least "re-educated".

Re: commenting, was Re: Use of declare blocks

[Randy Brukardt]

<tmoran@acm.org> wrote in message
news:GYydnepKEqaRFJnbnZ2dnUVZ_uqvnZ2d@comcast.com...
> > Wherever I wanted to be able to expand the source code
> > with additional documentation, I included a
> >
> >        --{file-name}
>   My problem is that I don't go back to yesterday's code that wasn't
> throw-away after all and comment it, or go back to last month's library
> routine that was easily readable by anyone working in last month's
> context, and expand on its comments.  I would have to be forced,
> or at least "re-educated".

I find that going back and expanding comments is a fool's game, because by
the time the need is obvious, it is too late to do a good job (at least
without wasting a lot of time relearning the code in question).

Here's what works for me:

(1) Throw-away code doesn't need to be commented, but then it must be thrown
away. That means immediately. I find the latter hard, so I hardly ever write
throw-away code (most of it is still on my computer somewhere - or on one of
my older computers...).

(2) Code that isn't likely to be used frequently gets commented in critical
places, and every subprogram gets a basic description. I use good names and
the like, so it will be possible to figure it out again in the future. After
all, a lot of Ada code doesn't need comments if the entity names are decent.

(3) If I find myself working on/reusing older code, if I find the comments
inadequate, I immediately improve them so that they make more sense. (Once I
figure out what is going on, of course.) Once you've used something twice,
it's a pretty good bet that you'll use it a third time - so don't even think
about delaying about improving the comments and other documentation. After
all, having insufficient comments the first time is understandable; it isn't
possible to predict what will be hard to understand in the future. But once
you have an firm answer to that question, failing to act on it is silly and
unprofessional.

If you really wanted to be forced to do something, it should be to throw
away throw away code. Keeping it around is more likely to be harmful than
helpful (especially if it is totally uncommented).

                                    Randy.

Re: commenting, was Re: Use of declare blocks

[tmoran]

I think we mostly agree.  It's bad to have a machine cluttered with files,
or code, that you think might be useful, but in fact it's so poorly
described that it can't be found, or understood when it is found.  So the
system should force throwing away such things.  If you truly think you
might need it in the future, you should adequately describe it now, before
you've forgotten.

Sometimes you know the code or file you are creating is "for the ages" and
you spend the necessary time thoroughly documenting it.  But often you
don't know for sure, and think the likelihood of future use is low, so
spending a lot of care is a probable waste of time.  Minimal documentation
is then appropriate.  Rather than having two levels - minimal docs/full
docs - and going from level 1 to level 2 when you need the program the
second time, I suggest several levels, with transitions dependent on your
estimate of the likelihood you'll need it again, and the rate of decay of
your memory.

For example, in developing a binding to some API, I do a lot of throw-away
programs to test that I understand the API calls correctly.  I then
document the binding.  But then a few years later, on some newer project,
I recall "I once did a program that did much of what I need now, I wonder
where that old program might be."  I'd like to either know that program is
definitely long gone, don't waste time looking for it, or else have a file
description that lets me easily find it, and internal documentation that
makes it easy to refresh my memory, to help with today's project.

Re: commenting, was Re: Use of declare blocks

[Simon Wright]

tmoran@acm.org writes:

> But then a few years later, on some newer project, I recall "I once
> did a program that did much of what I need now, I wonder where that
> old program might be."  I'd like to either know that program is
> definitely long gone, don't waste time looking for it, or else have
> a file description that lets me easily find it, and internal
> documentation that makes it easy to refresh my memory, to help with
> today's project.

Descriptive comments (including key words) in the file can be found by
tools like Spotlight. That would get you to the right area on the disk.

In my case the problem is often that the disk was in a machine that's
gone to recycling ...

Re: why learn C?

[kevin cline]

On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>
> It has always seemed rather odd to me that people who are as intelligent
> as programmers, rarely question the silliness of using tools such as C
> and C++ for serious work.
> They simply take for granted that the kind
> of errors that are so common in those languages are somehow akin to
> the laws of nature.

No, what actually happened is that expert C++ developers learned to
use C++ in such a way that those errors can not happen.  While it is
possible to write unsafe code in C++, it is also possible to adopt
coding guidelines that makes it easy to find and eliminate unsafe
code, and for most applications, that's quite good enough.  One reason
that experts choose C++ over Ada for performance-critical applications
because C++ templates allow compile-time type safety in high-level
code in a way that Ada generics do not.

Re: why learn C?

[Steve]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1175215906.645110.217810@e65g2000hsc.googlegroups.com...
> On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
>> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>>
>> It has always seemed rather odd to me that people who are as intelligent
>> as programmers, rarely question the silliness of using tools such as C
>> and C++ for serious work.
>> They simply take for granted that the kind
>> of errors that are so common in those languages are somehow akin to
>> the laws of nature.
>
> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.  One reason
> that experts choose C++ over Ada for performance-critical applications
> because C++ templates allow compile-time type safety in high-level
> code in a way that Ada generics do not.
>

Please give an example of one case where a C++ template gives more compile 
time safety than an Ada generic.  I have found just the opposite to be true.

Regards,
Steve
(The Duck)

Re: why learn C?

[jimmaureenrogers]

On Mar 29, 6:51 pm, "kevin  cline" <kevin.cl...@gmail.com> wrote:

> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.

Coding guidelines cannot by themselves prevent any errors. For
example,
the JSF AV C++ Coding Standard, which is intended to limit the unsafe
features of C++, contains 221 rules. It is not possible to check
6 million lines of code against 221 rules by hand in any timely or
economical manner.

The NASA Ada Flight Software coding guidelines contain 14 rules.
The intent of both coding standards is to produce software safe enough
to use for airborne avionics systems.

Coding standards can help up to a point. When the coding standards are
oppresively complex they cease to help.

Jim Rogers

Re: why learn C?

[kevin cline]

On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote:
> "kevin cline" <kevin.cl...@gmail.com> wrote in message
>
> news:1175215906.645110.217810@e65g2000hsc.googlegroups.com...
>
>
>
> > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
> >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>
> >> It has always seemed rather odd to me that people who are as intelligent
> >> as programmers, rarely question the silliness of using tools such as C
> >> and C++ for serious work.
> >> They simply take for granted that the kind
> >> of errors that are so common in those languages are somehow akin to
> >> the laws of nature.
>
> > No, what actually happened is that expert C++ developers learned to
> > use C++ in such a way that those errors can not happen.  While it is
> > possible to write unsafe code in C++, it is also possible to adopt
> > coding guidelines that makes it easy to find and eliminate unsafe
> > code, and for most applications, that's quite good enough.  One reason
> > that experts choose C++ over Ada for performance-critical applications
> > because C++ templates allow compile-time type safety in high-level
> > code in a way that Ada generics do not.
>
> Please give an example of one case where a C++ template gives more compile
> time safety than an Ada generic.  I have found just the opposite to be true.

Christopher Grein covered the topic thoroughly here: (http://home.t-
online.de/home/Christ-Usch.Grein/Ada/Dimension.html)

On attempts to achieve compile-time checking of physical units
computations in Ada, he wrote:

"Our attempt leads us to a plethora of overloaded functions. The
number of function definitions afforded runs into the hundreds... So
we have to confess that our attempt to let the compiler check
equations at compile time has miserably failed."

"The big difference is that C++ templates allow type checking during
compile-time, so that no overhead neither in memory space nor in
runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
than Ada generics."

Ada gives you low-level type safety out of the box, but does not
afford the tools necessary to achieve type-safety in high-level
programming.  Low-level C++ coding is not type safe, but C++ provides
powerful mechanisms to write high-level type-safe code.

Re: why learn C?

[Case Crab]

On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net"
<jimmaureenrog...@worldnet.att.net> wrote:
> On Mar 29, 6:51 pm, "kevin  cline" <kevin.cl...@gmail.com> wrote:
>
> > No, what actually happened is that expert C++ developers learned to
> > use C++ in such a way that those errors can not happen.  While it is
> > possible to write unsafe code in C++, it is also possible to adopt
> > coding guidelines that makes it easy to find and eliminate unsafe
> > code, and for most applications, that's quite good enough.
>
> Coding guidelines cannot by themselves prevent any errors.

Really?  I have found that coding practices can preclude certain
classes of errors.

> For example,
> the JSF AV C++ Coding Standard, which is intended to limit the unsafe
> features of C++, contains 221 rules.

How many rules distinguish SPARK from the full Ada language?

> It is not possible to check
> 6 million lines of code against 221 rules by hand in any timely or
> economical manner.

I expect that most of the checking can and will be done
automatically.  In any case, I would expect such
mission-critical code would be inspected, regardless of whether the
implementation language is C++ or Ada.

>
> The NASA Ada Flight Software coding guidelines contain 14 rules.
> The intent of both coding standards is to produce software safe enough
> to use for airborne avionics systems.

Interesting that one organization has 221 rules while the other has
only 14.

> Coding standards can help up to a point. When the coding standards are
> oppresively complex they cease to help.

Compile-time checks can also help, up to a point.  But they don't
solve the whole problem.

Re: why learn C?

[Gautier]

Case Crab:

>> For example,
>> the JSF AV C++ Coding Standard, which is intended to limit the unsafe
>> features of C++, contains 221 rules.
...
>> The NASA Ada Flight Software coding guidelines contain 14 rules.
>> The intent of both coding standards is to produce software safe enough
>> to use for airborne avionics systems.
> 
> Interesting that one organization has 221 rules while the other has
> only 14.

Probably the difference is more that the 221 rules are needed for "securizing" 
C++ and the 14 ones for Ada ?
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: why learn C?

[Lutz Donnerhacke]

* kevin  cline wrote:
> "The big difference is that C++ templates allow type checking during
> compile-time, so that no overhead neither in memory space nor in
> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
> than Ada generics."

This is correct. C++-Templates itself are a Lisp dialect and Turing complete.

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
>> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>>
>> It has always seemed rather odd to me that people who are as intelligent
>> as programmers, rarely question the silliness of using tools such as C
>> and C++ for serious work.
>> They simply take for granted that the kind
>> of errors that are so common in those languages are somehow akin to
>> the laws of nature.
>
> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.  One reason
> that experts choose C++ over Ada for performance-critical applications
> because C++ templates allow compile-time type safety in high-level
> code in a way that Ada generics do not.

Wow. This is like looking into your gasoline tank with a cigarette
lighter for illumination. 

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote:
>> "kevin cline" <kevin.cl...@gmail.com> wrote in message
>>
>> news:1175215906.645110.217810@e65g2000hsc.googlegroups.com...
>>
>>
>>
>> > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
>> >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>>
>> >> It has always seemed rather odd to me that people who are as intelligent
>> >> as programmers, rarely question the silliness of using tools such as C
>> >> and C++ for serious work.
>> >> They simply take for granted that the kind
>> >> of errors that are so common in those languages are somehow akin to
>> >> the laws of nature.
>>
>> > No, what actually happened is that expert C++ developers learned to
>> > use C++ in such a way that those errors can not happen.  While it is
>> > possible to write unsafe code in C++, it is also possible to adopt
>> > coding guidelines that makes it easy to find and eliminate unsafe
>> > code, and for most applications, that's quite good enough.  One reason
>> > that experts choose C++ over Ada for performance-critical applications
>> > because C++ templates allow compile-time type safety in high-level
>> > code in a way that Ada generics do not.
>>
>> Please give an example of one case where a C++ template gives more compile
>> time safety than an Ada generic.  I have found just the opposite to be true.
>
> Christopher Grein covered the topic thoroughly here: (http://home.t-
> online.de/home/Christ-Usch.Grein/Ada/Dimension.html)
>
> On attempts to achieve compile-time checking of physical units
> computations in Ada, he wrote:
>
> "Our attempt leads us to a plethora of overloaded functions. The
> number of function definitions afforded runs into the hundreds... So
> we have to confess that our attempt to let the compiler check
> equations at compile time has miserably failed."
>
> "The big difference is that C++ templates allow type checking during
> compile-time, so that no overhead neither in memory space nor in
> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
> than Ada generics."
>
> Ada gives you low-level type safety out of the box, but does not
> afford the tools necessary to achieve type-safety in high-level
> programming.  

I'm inclined to shout nonsense here: You people tend to mistake a type
system for a proof system on the correctness of your program. That are
two different things. Type safety is to avoid execution errors (once
again see Cardelli's introduction into type systems), whereas a type
system is hardly ever powerful enough to proof interesting things
about the correctness of your code -- so if you start proofing
correctness you can well start with a simple, but safe type system and
handle pre- and post-conditions completely in your proof system (that
also applies to subrange types and this kind of stuff).

(And yes that critique also applies to Ada subtyping to a certain
extend.)

> Low-level C++ coding is not type safe, but C++ provides
> powerful mechanisms to write high-level type-safe code.

That's a bit like saying, "I can write type safe code in C". The point
is, I might be able to write safe code in C, but type safe is an
attribute applying to a language (NOT a single instance of code) and
means that if the type checks are passed, the code is safe with regard
to execution errors (execution errors as defined in Cardelli's paper
again: That are error that bring the program into "undefined states"
or "invoke undefined behaviour" (hello, comp.std.c, can you hear me
:-)))).

The definition allow show that "this piece of code is type safe" makes
no sense, and that saying "I can write type safe code by keeping to
certain rules" makes hardly sense also, since it's the very essence of
type safety that it's the type checks that are the litmus test wether
you stuck to the rules or not.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> "kevin  cline" <kevin.cline@gmail.com> writes:
>
>> On Mar 29, 10:09 pm, "Steve" <nospam_steve...@comcast.net> wrote:
>>> "kevin cline" <kevin.cl...@gmail.com> wrote in message
>>>
>>> news:1175215906.645110.217810@e65g2000hsc.googlegroups.com...
>>>
>>>
>>>
>>> > On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
>>> >> "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
>>>
>>> >> It has always seemed rather odd to me that people who are as intelligent
>>> >> as programmers, rarely question the silliness of using tools such as C
>>> >> and C++ for serious work.
>>> >> They simply take for granted that the kind
>>> >> of errors that are so common in those languages are somehow akin to
>>> >> the laws of nature.
>>>
>>> > No, what actually happened is that expert C++ developers learned to
>>> > use C++ in such a way that those errors can not happen.  While it is
>>> > possible to write unsafe code in C++, it is also possible to adopt
>>> > coding guidelines that makes it easy to find and eliminate unsafe
>>> > code, and for most applications, that's quite good enough.  One reason
>>> > that experts choose C++ over Ada for performance-critical applications
>>> > because C++ templates allow compile-time type safety in high-level
>>> > code in a way that Ada generics do not.
>>>
>>> Please give an example of one case where a C++ template gives more compile
>>> time safety than an Ada generic.  I have found just the opposite to be true.
>>
>> Christopher Grein covered the topic thoroughly here: (http://home.t-
>> online.de/home/Christ-Usch.Grein/Ada/Dimension.html)
>>
>> On attempts to achieve compile-time checking of physical units
>> computations in Ada, he wrote:
>>
>> "Our attempt leads us to a plethora of overloaded functions. The
>> number of function definitions afforded runs into the hundreds... So
>> we have to confess that our attempt to let the compiler check
>> equations at compile time has miserably failed."
>>
>> "The big difference is that C++ templates allow type checking during
>> compile-time, so that no overhead neither in memory space nor in
>> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
>> than Ada generics."
>>
>> Ada gives you low-level type safety out of the box, but does not
>> afford the tools necessary to achieve type-safety in high-level
>> programming.  
>
> I'm inclined to shout nonsense here: You people tend to mistake a type
> system for a proof system on the correctness of your program. That are
> two different things. Type safety is to avoid execution errors (once
> again see Cardelli's introduction into type systems), whereas a type
> system is hardly ever powerful enough to proof interesting things
> about the correctness of your code -- so if you start proofing
> correctness you can well start with a simple, but safe type system and
> handle pre- and post-conditions completely in your proof system (that
> also applies to subrange types and this kind of stuff).
>
> (And yes that critique also applies to Ada subtyping to a certain
> extend.)
>
>> Low-level C++ coding is not type safe, but C++ provides
>> powerful mechanisms to write high-level type-safe code.
>
> That's a bit like saying, "I can write type safe code in C". The point
> is, I might be able to write safe code in C, but type safe is an
> attribute applying to a language (NOT a single instance of code) and
> means that if the type checks are passed, the code is safe with regard
> to execution errors (execution errors as defined in Cardelli's paper
> again: That are error that bring the program into "undefined states"
> or "invoke undefined behaviour" (hello, comp.std.c, can you hear me
> :-)))).
>
> The definition allow show that "this piece of code is type safe" makes

Should've been: "The definition also shows ..."

> no sense, and that saying "I can write type safe code by keeping to
> certain rules" makes hardly sense also, since it's the very essence of
> type safety that it's the type checks that are the litmus test wether
> you stuck to the rules or not.
>
> Regards -- Markus

Re: why learn C?

[Dmitry A. Kazakov]

On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:

> * kevin  cline wrote:
>> "The big difference is that C++ templates allow type checking during
>> compile-time, so that no overhead neither in memory space nor in
>> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
>> than Ada generics."
> 
> This is correct. C++-Templates itself are a Lisp dialect and Turing complete.

One should be careful with such statements. In fact it is apples and
oranges, because whatever power templates might have, they are *not*
executed on the target machine.

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

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-03-29 at 17:51 -0700, kevin cline wrote:
> On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
> > "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
> >
> > It has always seemed rather odd to me that people who are as intelligent
> > as programmers, rarely question the silliness of using tools such as C
> > and C++ for serious work.
> > They simply take for granted that the kind
> > of errors that are so common in those languages are somehow akin to
> > the laws of nature.
> 
> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.  One reason
> that experts choose C++ over Ada for performance-critical applications
> because C++ templates allow compile-time type safety in high-level
> code in a way that Ada generics do not.


Nevertheless, adherence to tradition and culture group preferences
(for lack of a better word) seems to prevent several highly desirable
additions or changes to C++ (and D. And Ada.). Or their integration
with the very templates that turn out to achieve useful effects:
A well defined and expressive base type system; case coverage in
conditionals; simplified overload rules (why overloading in
the first place when we have powerful templates and virtual
functions?); normal treatment of the return parameter in type
checking; ...

For example, why is int not a template? Sure it is possible to
come up with a number of templates and have the compiler answer
the question whether an all C++ program is base type safe.
So why not make int less C-ish?
And throw out types whose existence can no longer be justified,
at higher or lower level, such as short, long, and long long:

   class Coordinate : int<0, 4096, unsigned>, Ring {
     // ...
   };

I'm not saying that these things can't be programmed in C++.
I'm saying that they must be programmed if you want them in C++.
That's the point.

(Likewise, Ada should have the elementary school types only on
request, i.e. no predefined "Integer" with all the operations
some of which are hardly ever used in an average program.
(Only average programs should affect what's in a language,
no?)

Do we profit considerably from the presence of and, in cases, need
for all of typedef *and* class *and* struct *and* typename? And
a guaranteed load of rules per project?
The language's historic complexities can still provide for
entertaining distractions from solving the problem. C++ is not
alone here, but strangely, some programmers seem to insist on
old baggage even in new programs.

Template programming is tricky and likely will be because
templates weren't designed for using them in the useful ways
which we learn now many years after their addition to the
language. They are a quite interesting experimental feature of
compiling technology. (If they were not, I'm sure investors would
have asked for a different design. One that has less potential of
affecting programmer performance in *both* directions.
The work needed to understand or improve template error messages
is considerable: programmers need expensive time to fix template
mistakes. Witness the opportunity for tool shops to
sell expert systems for the interpretations of template error
messages, and all the work that goes into improving them somewhere
in the tool chain.)

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-03-29 at 23:30 -0700, Case Crab wrote:
> On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net"

> > Coding guidelines cannot by themselves prevent any errors.
> 
> Really?  I have found that coding practices can preclude certain
> classes of errors.

Can coding practices be improved by making them language
definitions?


> How many rules distinguish SPARK from the full Ada language?

If you allow me to be pedantic, SPARK is not distinguished from
Ada by external rules for programmers. Rather, it has its own
language definition, and translators that know about nothing
but the SPARK language. This approach is very different from
establishing coding rules.

For example, a coding rule might say, don't use recursion.
SPARK turns this coding rule into a language definition.
Unfortunately.

Re: why learn C?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1175230700.925143.28490@n59g2000hsh.googlegroups.com...
>
> Ada gives you low-level type safety out of the box, but does not
> afford the tools necessary to achieve type-safety in high-level
> programming.  Low-level C++ coding is not type safe, but C++ provides
> powerful mechanisms to write high-level type-safe code.
>
On reading the Grein paper, it is clear that the advantage is a very
small, and very narrowly focused one.   Any suggestion that C++
is, as a general principle, safer than Ada is simply a fantasy.

Overall, compile-time safety in Ada is substantially superior to that
in C++.    C and C++ are highly error-prone.  Programmers who
choose C++ take for granted that long hours of debugging obscure
errors is the way life ought to be.

As for high-level programming, this is where Ada does excel.   For
large-scale, multi-developer projects C++ simply is a mess.   There
is no dependable model for separate programming.  Oh yes, those
CPP files!  Well, they are inherently part of their own specification
and they need to be augmented by compiler directives just to make
sure there are not errors.

I nearly guffawed when reading your last sentence.  C++ as type
safe?  What a joke.   Sadly, I suspect you actually believe this.

With all mechanisms available in Ada for developing solid, dependable
code and a language definition that focuses on creating compilers that
maximize the amount of error detection that can be done early in
the development process, I wonder whether you really understand
Ada at all.   Have you any understanding of the visbility rules?  This
goes well beyond type-safety.    Do you understand the library model
and how it affects separate compilation?

As for the safety of generics, Grein's paper, which you take delight
in citing, does not discount the fact that most generic constructs
are type-safe at compile time.    Further, getting it right, with C++
templates is no trivial feat either.    There are plenty of opportunities
to create errors in C++ templates.

I have programmed in both languages.  I have taught C++ and I have
taught Ada.   I have colleagues who use both languages who realize
that C++ is far more error-prone than Ada.    While one can get a
good set of working software in C++ using heroic efforts, the chance
of errors in a C++ program is much higher in a corresponding program
written in Ada.   I find it strange that anyone who understands both
languages well would come to any other conclusion.

Richard Riehle 

Re: why learn C?

[adaworks]

"Case Crab" <casecrab@gmail.com> wrote in message 
news:1175236212.771445.135460@y66g2000hsf.googlegroups.com...
>
> Compile-time checks can also help, up to a point.  But they don't
> solve the whole problem.
>
True.  Software is never easy.   We always need a set of
tools to ensure that what we intended is what we got.

Further, Ada is not restricted to the checking of data types
at compile-time.  It includes a powerful set of options that
allow a variety of kinds of checks, when the developer
uses them.    This is better than the alternative languages
such as C++ that simply fail to provide the range of
options found in Ada.

One of my favorite columns in the now defunct C++
Report magazine was titled "Obfuscated C++."  I
still have some of those articles clipped out an in a
three-ring binder.    In every case, the obfuscation
illustrated was something that simply could not happen
in Ada.   I cannot imagine anyone writing a column
called "Obfuscated Ada."

Richard Riehle 

Re: why learn C?

[Pascal Obry]

kevin cline a �crit :

> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.  One reason

Sorry but you must live in another planet :) All the C++ code I've seen
are so full of bugs that I'm not inclined to buy that! Ok it *may* be
possible but how many C++ programmers are *good* enough and *wise*
enough to achieve that ? That's the real question to me, and from where
I stand this is close to 0% !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: why learn C?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:


> One of my favorite columns in the now defunct C++
> Report magazine was titled "Obfuscated C++."  I
> still have some of those articles clipped out an in a
> three-ring binder.    In every case, the obfuscation
> illustrated was something that simply could not happen
> in Ada.   I cannot imagine anyone writing a column
> called "Obfuscated Ada."

Wasn't there a obfuscated Ada thread some time ago her at c.l.a? Some 6 or 10 months ago?

> Richard Riehle 

BTW, wasn't it you who still wants to explain to me how Java is not
type safe, or am I mixing something up?

Regards -- Markus

Re: why learn C?

[Randy Brukardt]

<adaworks@sbcglobal.net> wrote in message
news:o2cPh.4026$u03.1786@newssvr21.news.prodigy.net...
>  I cannot imagine anyone writing a column
> called "Obfuscated Ada."

Not a column, perhaps, but surely you could write an interesting article.
Ada has plenty of ways to write something simple in wonderfully long-winded
ways which potentially harm readability. And there are various non-obvious
idioms that are very handy, like using Boolean'Pos to get the effect of a
conditional expression:

Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not
<condition>)*Function2;

I always comment such things extensively, but it would be interesting to
figure out the meaning without it.

                            Randy.

Re: why learn C?

[jimmaureenrogers]

On Mar 30, 12:30 am, "Case Crab" <casec...@gmail.com> wrote:
> On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net"
>
> <jimmaureenrog...@worldnet.att.net> wrote:
> > On Mar 29, 6:51 pm, "kevin  cline" <kevin.cl...@gmail.com> wrote:
>
> > > No, what actually happened is that expert C++ developers learned to
> > > use C++ in such a way that those errors can not happen.  While it is
> > > possible to write unsafe code in C++, it is also possible to adopt
> > > coding guidelines that makes it easy to find and eliminate unsafe
> > > code, and for most applications, that's quite good enough.
>
> > Coding guidelines cannot by themselves prevent any errors.
>
> Really?  I have found that coding practices can preclude certain
> classes of errors.

The JSF C++ coding standards are available from several sources on the
web. One link is http://www.research.att.com/~bs/JSF-AV-rules.pdf

The corresponding Ada coding standard is found at
http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf

>
> > For example,
> > the JSF AV C++ Coding Standard, which is intended to limit the unsafe
> > features of C++, contains 221 rules.
>
> How many rules distinguish SPARK from the full Ada language?
>
> > It is not possible to check
> > 6 million lines of code against 221 rules by hand in any timely or
> > economical manner.
>
> I expect that most of the checking can and will be done
> automatically.  In any case, I would expect such
> mission-critical code would be inspected, regardless of whether the
> implementation language is C++ or Ada.
>

Inspection is the problem. It is inefficient and error prone to
manually inspect 6 million lines of code against 221 rules.

There is an automated tool for checking the JSF standard. That
tool cannot perform a 100% check either due to the nature of the
rules.

>
>
> > The NASA Ada Flight Software coding guidelines contain 14 rules.
> > The intent of both coding standards is to produce software safe enough
> > to use for airborne avionics systems.
>
> Interesting that one organization has 221 rules while the other has
> only 14.

If you analyze the two standards, and understand the two languages,
you
will see that the 221 rules for C++ bring you close to the same safety
level you achieve with the 14 rules for Ada.

Many of the language features prohibited in the C++ standard simply do
not exist in Ada. This explains the bulk of the differences in the two
standards. For instance:

AV Rule 20 (MISRA Rule 122)
The setjmp macro and the longjmp function shall not be used.

Ada has no macros and no equivalent to the longjmp function.
There is no reason to prohibit their use in Ada.

Similarly:

AV Rule 29
  The #define pre-processor directive shall not be used to create
inline macros. Inline functions shall be used instead.
  Rationale: Inline functions do not require text substitutions
and behave well when called with arguments
(e.g. type checking is performed).

Ada does allow inline functions and procedures, but has no
language defined macro capability.

AV Rule 71.1
  A class's virtual functions shall not be invoked from its
destructor or any of its constructors.
  Rationale: A class's virtual functions are resolved
statically (not dynamically) in its constructors and
destructor.

Ada does not provide a direct equivalent to C++ constructors
and destructors. While this may seem a problem to a C++ or
Java programmer, it does have the virtue of not providing
an avenue for the error handled by this rule.

And the C++ multiple inheritance model provides interesting
opportunities for unsafe code:

AV Rule 89
  A base class shall not be both virtual and non-virtual in
the same hierarchy.
  Rationale: Hierarchy becomes difficult to comprehend and use.

Do not forget about all the wonders of pointers in C and C++.
For example:

AV Rule 97
  Arrays shall not be used in interfaces. Instead, the Array
class should be used.
  Rationale: Arrays degenerate to pointers when passed as
parameters. This "array decay" problem has long been known to be
a source of errors.

Ada arrays do not decay to pointers. This problem is unknown in
Ada with or without coding standards.

>
> > Coding standards can help up to a point. When the coding standards are
> > oppresively complex they cease to help.
>
> Compile-time checks can also help, up to a point.  But they don't
> solve the whole problem.

No, run time checks are needed for things that cannot be checked at
compile time. Ada helps is more helpful with run time checks than is
C or C++ due to the automated check writing built by the compilers.
For instance, if you define an integer type with a valid range of
values from -10 to 10, the compiler will perform all necessary
range checking for that type.

type My_Int is range -10..10;

You can provide run time checking in any language. In C++ you would
need to define a class for My_Int. The assignment operator would need
to be re-defined to check for the range, and throw an exception when
the range limits are violated.

C++ provides additional challenges to the definition and checking of
limited range integer types. In C and C++ (and Java) all numeric types
are initialized by default to 0. What does that do to your program if
0 is not within the valid range for your type? The compiler will
simply initialize the data member of your class to an invalid value.
You will need to provide a default constructor to initialize the value
to some valid value, along with the overridden assignment operator.

Jim Rogers

Re: why learn C?

[Dmitry A. Kazakov]

On Fri, 30 Mar 2007 15:29:18 -0500, Randy Brukardt wrote:

> And there are various non-obvious
> idioms that are very handy, like using Boolean'Pos to get the effect of a
> conditional expression:
> 
> Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not
> <condition>)*Function2;

That's great and it is used extensively, not in Ada of course, but in some
scripting languages used in process control. Especially interesting it
becomes when the condition and its inversion expressions are a subject of
race condition. In the language I am talking about it is practically always
the case...

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

Re: why learn C?

[Larry Kilgallen]

In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes:

> I cannot imagine anyone writing a column
> called "Obfuscated Ada."

Number_of_Genders_Encountered : Integer;
Traffic_Light_Color : Boolean;
Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module;

not NASA Ada coding standard

[Stephen Leake]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:

> The corresponding Ada coding standard is found at
> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf

Putting on my NASA hat, I must point out that those standards are
_not_ NASA-wide standards, but Goddard flight software standards.
Goddard is only one of many NASA centers, and the flight software
group at Goddard is a small part of the Goddard software community.

And in fact, my group, consisting of 5 programmers, is the only group
following those standards. Things on the web are not always what they
seem :).

There is a slightly more up-to-date version on my project website:
http://fsw.gsfc.nasa.gov/gds/gds_internal.html 

Enforcement of the standard is accomplished partly by using GNAT and
Emacs, but mostly by me reading _all_ of the code, as it is checked
into CVS.

-- 
-- Stephe

Re: why learn C?

[Peter C. Chapin]

Georg Bauhaus <bauhaus@futureapps.de> wrote in 
news:1175246243.5771.67.camel@localhost.localdomain:

> If you allow me to be pedantic, SPARK is not distinguished from
> Ada by external rules for programmers. Rather, it has its own
> language definition, and translators that know about nothing
> but the SPARK language. This approach is very different from
> establishing coding rules.

How is it different than using coding guidelines together with a tool 
that checks them automatically? I've used lint-like tools with C++ and 
I've found the combination effective. I express my coding guidelines in 
terms of which checks I enable in the tool. This is a tedious process 
but once done the configuration can be reused with multiple projects so 
it's not too terrible. Then I write programs so that the tool produces 
no messages.

The tool essentially defines a language that is a subset of the full 
language. By insisting that the tool produces no messages I'm getting 
mechanical verification that I'm using just that subset. In some 
respects it's not that different from using a stricter language in the 
first place except that I get to define the precise subset I want to 
use. Using a lax language like C++ together with a configurable tool 
thus gives me a degree of flexibility over the case where the 
programming language itself specifies all sorts of required checks that 
I can't configure.

On the other hand there is a portability issue introduced by using a 
third party tool. I can see that as being a major problem for programs 
written by multiple teams. Since Ada targets exactly those kinds of 
programs, Ada's approach of incorporating as much checking as possible 
into the standard language makes sense. I either work alone or in small 
groups, however, so using a third party tool is less of an issue for me.

The approach I outline here is not without its problems, but it does 
help one write reliable programs with a lax language. I don't consider 
myself a genius programmer (although I do have a lot of experience with 
C++) but I spend very little time in the debugger.

All around I appreciate Ada's approach and I enjoy working with Ada. 
Indeed, knowing Ada has made me a better C++ programmer. I especially 
like Ada's clean syntax and standards such as ASIS that make writing 
advanced tools for Ada easier. As you can probably guess, I'm a big 
believer in extending a programming language with tools. It's too bad 
that building tools for C++ is such a big pain in the neck. C++'s nasty 
syntax, together with the preprocessor, are probably the worst things 
about the language because they inhibit tool building.

Peter

Re: why learn C?

[Steve]

<adaworks@sbcglobal.net> wrote in message 
news:6XbPh.4025$u03.802@newssvr21.news.prodigy.net...
>
[snip]
>
>....   I have colleagues who use both languages who realize
> that C++ is far more error-prone than Ada.    While one can get a
> good set of working software in C++ using heroic efforts, the chance
> of errors in a C++ program is much higher in a corresponding program
> written in Ada.   I find it strange that anyone who understands both
> languages well would come to any other conclusion.
>
> Richard Riehle
>

Me too.

Steve
(The Duck) 

Re: why learn C?

[Pascal Obry]

adaworks@sbcglobal.net a �crit :

> I have programmed in both languages.  I have taught C++ and I have
> taught Ada.   I have colleagues who use both languages who realize
> that C++ is far more error-prone than Ada.    While one can get a
> good set of working software in C++ using heroic efforts, the chance
> of errors in a C++ program is much higher in a corresponding program
> written in Ada.   I find it strange that anyone who understands both
> languages well would come to any other conclusion.

Same experience on my side, same questioning!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: not NASA Ada coding standard

[Markus E Leypold]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:
>
>> The corresponding Ada coding standard is found at
>> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf
>
> Putting on my NASA hat, I must point out that those standards are
> _not_ NASA-wide standards, but Goddard flight software standards.
> Goddard is only one of many NASA centers, and the flight software
> group at Goddard is a small part of the Goddard software community.
>
> And in fact, my group, consisting of 5 programmers, is the only group
> following those standards. Things on the web are not always what they
> seem :).
>
> There is a slightly more up-to-date version on my project website:
> http://fsw.gsfc.nasa.gov/gds/gds_internal.html 
>
> Enforcement of the standard is accomplished partly by using GNAT and
> Emacs, but mostly by me reading _all_ of the code, as it is checked
> into CVS.

And it is well known, that review is the most effective QA measure
anyway: So it _is_ useful to read (or better let read) the code before
chacking in to the main code base. Which also gives another 2-cent
contribution to this thread: Reviewing against a small number of rules
is of course less error prone (and does cost less) than reviewing
against a huge number of rules. And furthermore reviews are easier if
the language is readable (a plus for Ada and its generics, a minus for
C++ and templates in my eyes).

I think this is one up for Ada here.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

"Steve" <nospam_steved94@comcast.net> writes:

> <adaworks@sbcglobal.net> wrote in message 
> news:6XbPh.4025$u03.802@newssvr21.news.prodigy.net...
>>
> [snip]
>>
>>....   I have colleagues who use both languages who realize
>> that C++ is far more error-prone than Ada.    While one can get a
>> good set of working software in C++ using heroic efforts, the chance
>> of errors in a C++ program is much higher in a corresponding program
>> written in Ada.   I find it strange that anyone who understands both
>> languages well would come to any other conclusion.
>>
>> Richard Riehle
>>
>
> Me too.

I think I've tried to explain before that it is very rare, that real
projects can choose a language absolutely freely, based only on the
merits / properties of the languages in question. In reality, most
people work with a given language on a historically grown code
base. If new projects are started, they are usually started in a
corporate environment which also has existing infrastructure,
experience, a source code base, coding guide lines etc. All this is
often a motivation not to change the language or at least "not just
now".

The way Richard presents things distorts reality somewhat: He gives
the impression that there is a number of peple out there, which know
C++ and Ada equally well, start projects with an absolutely clean
slate (no development environment, no code base on which to build, no
corporate guide lines) and then -- with seeing eyes -- decide for C++
and against Ada, but still expect completely error free software.

This is not so.

(And given the state of vendor support on various platforms from
embedded to PC operating systems in both C++ and Ada, I could still
understand if some people came to the conclusion that, to retain the
flexibility, both in moving from platform to platform as well as in
hiring developers, that they would be prepared to accept "proneness"
to lesser quality -- if I had to make that decision I'd try to avoid
this outcome, but I certainly would understand the point of somebody
who would decide differently).

In summary: Technical merits of languages play only a tiny part in
decisions for or against a given language. But I already have said
that often enough, haven't I?

Regards -- Markus

Re: why learn C?

[adaworks]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
news:c82IfUV$xbi8@eisner.encompasserve.org...
> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, 
> <adaworks@sbcglobal.net> writes:
>
>> I cannot imagine anyone writing a column
>> called "Obfuscated Ada."
>
> Number_of_Genders_Encountered : Integer;
> Traffic_Light_Color : Boolean;
> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module;

OK.  With a little effort, one can write obfuscated code in any language. 
However,
with C++ it is far more likely than with Ada.   Further, as your examples 
illustrate,
one needs to really make an effort to do so with Ada.   I recall a project I 
worked
on many hundreds of years ago (it seems that long) where we were using COBOL.
One of the programmers used the names of comic book characters as data and
procedure names throughout his program.   We had constructs such as,

           MOVE BATMAN TO BATMOBILE.

The code worked fine, but it was somewhat obfuscated.

Your last example is particularly interesting.   In the absence of a global
visibility clause (use), one would expect dot notation to disambiguate the
other module.

For your first example, coding standards would certainly apply.   We learned
a long time ago not to use type numeric types in package Standard.   In Ada,
we can define our own data types.  This is not an option in C++ unless one
jumps through hoops.

Finally, using Boolean for Traffic_Light_Color is simply absurd, not 
obfuscation.
There are three colors for a traffic light, and Boolean only covers two.  This 
is
not bad coding, nor is obfuscated code.  Instead, it is bad design.

The "Obfuscated C++" column, which I enjoyed while it lasted, was not
always code that was tormented into a puzzle.  Instead, it was code that
one might actually find someone using on a project.   Sometimes, I could
figure it out through simple reasoning.  Other times, I had to fire up my
trusty C++ compiler to get to the answer.   A couple of times I had to
wait for the following month's installment with the published answer.

In Ada, this kind of thing would be less likely.

Richard Riehle 

Re: why learn C?

[Cesar Rabak]

Larry Kilgallen escreveu:
> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes:
> 
>> I cannot imagine anyone writing a column
>> called "Obfuscated Ada."
> 
> Number_of_Genders_Encountered : Integer;
> Traffic_Light_Color : Boolean;
> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module;
Well after going through MyIntenrs� Ada_Obfuscator V. XLIV it can get 
harder:

X1 : Integer;
X2 : Boolean;
X3 : Y77;



[1] obviously a registered mark ;-)

Re: why learn C?

[Markus E Leypold]

<adaworks@sbcglobal.net> writes:

> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message 
> news:c82IfUV$xbi8@eisner.encompasserve.org...
>> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, 
>> <adaworks@sbcglobal.net> writes:
>>
>>> I cannot imagine anyone writing a column
>>> called "Obfuscated Ada."
>>
>> Number_of_Genders_Encountered : Integer;
>> Traffic_Light_Color : Boolean;
>> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module;
>

> OK.  With a little effort, one can write obfuscated code in any
> language.  However, with C++ it is far more likely than with Ada.

Obfuscation is a voluntary effort, though. The word "likely" probably
can't be applied then.

If we're just talking about non-understandable code, I suggest that
the "terse" syntax of the C/C++ language family is only a part of the
problem. Choosing wrong or indecriptive identifiers (perhaps in a
language one isn't fluent in -- or in a language the reader isn't
fluent in ... :-)) can happen in Ada as well.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

Cesar Rabak <csrabak@yahoo.com.br> writes:

> Larry Kilgallen escreveu:
>> In article <o2cPh.4026$u03.1786@newssvr21.news.prodigy.net>, <adaworks@sbcglobal.net> writes:
>>
>>> I cannot imagine anyone writing a column
>>> called "Obfuscated Ada."
>> Number_of_Genders_Encountered : Integer;
>> Traffic_Light_Color : Boolean;
>> Completion_Flag : My_Special_Record_Type_Defined_in_Another_Module;
> Well after going through MyIntenrs� Ada_Obfuscator V. XLIV it can get
> harder:
>
> X1 : Integer;
> X2 : Boolean;
> X3 : Y77;

Is that really harder? At least here it's evident that the names don't
mean anything. But Traffic_Light_Color:Boolean really suggests
something that is wrong. 

Regards -- Markus

Re: why learn C?

[Georg Bauhaus]

Peter C. Chapin wrote:
> Georg Bauhaus <bauhaus@futureapps.de> wrote in 
> news:1175246243.5771.67.camel@localhost.localdomain:
> 
>> If you allow me to be pedantic, SPARK is not distinguished from
>> Ada by external rules for programmers. Rather, it has its own
>> language definition, and translators that know about nothing
>> but the SPARK language. This approach is very different from
>> establishing coding rules.
> 
> How is it different than using coding guidelines together with a tool 
> that checks them automatically?


Maybe I was incorrectly assuming that coding rules are not
enforced in the same way that language rules are enforced, because
using a special language parser with rule checks built in requires
additional efforts and tedious discipline (in the short run).
But I'm not too confident that the efficacy of coding rules
without such a tool is de facto the same as that of existing language
rules. Coding rules require programmers who will apply the rules
by their own free will and who know quite a bit about programming.


> As you can probably guess, I'm a big 
> believer in extending a programming language with tools.

I would even hope that a systematic survey of how tools for translation,
checking, "architecture" etc. are used  can help establish some knowledge
of what a future very high level language should provide.

But here's a case demonstrating that now we are (still) in sore need of 
good language rather than good rules. (A difficulty of arguing in favor of
a "strict" Ada-like language will be the "works for me razor" applied by
those who seem to be using less strict languages with seemingly good success.
The argument is similar to that of very good Lisp programmers who build
well working macros reflecting their own sophistication with all pros and
cons of that. As you have mentioned, it may be fine for small teams.)
The case is that of conditionals where a condition is written
after the statement that it controls, but the programming language is not
really using postfix notation. Postfix conditionals aren't in either
C++ or Ada, but they serve well as an example of where the human element
matters in adopting rules or not.

The postfix conditional has been in Perl for some time, and postfix
forms of conditionals and loops are being added to Python. Perl::Critic,
a rule checking tool, will warn about postfix conditionals, a negative 
rule being based on the recommendations of a well received book
(Perl Best Practices (PBP)).
But why is the postfix form of "if" nevertheless popular in new Perl code,
even added to Python, although it has been identified as a problem?
My guess is that a human can say, "do this unless there is X", a postfix
conditional. By doing so he or she uses a common mode of expression that
is well understood by a human, hence seems acceptable, even natural.[1]
Another reason of continuing popularity of postfix if, opposing the PBP rules,
might be that a popular Perl book doesn't talk about the dangers of postfix if.

Like C++ and Ada, Perl is a given language. Corresponding tools are just not
used frequently, so we will continue to see code that recreates fancy pitfalls.
Therefore, the best way for years of rule checking experience to manifest
itself in software is adding the most important results to the language
proper. Or, where possible, use a language that enforces these rules by
definition.


[1] "The *if* and *unless* modifiers work pretty much as you'd expect
if you speak English." (Wall, L.; Christiansen, T.; and Schwartz, R.L.:
Programming Perl)

Re: why learn C?

[adaworks]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:eujrs1$9e$1@jacob-sparre.dk...
> <adaworks@sbcglobal.net> wrote in message
> news:o2cPh.4026$u03.1786@newssvr21.news.prodigy.net...
>>  I cannot imagine anyone writing a column
>> called "Obfuscated Ada."
>
> Not a column, perhaps, but surely you could write an interesting article.
> Ada has plenty of ways to write something simple in wonderfully long-winded
> ways which potentially harm readability. And there are various non-obvious
> idioms that are very handy, like using Boolean'Pos to get the effect of a
> conditional expression:
>
> Something : Integer := Boolean'Pos(<condition>)*Function1 + Boolean'Pos(not
> <condition>)*Function2;
>
This does not compare with the possibilities for obfuscation in C++.   Further,
we know quite a bit about this example early, even though we may not know
what its intent is on first reading.

I do know that there is no automatic promotion of values.  I am confident that
Something, as described is of type Integer.   I am also secure in understanding
that the expression needs to evaluate to a predefined type Integer.   Type
qualification, Boolean'Pos(...) ensures there is no type mismatch anywhere
in the expression.

In other words, one can easily reason about the expression without knowing
its details.

Richard Riehle 

Re: why learn C?

[Martin Krischik]

Pascal Obry wrote:

> kevin cline a ï¿œcrit :
> 
>> No, what actually happened is that expert C++ developers learned to
>> use C++ in such a way that those errors can not happen.  While it is
>> possible to write unsafe code in C++, it is also possible to adopt
>> coding guidelines that makes it easy to find and eliminate unsafe
>> code, and for most applications, that's quite good enough.  One reason
> 
> Sorry but you must live in another planet :) All the C++ code I've seen
> are so full of bugs that I'm not inclined to buy that! Ok it *may* be
> possible but how many C++ programmers are *good* enough and *wise*
> enough to achieve that ? That's the real question to me, and from where
> I stand this is close to 0% !

I am more optimistic - I put it at 1% ;-).

Martin 
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: why learn C?

[Peter C. Chapin]

Georg Bauhaus <bauhaus@futureapps.de> wrote in
news:460f0951$0$23134$9b4e6d93@newsspool1.arcor-online.net: 

> Like C++ and Ada, Perl is a given language. Corresponding tools are
> just not used frequently, so we will continue to see code that
> recreates fancy pitfalls. Therefore, the best way for years of rule
> checking experience to manifest itself in software is adding the most
> important results to the language proper. Or, where possible, use a
> language that enforces these rules by definition.

The advantage of using tool checked coding guidelines is that everyone can 
customize them. The disadvantage of using tool checked coding guidelines is 
that everyone can customize them. :-)

Peter

Re: why learn C?

[Ed Falis]

Markus E Leypold wrote:
..

> In summary: Technical merits of languages play only a tiny part in
> decisions for or against a given language. But I already have said
> that often enough, haven't I?

Perhaps you should pick up a copy of Peter Middleton's and James
Sutton's "Lean Software Strategies".  They make the same argument with
respect to purely technical factors, but then go on to recommend Ada as
the most appropriate language for the strategies they promote based on
its contribution to the integrity of the software production process.
The latter is a value that they rate as much, much more important than
sheer technical characteristics (contributing something like 40% vs 5%
to project outcomes).

http://www.amazon.com/gp/product/1563273055/103-1669742-0555007

- Ed

Re: not NASA Ada coding standard

[Simon Clubley]

In article <u648hbnx1.fsf_-_@stephe-leake.org>, Stephen Leake <stephen_leake@stephe-leake.org> writes:
> "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:
> 
>> The corresponding Ada coding standard is found at
>> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf
> 
> Putting on my NASA hat, I must point out that those standards are
> _not_ NASA-wide standards, but Goddard flight software standards.
> Goddard is only one of many NASA centers, and the flight software
> group at Goddard is a small part of the Goddard software community.
> 

Do you have online pointers to the other NASA department level, or even
better, NASA-wide, standards ?

I, for one, would be very interested in reading them.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

Re: why learn C?

[Pascal Obry]

Martin Krischik a ï¿œcrit :

> I am more optimistic - I put it at 1% ;-).

Yes probably :) I was just a bit upset by those *theoretical* arguments
when day after day you try to understand or try to make a junk C++ code
working !

So in theory there is no difference between the theory and the practice
but in practice there is :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: why learn C?

[tmoran]

> If we're just talking about non-understandable code, I suggest that
> the "terse" syntax of the C/C++ language family is only a part of the
> problem. Choosing wrong or indecriptive identifiers ...
  As I recall, the obfuscated C examples weren't generally about
stupidly chosen identifiers, but more often C code which appeared at
first glance to do one thing, but on *close* parsing of the syntax,
actually did something else.

Re: why learn C?

[tmoran]

> > Sorry but you must live in another planet :) All the C++ code I've seen
> > are so full of bugs that I'm not inclined to buy that! Ok it *may* be
> > possible but how many C++ programmers are *good* enough and *wise*
> > enough to achieve that ? That's the real question to me, and from where
> > I stand this is close to 0% !
>
> I am more optimistic - I put it at 1% ;-).
   When I was first switching from C to Ada I sometimes tried translating
some existing C code (no, not necessarily mine) to Ada and that process
almost invariably revealed errors in the C code.

Re: why learn C?

[kevin cline]

On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:
> > * kevin  cline wrote:
> >> "The big difference is that C++ templates allow type checking during
> >> compile-time, so that no overhead neither in memory space nor in
> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
> >> than Ada generics."
>
> > This is correct. C++-Templates itself are a Lisp dialect and Turing complete.
>
> One should be careful with such statements. In fact it is apples and
> oranges, because whatever power templates might have, they are *not*
> executed on the target machine.

So what?  The discussion was about compile-time type safety, and the
point is that C++ templates, being Turing complete, allow more
thorough compile type checking than is possible in Ada.

Re: why learn C?

[Brian May]

>>>>> "kevin" == kevin cline <kevin> writes:

    kevin> "The big difference is that C++ templates allow type
    kevin> checking during compile-time [...]

How is this any different from Ada generics?

Ada generics do type checking at compile-time too.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: why learn C?

[kevin cline]

On Mar 30, 12:39 pm, <adawo...@sbcglobal.net> wrote:
> "kevin cline" <kevin.cl...@gmail.com> wrote in message
>
> news:1175230700.925143.28490@n59g2000hsh.googlegroups.com...
>
> > Ada gives you low-level type safety out of the box, but does not
> > afford the tools necessary to achieve type-safety in high-level
> > programming.  Low-level C++ coding is not type safe, but C++ provides
> > powerful mechanisms to write high-level type-safe code.
>
> On reading the Grein paper, it is clear that the advantage is a very
> small, and very narrowly focused one.

To me, it's a large advantage, and not narrowly focused at all.  I
would think the inability to perform complete compile-time checking of
physical units would be pretty serious in real-time control
applications.  Do Ada programmers make do with run-time type checking,
or just write more and more generic function instantiations until the
application is finished?  The rest of use have more important things
to do.

Any suggestion that C++
> is, as a general principle, safer than Ada is simply a fantasy.

It's not safer, AS A GENERAL PRINCIPLE.  But in the hands of experts, C
++ allows compile-time type checking that is impossible in Ada.

>
> Overall, compile-time safety in Ada is substantially superior to that
> in C++.    C and C++ are highly error-prone.

... when used by poorly lead mediocre programmers.

> Programmers who
> choose C++ take for granted that long hours of debugging obscure
> errors is the way life ought to be.

No doubt some programmers do.  Good C++ programmers don't.  I
certainly don't.

> As for high-level programming, this is where Ada does excel.

Not for most of us, because the advantages in safety are overwhelmed
by the increased verbosity.

> For
> large-scale, multi-developer projects C++ simply is a mess.   There
> is no dependable model for separate programming.  Oh yes, those
> CPP files!  Well, they are inherently part of their own specification
> and they need to be augmented by compiler directives just to make
> sure there are not errors.
>
> I nearly guffawed when reading your last sentence.  C++ as type
> safe?  What a joke.   Sadly, I suspect you actually believe this.
>
> With all mechanisms available in Ada for developing solid, dependable
> code and a language definition that focuses on creating compilers that
> maximize the amount of error detection that can be done early in
> the development process, I wonder whether you really understand
> Ada at all.   Have you any understanding of the visbility rules?  This
> goes well beyond type-safety.    Do you understand the library model
> and how it affects separate compilation?

Do you understand how unimportant those theoretical considerations are
for those of us faced with time-to-market pressure?  Do you understand
how the start of the art in C++ compilers and C++ programming has
advanced since Ada-95 was introduced?

>
> As for the safety of generics, Grein's paper, which you take delight
> in citing, does not discount the fact that most generic constructs
> are type-safe at compile time.    Further, getting it right, with C++
> templates is no trivial feat either.

Actually, it's pretty trivial once you learn to think at the right
level of abstraction.  And if no one on a team can think at the right
level of abstraction, you will end up with a mess regardless of the
language chosen.

> There are plenty of opportunities
> to create errors in C++ templates.
>
> I have programmed in both languages.

How much?

> I have taught C++

Which textbook did you use?

> and I have
> taught Ada.   I have colleagues who use both languages who realize
> that C++ is far more error-prone than Ada.    While one can get a
> good set of working software in C++ using heroic efforts,

Heroic efforts are not necessary.  These days, about all that is
necessary is to avoid writing code that produces compiler warnings.

the chance
> of errors in a C++ program is much higher in a corresponding program
> written in Ada.  I find it strange that anyone who understands both
> languages well would come to any other conclusion.

For me, the short reason is that Ada generics are not as powerful as C+
+ templates.  The power of C++ templates has enabled me to write
compact, efficient type-safe application code at a very high level in
a way which is not possible in Ada.

Re: why learn C?

[Harald Korneliussen]

To ensure that minimal safety guidelines are in fact followed in C++,
and not just stand there on some piece of paper, you need a
programmable static analyzer a la Coverity, Klocwork, etc. The
template system can be (ab)used to do static checking for you in some
cases (you mention units), but not all - you can't ensure that the
elaborately constructed safe functions are actually used, for
instance.

But if you already need a programmable static analyzer, couldn't you
use it to get the checks through that instead of templates?

I dare say you don't need a big static analyzer of that kind to make
type safe Ada.

(concering "power", the C preprosessor is also turing-complete, which
means that there probably is a way to use that for type safe units as
well.)

Re: why learn C?

[kevin cline]

On Apr 2, 12:03 am, Brian May <b...@snoopy.apana.org.au> wrote:
> >>>>> "kevin" == kevin cline <kevin> writes:
>
>     kevin> "The big difference is that C++ templates allow type
>     kevin> checking during compile-time [...]
>
> How is this any different from Ada generics?

Because Ada generics have to be explicitly instantiated.  Ada requires
an explicit instantiation for every combination of types that appears
in the program.  C++ template functions are implicitly instantiated,
and can be defined once to cover all combinations of physical units,
like this:

template <int M, int L, int T> class Unit
// Mechanical unit with mass dimension M, length dimension L,
// and time dimension T.
{
private:
  double value;
public:
  explicit Unit(double v): value(v) {}
  Unit operator+(Unit rhs) { return Unit(v + rhs.v); }
  Unit operator-(Unit rhs) { return Unit(v - rhs.v); }
  Unit<M+M2,L+L2,T+T2> operator*(Unit<M2,L2,T2>& rhs)
  { return Unit<M+M2,L+L2,T+T2>(v * rhs.v); }
  ...
};

typedef Unit<0,0,0> Scalar;
typedef Unit<1,0,0> Mass;
typedef Unit<0,1,0> Length;
typedef Unit<0,0,1> Time;
typedef Unit<1,1,-2> Force;
typedef Unit<1,-1,-2> Pressure;
typedef Unit<1,-3,0> Density;

Mass gram(1);
Length meter(1);
Time second(1);

Pressure water_pressure(Length head)
{
  Force g_earth = Scalar(9.8)*meter/second/second;
  Density water_density = Scalar(1000000)*gram/meter/meter/meter;
  return head * g_earth * water_density;
}

Ada would require a separate instantiations for each of these
operations:

Scalar * Length (returning Length)
Length / Time (returning Velocity)
Velocity / Time (returning Acceleration)
Scalar * Mass (returning Mass)
Mass / Length (returning Unit<1,-1,0>)
Unit<1,-1,0>/Length (returning Unit<1,-2,0>)
Unit<1,-2,0>/Length (returning Density)
Length * Acceleration (returning Unit<0,-2,2>)
Unit<0,2,2>*Density (returning Pressure)

Shortage on C / C++ experts

[Martin Krischik]

kevin cline schrieb:

>> Any suggestion that C++
>> is, as a general principle, safer than Ada is simply a fantasy.
> 
> It's not safer, AS A GENERAL PRINCIPLE.  But in the hands of experts, C
> ++ allows compile-time type checking that is impossible in Ada.

So does Assembler. Problem is that only 1% of C / C++ programmers are 
experts. You don't belive me? Well, on the last C++ project I worked I 
was the only developer who knew that virtual inheritance exitst. And one 
team created (simplification):

class A: IMouseHander, IKeyboardHandler
class B: public A, IMouseHander, IKeyboardHandler
class C: public B, IMouseHander, IKeyboardHandler
class D: public C, IMouseHander, IKeyboardHandler

This is how real live looks. Of course abstraction is bullshit. But 
using inheritance saved them aprox. 50 keystrokes per handler.

No such thing as "in the hands of experts" or "Good C++ programmers 
don't.". The feature is there it will be used. Whole teams go for years 
without a single "expert" at there disposal.

And when they asked the only expert around (me) it was to late.

> Heroic efforts are not necessary.  These days, about all that is
> necessary is to avoid writing code that produces compiler warnings.

Of course the team in question did not have /W4 activated - they used no 
/W at all witch is "/W0". They did not have an expert to analyse there 
compiler switches.

The bitter truth is: There are not enough experts around.

Martin

Re: why learn C?

[kevin cline]

On Mar 31, 8:18 am, "Peter C. Chapin" <pcha...@sover.net> wrote:
> As you can probably guess, I'm a big
> believer in extending a programming language with tools. It's too bad
> that building tools for C++ is such a big pain in the neck. C++'s nasty
> syntax, together with the preprocessor, are probably the worst things
> about the language because they inhibit tool building.

The preprocessor is no trouble at all, because it can be run
separately. But it's true that C and C++ are hard to parse with a LALR
grammar.

Building a full Ada parser from scratch is not easy either.  The
easiest way to write tools for either language is probably to build on
the GNU parsers.

Re: why learn C?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1175488143.324741.283480@y80g2000hsf.googlegroups.com...
> On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:
>> > * kevin  cline wrote:
>> >> "The big difference is that C++ templates allow type checking during
>> >> compile-time, so that no overhead neither in memory space nor in
>> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
>> >> than Ada generics."
>>
>> > This is correct. C++-Templates itself are a Lisp dialect and Turing 
>> > complete.
>>
>> One should be careful with such statements. In fact it is apples and
>> oranges, because whatever power templates might have, they are *not*
>> executed on the target machine.
>
> So what?  The discussion was about compile-time type safety, and the
> point is that C++ templates, being Turing complete, allow more
> thorough compile type checking than is possible in Ada.
>
Quite simply not true.   I wonder whether you really understand Ada.
The principle design goal of Ada is for a language that supports the
maximum amount of error checking as early in the development
process as possible.

With a very small number of exceptions, Ada does this better than
most existing languages and certainly better than C++.

As to C++ templates, the Grein paper is rather narrowly focused and
in ordinary cases, Ada templates are as type-safe as those in C++,
and in all but a few cases more so.   Further, C++ templates support
an excessively complicated model that is easily turned into a mismash
of errors that are not so easily detected until one is well along into
the debugging process.

Ada's visibility rules, which I suspect you do not understand very well
due to your assertions about the language, are a powerful capability for
ensuring a substantial amount of error-checking at compile time.  C++
does not have this feature.   Ada's library model, where the specification
and the implementation are separately compiled, but also checked bit
by bit by the compiler is also missing from C++.    C++ data types are
rather thin compared to those in Ada, and the ability of an Ada designer
to design new types with constrained values is also missing from C++,
unless one chooses to jump through hoops.

There are so many benefits of Ada over C++ that anyone who wants
to make an objective comparison can only conclude that Ada is, in
most respects (not all respects), a far better language for developing
dependable software.

C++, on the other hand, is inherently error-prone.   There are so many
gotchas in the syntax and semantics that C++ developers are forced to
depend on long hours of debugging -- far more of this than the equivalent
Ada developer.

If you do not know Ada, you can be forgiven for not realizing any of this.
However, it might be useful for you to become acquainted with it so you
will have a better understanding of what you criticize.

I have programmed in Ada and C++.   From my own experience, C++ is
not a language I would ever want to use for anything that had to work
predictably after being deployed.   It is just too full of surprises.

Richard Riehle 

Re: why learn C?

[adaworks]

"Markus E Leypold" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
wrote in message news:0fbqi9tncx.fsf@hod.lan.m-e-leypold.de...
>
>
> The way Richard presents things distorts reality somewhat: He gives
> the impression that there is a number of peple out there, which know
> C++ and Ada equally well, start projects with an absolutely clean
> slate (no development environment, no code base on which to build, no
> corporate guide lines) and then -- with seeing eyes -- decide for C++
> and against Ada, but still expect completely error free software.
>
Good observation. Well-phrased and thoughtful.

I realize that few people know both languages well.   I also know that
projects rarely start with a clean slate.

There are certainly circumstances where C++ is the preferred option.
These usually are environments where everyone is already well-trained
and experienced in C++.    Moving to a new language should never
be taken lightly.   One reason C++ has been so successful is that it
is familiar with those who originally programmed in C.

I have counseled people to avoid new languages on many occasions.  On
one occasion, a three-star general asked me whether he should convert all
his Fortran code to Ada.  My answer was, No.   On another occasion, I
was asked about what to do about COBOL in a shop that had hundreds
of thousands of code in COBOL.  "Should we convert to Java?"  My answer
was again an emphatic No!

In my own experience, I have had the opportunity to program in many different
languages on a lot of different kinds of projects.   I have been doing this for
well over forty years.    I realize that every language has its good points and
bad points.   Some have more bad points than others.

When I look at C++, versus the alternatives, I see a language that should be
retired from service at the earliest opportunity.   It is dangerous, messy, and
error-prone.   It served its purpose for a while.  It was considered useful for
its alleged efficiency.   This issue is largely moot.   At present, C++ is 
nothing
more than an object-oriented universal Assembler.   From time to time it is
still useful.  However, newer languages have come into existence and C++ is
something of a buggy-whip equivalent.

If we are to move the profession forward to a more engineering discipline, the
buggy-whip needs to be replaced with more appropiate tools.

Functional languages such as OCAML are showing their advantages, where
they are used.   Eiffel continues to be an excellent alternative when one needs
an OOP language with a bit more dependabilty.   And Ada continues to evolve
well, even though it still needs more evolution in subsequent iterations.  C++,
on the other hand, seems to be evolving new features with the principle intent
of fixing things in the existing language that are broken.    With all the 
better
alternatives available, I can only wonder why anyone would deliberately
choose C++.

Of particular concern, for me, is the nitwits who have chosen C++ over Ada
for military weapon systems.   This is absolutely horrible.   I deal regularly 
with
the young military personnel who are going to have to rely on the software
in those systems, and it frightens me that we are sending them into combat
with equipment programmed in language that is inherently error-prone.

Richard Riehle 

Re: why learn C?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1175491660.511530.58430@y80g2000hsf.googlegroups.com...
>
> For me, the short reason is that Ada generics are not as powerful as C+
> + templates.  The power of C++ templates has enabled me to write
> compact, efficient type-safe application code at a very high level in
> a way which is not possible in Ada.
>
Those of us who use Ada write efficient, type-safe application code in
Ada all the time and it is certainly possible in Ada.    Further, those Ada
generics are checked at compile-time.  That is a fundamental feature
of the language.

Richard Riehle 

Re: why learn C?

[kevin cline]

On Apr 2, 2:07 am, <adawo...@sbcglobal.net> wrote:
> "kevin cline" <kevin.cl...@gmail.com> wrote in message
>
> news:1175491660.511530.58430@y80g2000hsf.googlegroups.com...
>
> > For me, the short reason is that Ada generics are not as powerful as C+
> > + templates.  The power of C++ templates has enabled me to write
> > compact, efficient type-safe application code at a very high level in
> > a way which is not possible in Ada.
>
> Those of us who use Ada write efficient, type-safe application code in
> Ada all the time and it is certainly possible in Ada.

No doubt you do.  I have written efficient type-safe application code
in Ada too.  But for the most interesting sorts of computationally
intensive applications I have written, I found C++'s powerful
templates to be indispensable.

For example, for a logistics application, variable quantities were
modeled as piecewise constant functions of time, but for efficiency
there were multiple implementing classes: one for functions that were
constant over all time, another for functions that were periodic,
another for functions whose variation was defined by a table, and so
on.

With C++ templates it was a relatively simple matter to define an
algebra on those functions so that one could say things like:

 Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q);

even though f1, f2, f3, and f4 were possibly of different types.

In Ada, dozens of lines of generic instantiations would have been
needed before the expression could be written.

Re: why learn C?

[kevin cline]

On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"
<jimmaureenrog...@worldnet.att.net> wrote:
> On Mar 30, 12:30 am, "Case Crab" <casec...@gmail.com> wrote:
>
> > On Mar 29, 10:52 pm, "jimmaureenrog...@worldnet.att.net"
>
> > <jimmaureenrog...@worldnet.att.net> wrote:
> > > On Mar 29, 6:51 pm, "kevin  cline" <kevin.cl...@gmail.com> wrote:
>
> > > > No, what actually happened is that expert C++ developers learned to
> > > > use C++ in such a way that those errors can not happen.  While it is
> > > > possible to write unsafe code in C++, it is also possible to adopt
> > > > coding guidelines that makes it easy to find and eliminate unsafe
> > > > code, and for most applications, that's quite good enough.
>
> > > Coding guidelines cannot by themselves prevent any errors.
>
> > Really?  I have found that coding practices can preclude certain
> > classes of errors.
>
> The JSF C++ coding standards are available from several sources on the
> web. One link ishttp://www.research.att.com/~bs/JSF-AV-rules.pdf
>
> The corresponding Ada coding standard is found athttp://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf
>
>
>
>
>
> > > For example,
> > > the JSF AV C++ Coding Standard, which is intended to limit the unsafe
> > > features of C++, contains 221 rules.
>
> > How many rules distinguish SPARK from the full Ada language?
>
> > > It is not possible to check
> > > 6 million lines of code against 221 rules by hand in any timely or
> > > economical manner.
>
> > I expect that most of the checking can and will be done
> > automatically.  In any case, I would expect such
> > mission-critical code would be inspected, regardless of whether the
> > implementation language is C++ or Ada.
>
> Inspection is the problem. It is inefficient and error prone to
> manually inspect 6 million lines of code against 221 rules.
>
> There is an automated tool for checking the JSF standard. That
> tool cannot perform a 100% check either due to the nature of the
> rules.
>
>
>
> > > The NASA Ada Flight Software coding guidelines contain 14 rules.
> > > The intent of both coding standards is to produce software safe enough
> > > to use for airborne avionics systems.
>
> > Interesting that one organization has 221 rules while the other has
> > only 14.
>
> If you analyze the two standards, and understand the two languages,
> you
> will see that the 221 rules for C++ bring you close to the same safety
> level you achieve with the 14 rules for Ada.
>
> Many of the language features prohibited in the C++ standard simply do
> not exist in Ada. This explains the bulk of the differences in the two
> standards. For instance:
>
> AV Rule 20 (MISRA Rule 122)
> The setjmp macro and the longjmp function shall not be used.
>
> Ada has no macros and no equivalent to the longjmp function.
> There is no reason to prohibit their use in Ada.
>
> Similarly:
>
> AV Rule 29
>   The #define pre-processor directive shall not be used to create
> inline macros. Inline functions shall be used instead.
>   Rationale: Inline functions do not require text substitutions
> and behave well when called with arguments
> (e.g. type checking is performed).
>
> Ada does allow inline functions and procedures, but has no
> language defined macro capability.
>
> AV Rule 71.1
>   A class's virtual functions shall not be invoked from its
> destructor or any of its constructors.
>   Rationale: A class's virtual functions are resolved
> statically (not dynamically) in its constructors and
> destructor.
>
> Ada does not provide a direct equivalent to C++ constructors
> and destructors. While this may seem a problem to a C++ or
> Java programmer, it does have the virtue of not providing
> an avenue for the error handled by this rule.
>
> And the C++ multiple inheritance model provides interesting
> opportunities for unsafe code:
>
> AV Rule 89
>   A base class shall not be both virtual and non-virtual in
> the same hierarchy.
>   Rationale: Hierarchy becomes difficult to comprehend and use.
>
> Do not forget about all the wonders of pointers in C and C++.
> For example:
>
> AV Rule 97
>   Arrays shall not be used in interfaces. Instead, the Array
> class should be used.
>   Rationale: Arrays degenerate to pointers when passed as
> parameters. This "array decay" problem has long been known to be
> a source of errors.
>
> Ada arrays do not decay to pointers. This problem is unknown in
> Ada with or without coding standards.
>
>
>
> > > Coding standards can help up to a point. When the coding standards are
> > > oppresively complex they cease to help.
>
> > Compile-time checks can also help, up to a point.  But they don't
> > solve the whole problem.
>
> No, run time checks are needed for things that cannot be checked at
> compile time. Ada helps is more helpful with run time checks than is
> C or C++ due to the automated check writing built by the compilers.
> For instance, if you define an integer type with a valid range of
> values from -10 to 10, the compiler will perform all necessary
> range checking for that type.
>
> type My_Int is range -10..10;
>
> You can provide run time checking in any language. In C++ you would
> need to define a class for My_Int.

Actually, you would define a template class RangedInt, and then write
something like:

  typedef RangedInt<-10,10> My_Int;

> The assignment operator would need
> to be re-defined to check for the range, and throw an exception when
> the range limits are violated.

Right.  One eight-line class to replicate the Ada ranged integer type.

>
> C++ provides additional challenges to the definition and checking of
> limited range integer types. In C and C++ (and Java) all numeric types
> are initialized by default to 0.

Not exactly.

> What does that do to your program if
> 0 is not within the valid range for your type?

> The compiler will
> simply initialize the data member of your class to an invalid value.
> You will need to provide a default constructor to initialize the value
> to some valid value, along with the overridden assignment operator.

True.  The C++ design philosophy was that features would not be added
to the language if they could be implemented as library classes.  A
limited-range integer is a pretty trivial class to write, so there was
no need to add it to the language.  Also, C++ was designed with the
idea that if you didn't need it, you didn't have to pay for it.  So
variables are not automatically initialized.  Modern compilers produce
warnings if it is possible for a variable to be used before it has
been initialized.

Re: why learn C?

[Dmitry A. Kazakov]

On 1 Apr 2007 21:29:03 -0700, kevin  cline wrote:

> On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:
>>> * kevin  cline wrote:
>>>> "The big difference is that C++ templates allow type checking during
>>>> compile-time, so that no overhead neither in memory space nor in
>>>> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
>>>> than Ada generics."
>>
>>> This is correct. C++-Templates itself are a Lisp dialect and Turing complete.
>>
>> One should be careful with such statements. In fact it is apples and
>> oranges, because whatever power templates might have, they are *not*
>> executed on the target machine.
> 
> So what?

That templates have power = 0 on the machine. You can compute *nothing*
using templates. They are simply not executed there. Period.

> The discussion was about compile-time type safety, and the
> point is that C++ templates, being Turing complete, allow more
> thorough compile type checking than is possible in Ada.

1. Here you compare the language of templates (a quite crippled one) with
the language in which the Ada compiler was written. Clearly, this
comparison cannot be in favor of templates. In case you doubt it, try write
a parser and code generator in C++ templates...

2. This all has nothing to do with types, because the meta language of
templates does not deal with language objects (types of which are supposed
to be checked). Templates are about templates of types, not types. The
result of template execution (by the compiler) is a C++ program which is
then checked using C++ types system. Thus templates add/remove absolutely
nothing to types safety. (Same as Ada generics, BTW)

3. The meta language of C++ templates is itself untyped. In contrast to the
language of Ada generics which is typed. So much for types safety.

P.S. There should better be neither templates nor generics.

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

Re: why learn C?

[kevin cline]

On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"  For instance:
>
> AV Rule 20 (MISRA Rule 122)
> The setjmp macro and the longjmp function shall not be used.
>
> Ada has no macros and no equivalent to the longjmp function.
> There is no reason to prohibit their use in Ada.

I haven't seen setjmp or longjmp used in about twenty years.  This is
not a practical problem in C++ programming.
>
> Similarly:
>
> AV Rule 29
>   The #define pre-processor directive shall not be used to create
> inline macros. Inline functions shall be used instead.
>   Rationale: Inline functions do not require text substitutions
> and behave well when called with arguments
> (e.g. type checking is performed).

Preprocessor macros are quite out of fashion for C++ programming.

>
> Ada does allow inline functions and procedures, but has no
> language defined macro capability.


>
> AV Rule 71.1
>   A class's virtual functions shall not be invoked from its
> destructor or any of its constructors.
>   Rationale: A class's virtual functions are resolved
> statically (not dynamically) in its constructors and
> destructor.
>
> Ada does not provide a direct equivalent to C++ constructors
> and destructors. While this may seem a problem to a C++ or
> Java programmer,

It's a huge problem when a class needs initialization.  Then you have
to mess around with controlled types.

> it does have the virtue of not providing
> an avenue for the error handled by this rule.

No, instead you get to deal with the problem of having objects that
have been created but require further initialization before use.  Or
else you have to create a controlled type, which is just complex
enough that most Ada programmers probably don't quite understand it,
so mostly it doesn't get done.

>
> And the C++ multiple inheritance model provides interesting
> opportunities for unsafe code:
>
> AV Rule 89
>   A base class shall not be both virtual and non-virtual in
> the same hierarchy.
>   Rationale: Hierarchy becomes difficult to comprehend and use.

And in 10 years of C++ programming I never saw anyone even tempted to
do this.

>
> Do not forget about all the wonders of pointers in C and C++.
> For example:
>
> AV Rule 97
>   Arrays shall not be used in interfaces. Instead, the Array
> class should be used.
>   Rationale: Arrays degenerate to pointers when passed as
> parameters. This "array decay" problem has long been known to be
> a source of errors.
>
> Ada arrays do not decay to pointers. This problem is unknown in
> Ada with or without coding standards.

It's not a practical problem for C++ programmers either, because we
don't much use arrays anymore, except as needed to call C libraries.

>
>
>
> > > Coding standards can help up to a point. When the coding standards are
> > > oppresively complex they cease to help.
>
> > Compile-time checks can also help, up to a point.  But they don't
> > solve the whole problem.
>
> No, run time checks are needed for things that cannot be checked at
> compile time. Ada helps is more helpful with run time checks than is
> C or C++ due to the automated check writing built by the compilers.
> For instance, if you define an integer type with a valid range of
> values from -10 to 10, the compiler will perform all necessary
> range checking for that type.
>
> type My_Int is range -10..10;

That's perfect if it happens to be the exact thing that you need.  It
doesn't help much if what you need is a point inside the unit circle.

In C++ the language provides neither of these things, but they are
both be implemented in a few lines of code.

In Ada, the implementation of the constrained point is not so
obvious.

Re: why learn C?

[kevin cline]

On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> 1. Here you compare the language of templates (a quite crippled one) with
> the language in which the Ada compiler was written.

Probably C or C++.

> Clearly, this
> comparison cannot be in favor of templates. In case you doubt it, try write
> a parser and code generator in C++ templates...

The Ada compiler is closed.  I can't go modify the Ada compiler and
get it to ensure that the physical units in my Ada program are
consistent.  But I can use C++ templates to define a type algebra, and
then use those types to insure that the equations in my C++ program
are consistent.

Re: why learn C?

[Martin Krischik]

kevin cline schrieb:

> True.  The C++ design philosophy was that features would not be added
> to the language if they could be implemented as library classes.  A
> limited-range integer is a pretty trivial class to write, so there was
> no need to add it to the language.

That would be fair enough if they actually added a limited-range integer 
class.

And how about a limited-range float ;-)

Martin

Re: why learn C?

[Harald Korneliussen]

On Apr 2, 8:37 am, "kevin  cline" <kevin.cl...@gmail.com> wrote:

> The preprocessor is no trouble at all, because it can be run
> separately.
No trouble at all? Ha! You can tell that to the Edison Design Group
people. For some real-life experiences about C++, see the first
article from this staic analysis summit:

http://samate.nist.gov/docs/NIST_Special_Publication_500-262.pdf

> But it's true that C and C++ are hard to parse with a LALR
> grammar.

It seems EDG are about the only ones with a decent semantic parser for
C++, even they have no chance whatsoever of supporting everything out
there (I'm stuck with a c++ compiler from this obscure little company
called Borland, so I can forget about static analysis tools)

> Building a full Ada parser from scratch is not easy either.  The
> easiest way to write tools for either language is probably to build on
> the GNU parsers.

In which case you get a GNU-specific parser, which is not a good
thing. I don't know how much easier it is to build an Ada parser, you
could ask the Bauhaus folks, their tool handles Ada (and is mostly
written in it, too).

Re: not NASA Ada coding standard

[Stephen Leake]

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:

> In article <u648hbnx1.fsf_-_@stephe-leake.org>, Stephen Leake
> <stephen_leake@stephe-leake.org> writes:
>> "jimmaureenrogers@worldnet.att.net"
>> <jimmaureenrogers@worldnet.att.net> writes:
>> 
>>> The corresponding Ada coding standard is found at
>>> http://software.gsfc.nasa.gov/AssetsApproved/PA2.4.1.1.1.pdf
>> 
>> Putting on my NASA hat, I must point out that those standards are
>> _not_ NASA-wide standards, but Goddard flight software standards.
>> Goddard is only one of many NASA centers, and the flight software
>> group at Goddard is a small part of the Goddard software community.
>> 
>
> Do you have online pointers to the other NASA department level, or even
> better, NASA-wide, standards ?

Unfortunately, no. 

We need to do a better job of this.

-- 
-- Stephe

Re: why learn C?

[Georg Bauhaus]

On Mon, 2007-04-02 at 00:43 -0700, kevin cline wrote:
> On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"

> > type My_Int is range -10..10;
> >
> > You can provide run time checking in any language. In C++ you would
> > need to define a class for My_Int.
> 
> Actually, you would define a template class RangedInt, and then write
> something like:
> 
>   typedef RangedInt<-10,10> My_Int;
> 
> > The assignment operator would need
> > to be re-defined to check for the range, and throw an exception when
> > the range limits are violated.
> 
> Right.  One eight-line class to replicate the Ada ranged integer type.

I'd add a few more lines to a RangedInt in order to have iteration
support, explicit range test, 'Valid, using integer operations with
compatible subtypes, computing in the base type, and having template
compile/link time checks for array-style data structures built on
top of the type properties of RangedInt. (Type casts?)

And then, unfortunately, C++ doesn't have dynamic types
(unless I'm missing something):

template <int left>
int foo(int n)
{
  typedef class RangedInt<left, n> Int;
  Int x(12);
  // ...
  return *x;
}

Int would have to be visible only from within foo(),
its values would have to be bound by n.
Objects of type Int would only exist within foo,
and be accessible while foo executes (no & allowed).
With Ada 2005, this is true of all locally extensible types.

But OTOH, is there any good reason to replace the handful
of machine oriented base types that C++ has (inherited
from C) and instead use something that is more predictable
and more expressive?
I think, yes, when apparently students can do their homework
significantly more successfully when they can choose names, values,
named values and types in the ways that have inspired the Ada type
system.
(According at least to a seemingly unbiased report presented here
some weeks ago, about an embedded systems class.)

Re: Shortage on C / C++ experts

[Larry Kilgallen]

In article <4610a3c8$1@news.post.ch>, Martin Krischik <krischik@users.sourceforge.net> writes:
> kevin cline schrieb:
> 
>>> Any suggestion that C++
>>> is, as a general principle, safer than Ada is simply a fantasy.
>> 
>> It's not safer, AS A GENERAL PRINCIPLE.  But in the hands of experts, C
>> ++ allows compile-time type checking that is impossible in Ada.
> 
> So does Assembler. Problem is that only 1% of C / C++ programmers are 
> experts.

So the problem is how to ensure that only experts are hired by the
company for whom you work.

And the larger problem is how to ensure that only experts are hired
by the manufacturers of airplanes on which you fly.

Re: Shortage on C / C++ experts

[Ludovic Brenta]

Larry Kilgallen wrote:
> So the problem is how to ensure that only experts are hired by the
> company for whom you work.
>
> And the larger problem is how to ensure that only experts are hired
> by the manufacturers of airplanes on which you fly.

And how to ensure that the experts never have a momentary lapse of
reason, to quote a well-known band.

--
Ludovic Brenta.

Re: why learn C?

[Dmitry A. Kazakov]

On 2 Apr 2007 01:19:19 -0700, kevin  cline wrote:

> On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> 1. Here you compare the language of templates (a quite crippled one) with
>> the language in which the Ada compiler was written.
> 
> Probably C or C++.

Ask AdaCore.

As for me, I have developed compilers of specialized languages in C++, Ada,
even in Assembly (with macros). No, I wouldn't advise anybody to use C++
for compiler construction...

>> Clearly, this
>> comparison cannot be in favor of templates. In case you doubt it, try write
>> a parser and code generator in C++ templates...
> 
> The Ada compiler is closed.  I can't go modify the Ada compiler and
> get it to ensure that the physical units in my Ada program are
> consistent.

You don't need to modify the compiler for that.

If you meant static checks, then it were trivially impossible in general
case. Units can be statically checked only under certain [rather rare]
conditions.

A good design should support static checks where possible and go run-time
elsewhere. Templated / generic solution obviously does not scale.

>  But I can use C++ templates to define a type algebra,

Which is a wrong way in a statically typed language, because see above.

It should be an algebra of the type *constraints*, which C++ has no notion
of.

> and
> then use those types to insure that the equations in my C++ program
> are consistent.

Try �C, K, sqrt (m�), then come back.

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

Re: Shortage on C / C++ experts

[Dmitry A. Kazakov]

On 2 Apr 2007 05:01:05 -0700, Ludovic Brenta wrote:

> Larry Kilgallen wrote:
>> So the problem is how to ensure that only experts are hired by the
>> company for whom you work.
>>
>> And the larger problem is how to ensure that only experts are hired
>> by the manufacturers of airplanes on which you fly.
> 
> And how to ensure that the experts never have a momentary lapse of
> reason, to quote a well-known band.

Umm, no, it is how to tie expertise to money. The rest is secondary.

It is the tickets we are paying for, not for speed, schedule, comfort, not
even for a chance to not to crash. After all both the first and the economy
classes would crash together...

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

Re: why learn C?

[adaworks]

"kevin cline" <kevin.cline@gmail.com> wrote in message 
news:1175491660.511530.58430@y80g2000hsf.googlegroups.com...
>
> For me, the short reason is that Ada generics are not as powerful as C+
> + templates.  The power of C++ templates has enabled me to write
> compact, efficient type-safe application code at a very high level in
> a way which is not possible in Ada.
>
I take your central point to be something related to the number
of instantiations required in Ada to accomplish a roughly equivalent
result in C++.   I will grant you that Ada does require more code
for each instantiation.   This tends to increase, not decrease, the
dependability since each instantiation is checked at compile-time.

Further, an example you provide, shown below:

          With C++ templates it was a relatively simple matter to define an
          algebra on those functions so that one could say things like:

          Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q);

          even though f1, f2, f3, and f4 were possibly of different types.

illustrates the problem quite nicely.  In fact, your acknowledgement of
the "different types" is quite telling.    Further, the ad hoc pointer is
potentially problematic.    A similar construct in Ada, using an access
to a function, requires the function to be type conformant and parameter
conformant prior to being incorporated into the construct.   That is, there
is more compiler checking before this construct is even allowed to be
compiled.

Type-safety is not a very strong argument for C++.   Granted, there has
been improvement in the latest version of the language.  Some (but not
all) of the unruly pointer behavior is gone.   However, by reference constructs
are still a potential source of error.   Friends are still problematic.  And the
disjoint between .h and .cpp files can create entertaining moments in the
life of the programmer.

You use typdef quite a bit.   The examples you give are reasonable.  However,
typedef does not provide the level of type safety one would expect in a
corresponding Ada program.  There is a structural equivalence that poses
some danger.

The reality is that C++ is not really as type-safe as Ada.  Consider the 
automatic
promotion of values from an integer to a float.   While this might seem trivial 
on
the surface, it is not a good example of type-safety -- certainly not an example
of strict typing.

I take your point about not using simple arrays.   The responsible C++ 
programmer
will not use that feature.   Ooops!   Sorry. I still see a lot of C++ code 
written that
way, and even using pointer computation.  It is just too easy to do that instead 
of
using those pesky libraries.   And the wonderful assortment of type-casting one
finds in C++ brings even more joy to the development process.  Particularly
amusing is casting away const.   One could go on, but it is 5 AM in the morning,
and I need to get ready for work.

The verbosity in Ada is no accident.   The programs are intended to be
more readable than writeable.   They are intended to be more reliable and to
be more checkable at compile-time.   Those are fundamental goals.  They
are, for the most part, achieved.    There is a good reason why Ada does not
have some of the wonderful little shortcuts you find so charming in C++: those
shortcuts and defaults are simply not suitable for producing dependable code.

In my most recent meeting with a bunch of C++ developers, there was general
agreement that one must use C++ with great care to avoid creating horrible
programs.   Everyone who uses C++ (except you, it seems) realizes that the
language is fraught with traps for the unwary programmer -- and even the
wary programmer.   I would expect one would want a language where the
focus was on using the language to solve application problems, not to solve
language problems.  This is where Ada and C++ part company.  When using
Ada, I am able to focus on the application problem rather than worrying about
the pitfalls inherent in the language.

Richard Riehle

Re: Shortage on C / C++ experts

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:
> After all both the first and the economy classes would crash together...

This is not exactly true. Perhaps you meant that business class and economy
class crash together; but business class in regular airline can't be regarded
as first class these days - there is plenty of private and corporate business
jets in the world... and they crash separately from economy class.

Re: Shortage on C / C++ experts

[tmoran]

> ... there is plenty of private and corporate business
> jets in the world... and they crash separately from economy class.
   I understand Boeing use Ada for flight control software on their
big (ie, containing economy class) jets.  What about the makers of
executive jets?  Does one executive say to another "I was going to
buy one of your jets, but then I learned it was programmed in C."

Re: why learn C?

[Randy Brukardt]

"kevin cline" <kevin.cline@gmail.com> wrote in message
news:1175501959.751535.23190@d57g2000hsg.googlegroups.com...
> On Apr 2, 2:52 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > 1. Here you compare the language of templates (a quite crippled one)
with
> > the language in which the Ada compiler was written.
>
> Probably C or C++.

The front-end of every Ada compiler that I know of (and know the
implementation language) is written in Ada. Some of them use shared
back-ends that are out of their control and are likely written in other
things.

My experience is that Ada is a great language for writing a compiler,
because it has strong type checking that is hard to circumvent. The issues
with type systems (like physical units) are irrelevant to compiler
construction.

I'm not quite sure why you're so concerned about generics/templates anyway.
There is little reason to write a generic if all you want to do is create
types in Ada: you just write an appropriate type declaration and package.
(Maybe it is because C++ doesn't have a separate encapsulation mechanism, so
you're pretty much stuck using classes for anything.) Yes, I agree that
writing a good package for units is a pain (especially since the method
you're suggesting won't work; it's probably best to just bite the bullet and
write out every operation you need), but you only have to do it once per
organization. (And the Amendment fixed the most important problem in Ada 95:
the inability to "erase" an inappropriate operation from a unit type
package.)

                                Randy.

Re: why learn C?

[Randy Brukardt]

"kevin cline" <kevin.cline@gmail.com> wrote in message
news:1175501602.127760.186120@q75g2000hsh.googlegroups.com...
> On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"  For instance:
...
>
> > Ada does not provide a direct equivalent to C++ constructors
> > and destructors. While this may seem a problem to a C++ or
> > Java programmer,
>
> It's a huge problem when a class needs initialization.  Then you have
> to mess around with controlled types.

You have that backwards: there is (almost) no reason for a tagged type to
not be controlled in Ada. All new types should be declared that way, unless
there is a compelling reason why the (tiny) space and time overhead matters.
I don't believe that there are many (if any) such types. But if there are
such types, how do you write a C++ class for them that doesn't have that
overhead?

> > it does have the virtue of not providing
> > an avenue for the error handled by this rule.
>
> No, instead you get to deal with the problem of having objects that
> have been created but require further initialization before use.  Or
> else you have to create a controlled type, which is just complex
> enough that most Ada programmers probably don't quite understand it,
> so mostly it doesn't get done.

Are these "most Ada programmers" the same as the "most C++ programmers" that
you claim don't matter? You're only willing to talk about "expert C++
programmers", so I think it is only fair that we only talk about "expert Ada
programmers". And no one that doesn't understand at least the basics of
controlled types (which are nearly trivial) could possibly be called an Ada
expert.

                                Randy.

Re: why learn C?

[Brian May]

>>>>> "kevin" == kevin cline <kevin> writes:

    kevin> Because Ada generics have to be explicitly instantiated.
    kevin> Ada requires an explicit instantiation for every
    kevin> combination of types that appears in the program.  C++
    kevin> template functions are implicitly instantiated, and can be
    kevin> defined once to cover all combinations of physical units,
    kevin> like this:

It is a compromise between:

- having a language where you are forced to be specific about the
details OR

- having a language where the compiler tries to guess what you meant.

Personally I prefer the first option, as I have found the second
option hides bugs.

Many programmers prefer the later, which is (presumably) why languages
like Perl, PHP, Python and ASP are so popular.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Apr 2, 12:03 am, Brian May <b...@snoopy.apana.org.au> wrote:
>> >>>>> "kevin" == kevin cline <kevin> writes:
>>
>>     kevin> "The big difference is that C++ templates allow type
>>     kevin> checking during compile-time [...]
>>
>> How is this any different from Ada generics?
>
> Because Ada generics have to be explicitly instantiated.  

That doesn't make them non type checking. Quite the opposite. And as
far as type checking in templates goes: Last time I looked, many usage
errors intemplates where not caught by a kind of type systems (which
would say "you can't use this tape as a parameter in a template), but
rather by the linker wwhich told me that there is no usch
function/method for this type: This is not type checking.

> Ada requires
> an explicit instantiation for every combination of types that appears
> in the program.  C++ template functions are implicitly instantiated,
> and can be defined once to cover all combinations of physical units,
> like this:

I think we had the problem already once: What about floating point
parameters to templates? :-)

>
> template <int M, int L, int T> class Unit
> // Mechanical unit with mass dimension M, length dimension L,
> // and time dimension T.
> {
> private:
>   double value;
> public:
>   explicit Unit(double v): value(v) {}
>   Unit operator+(Unit rhs) { return Unit(v + rhs.v); }
>   Unit operator-(Unit rhs) { return Unit(v - rhs.v); }
>   Unit<M+M2,L+L2,T+T2> operator*(Unit<M2,L2,T2>& rhs)
>   { return Unit<M+M2,L+L2,T+T2>(v * rhs.v); }
>   ...
> };
>
> typedef Unit<0,0,0> Scalar;
> typedef Unit<1,0,0> Mass;
> typedef Unit<0,1,0> Length;
> typedef Unit<0,0,1> Time;
> typedef Unit<1,1,-2> Force;
> typedef Unit<1,-1,-2> Pressure;
> typedef Unit<1,-3,0> Density;
>
> Mass gram(1);
> Length meter(1);
> Time second(1);
>
> Pressure water_pressure(Length head)
> {
>   Force g_earth = Scalar(9.8)*meter/second/second;
>   Density water_density = Scalar(1000000)*gram/meter/meter/meter;
>   return head * g_earth * water_density;
> }
>
> Ada would require a separate instantiations for each of these
> operations:
>
> Scalar * Length (returning Length)
> Length / Time (returning Velocity)
> Velocity / Time (returning Acceleration)
> Scalar * Mass (returning Mass)
> Mass / Length (returning Unit<1,-1,0>)
> Unit<1,-1,0>/Length (returning Unit<1,-2,0>)
> Unit<1,-2,0>/Length (returning Density)
> Length * Acceleration (returning Unit<0,-2,2>)
> Unit<0,2,2>*Density (returning Pressure)

Who cares? I'm a physicist (by education), but I have come to the
conclusion that judging the merits of a programming system on how much
I have to type to support checking physical units is cranky: It's a
fringe application and I can write a "physical units" definition file
and a translator to translate this into a Physical_Units package
(which does not only contain kg*m/s^2 (as your template does) but
actually the type Force) in some hours.

BTW: I haven't checked your C++ example, but I'd expect trouble if one
calculates


    f / m * t1 * t2 

as opposed to 

   t1 * t2 * f / m

since you need (dependend on the implicit grouping/association of the
multiplication operator) also operations 

   time * time  -> time^2

   time * force -> momemntum [kg*m/s]

and so on. Maybe the templating would automatically provide all this
(more power to C++ then), but it certainly looks like a complete mess

Regards -- Markus

  

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:
>> > * kevin  cline wrote:
>> >> "The big difference is that C++ templates allow type checking during
>> >> compile-time, so that no overhead neither in memory space nor in
>> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
>> >> than Ada generics."
>>
>> > This is correct. C++-Templates itself are a Lisp dialect and Turing complete.
>>
>> One should be careful with such statements. In fact it is apples and
>> oranges, because whatever power templates might have, they are *not*
>> executed on the target machine.
>
> So what?  The discussion was about compile-time type safety, and the
> point is that C++ templates, being Turing complete, allow more
> thorough compile type checking than is possible in Ada.

I fail to see what the one has to do with the other. Indeed, I'd
rather not write my own type checker in a lispish compile time
language.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:


> To me, it's a large advantage, and not narrowly focused at all.  I
> would think the inability to perform complete compile-time checking of
> physical units would be pretty serious in real-time control
> applications.  Do Ada programmers make do with run-time type checking,
> or just write more and more generic function instantiations until the
> application is finished?  The rest of use have more important things
> to do.

<...>

> It's not safer, AS A GENERAL PRINCIPLE.  But in the hands of experts, C
> ++ allows compile-time type checking that is impossible in Ada.

<...>

> ... when used by poorly lead mediocre programmers.

<...>

> No doubt some programmers do.  Good C++ programmers don't.  I
> certainly don't.

Is this a macho / male ego thing to you? It certainly sounds like it.


>> As for high-level programming, this is where Ada does excel.
>
> Not for most of us, because the advantages in safety are overwhelmed
> by the increased verbosity.

Haha. You don't sound like an experienced developer to my suspicious
ears ...


>> With all mechanisms available in Ada for developing solid, dependable
>> code and a language definition that focuses on creating compilers that
>> maximize the amount of error detection that can be done early in
>> the development process, I wonder whether you really understand
>> Ada at all.   Have you any understanding of the visbility rules?  This
>> goes well beyond type-safety.    Do you understand the library model
>> and how it affects separate compilation?
>
> Do you understand how unimportant those theoretical considerations are
> for those of us faced with time-to-market pressure?  Do you understand

"those of us faced with time to market pressure"? :-), indeed :-))).

I see you hunting bugs after you shipped banana software then for the
next years.

> how the start of the art in C++ compilers and C++ programming has
> advanced since Ada-95 was introduced?


>> As for the safety of generics, Grein's paper, which you take delight
>> in citing, does not discount the fact that most generic constructs
>> are type-safe at compile time.    Further, getting it right, with C++
>> templates is no trivial feat either.

> Actually, it's pretty trivial once you learn to think at the right
> level of abstraction.  And if no one on a team can think at the right
> level of abstraction, you will end up with a mess regardless of the
> language chosen.

:-)))


>> There are plenty of opportunities
>> to create errors in C++ templates.
>>
>> I have programmed in both languages.
>
> How much?
>
>> I have taught C++

> Which textbook did you use?



> For me, the short reason is that Ada generics are not as powerful as C+
> + templates.  The power of C++ templates has enabled me to write
> compact, efficient type-safe application code at a very high level in
> a way which is not possible in Ada.

More marketing speak ...

Regards -- Markus 

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

<... many things ...>

To me Kevin, what you write sounds plenty like so much
bullshitting. It's less that you oppose Ada and advocate C++ but the
way you do it.

I still think that in reality the case against C++ as vs. for Ada is
not as clear cut as many here think since other factors beside the
language itself have to be taken into consideration -- but whereas I
hopefully have been trying to explain my reasoning you're just
bragging about how much better you supposedly are than the average of
the industry and spouting so much nonsense (you're not even using the
word "type safe" right).

I can't get rid of the impression that -- as a programmer -- you're
actually rather immature and rather full of yourself.

Learn humility.

Regards -- Markus

Re: why learn C?

[jimmaureenrogers]

While the C++ template language is very powerful it is also
amazingly crippled in the eyes of an Ada programmer (me).
In discussions with C++ programmers concerning the ability
to write templates for range-specified numeric types I
discovered that C++ template language does not allow the
specification of a floating point value as a template
parameter.

Therefore, while one can write a C++ template to handle
range-specified integer classes, one cannot write a C++
template to handle range-specified floating point classes.

In other words, C++ allows you to write a template that
is equivalent to:

type My_Integer_Type is range 1..10;

But you cannot write a template equivalent to:

type Voltage_Type is digits 11 range -5.0..5.0;

Jim Rogers

Re: why learn C?

[jimmaureenrogers]

On Apr 2, 2:13 am, "kevin  cline" <kevin.cl...@gmail.com> wrote:
> On Mar 30, 9:41 pm, "jimmaureenrog...@worldnet.att.net"  For instance:
> > No, run time checks are needed for things that cannot be checked at
> > compile time. Ada helps is more helpful with run time checks than is
> > C or C++ due to the automated check writing built by the compilers.
> > For instance, if you define an integer type with a valid range of
> > values from -10 to 10, the compiler will perform all necessary
> > range checking for that type.
>
> > type My_Int is range -10..10;
>
> That's perfect if it happens to be the exact thing that you need.  It
> doesn't help much if what you need is a point inside the unit circle.
>

That is an interesting non-sequiter. No integer type would be
satisfactory to define a point within a unit circle.

> In C++ the language provides neither of these things, but they are
> both be implemented in a few lines of code.
>
> In Ada, the implementation of the constrained point is not so
> obvious.

You want a type for specification of a point within a unit circle.
Is this really hard to comprehend:

type Unit_Radius_Type is digits 15 range 0.0..1.0;
type Angle is digits 15 range 0.0..2.0 * Pi;

type Circular_Point is record
   X     : Unit_Radius_Type;
   Theta : Angle;
end record;

Given any unit circle with a known center coordinate, all
points can be designated within 15 digits of accuracy.

Please demonstrate how you would use C++ templates to
create an equivalent definition. I am most curious about the
range-specified and precision-specified floating point types.

Jim Rogers

Erasing inappropriate operations (was: why learn C?)

[Ludovic Brenta]

Randy Brukardt:
> the Amendment fixed the most important problem in Ada 95:
> the inability to "erase" an inappropriate operation from a unit type
> package.

Could you please explain what you mean by this? A quick perusal of the
Ada 2005 rationale failed to enlighten me.

--
Ludovic Brenta.

Re: Erasing inappropriate operations (was: why learn C?)

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message
news:1175604129.583861.40720@q75g2000hsh.googlegroups.com...
> Randy Brukardt:
> > the Amendment fixed the most important problem in Ada 95:
> > the inability to "erase" an inappropriate operation from a unit type
> > package.
>
> Could you please explain what you mean by this? A quick perusal of the
> Ada 2005 rationale failed to enlighten me.

In Ada 95, abstract operators of untagged types are considered in
resolution. So, you still might call them;then get an error message. That is
especially problematical if an appropriate operator is defined somewhere
else, because the expression might be ambiguous. (It's also a problem with
literals).

The Amendment 1 changed that so that they do not participate in resolution.
Thus, they no longer clog up resolution.

For instance, if you had:

     type F1 is digits 3;
     type F2 is digits 3;
     function "*" (Left : F1, Right : F2) return F2;
     function "*" (Left, Right : F2) return F2 is abstract; -- Don't want
this operator.

     A : F1 := 1.0;
     B : F2 := A * 1.0; -- (1)

The expression (1) is ambiguous in Ada 95 (even though one of the possible
operators is illegal). But Amendment 1 makes it OK; you'll get the intended
operator without interference from the predefined ones you don't want.

                                 Randy.

Re: Erasing inappropriate operations

[Ludovic Brenta]

Randy Brukardt writes:
> In Ada 95, abstract operators of untagged types are considered in
> resolution. So, you still might call them;then get an error message. That is
> especially problematical if an appropriate operator is defined somewhere
> else, because the expression might be ambiguous. (It's also a problem with
> literals).
> 
> The Amendment 1 changed that so that they do not participate in resolution.
> Thus, they no longer clog up resolution.
> 
> For instance, if you had:
>
>      type F1 is digits 3;
>      type F2 is digits 3;
>      function "*" (Left : F1, Right : F2) return F2;
>      function "*" (Left, Right : F2) return F2 is abstract; -- Don't want
> this operator.
>
>      A : F1 := 1.0;
>      B : F2 := A * 1.0; -- (1)
>
> The expression (1) is ambiguous in Ada 95 (even though one of the possible
> operators is illegal). But Amendment 1 makes it OK; you'll get the intended
> operator without interference from the predefined ones you don't want.

Even in Ada 95 mode, GNAT does not consider (1) to be ambiguous
because only one of the operators matches the actual parameter
profile.  Is this a bug?

In the absence of the first (non-abstract) operator, it says "cannot
call abstract subprogram".  Fair enough, I still see no bug here.

Or perhaps you meant...

with Ada.Text_IO;
procedure Proc1 is
   type F1 is digits 3;
   type F2 is digits 3;
   function "*" (Left : F1; Right : F2) return F2;
   function "*" (Left, Right : F2) return F2
     is abstract; -- Don't want this operator.

   function "*" (Left : F1; Right : F2) return F2 is
   begin
      Ada.Text_IO.Put_Line ("* called");
      return F2 (Float (Left) * Float (Right));
   end "*";

   A : F1 := 1.0;
   B : F2 := 1.0 * F2 (A); -- (1)
begin
   null;
end Proc1;

which gives me:

gcc-4.1 -c -gnatwa -gnat95 proc1.adb
proc1.adb:15:18: ambiguous expression (cannot resolve "*")
proc1.adb:15:18: possible interpretation at line 6
proc1.adb:15:18: possible interpretation at line 5

The abstract subprogram is indeed considered in overload resolution.
But since the resolution fails (the call is ambiguous), there is still
no way to call the abstract subprogram.  So if I understand correctly,
in Amendment 1, the call is no longer ambiguous and the first operator
is called.  Correct?

-- 
Ludovic Brenta.

Re: why learn C?

[jayessay]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> "kevin  cline" <kevin.cline@gmail.com> writes:
> 
> > On Mar 30, 4:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Fri, 30 Mar 2007 07:44:31 +0000 (UTC), Lutz Donnerhacke wrote:
> >> > * kevin  cline wrote:
> >> >> "The big difference is that C++ templates allow type checking during
> >> >> compile-time, so that no overhead neither in memory space nor in
> >> >> runtime is incurred. In this respect, C++ templates ARE MORE POWERFUL
> >> >> than Ada generics."
> >>
> >> > This is correct. C++-Templates itself are a Lisp dialect and Turing complete.

<delurk, in order to correct this nonsense>

This is only half correct and totally misleading.  C++ templates,
other than being Turing complete, have absolutely nothing to do with
Lisp or Lisp like languages.  Nothing.  And to think otherwise shows a
complete ignorance of the matter.  This poster probably saw someone
somewhere claim that templates are "like" Lisp macros because they are
a (very weak) example of metaprogramming.


> >> One should be careful with such statements. In fact it is apples and
> >> oranges, because whatever power templates might have, they are *not*
> >> executed on the target machine.
> >
> > So what?  The discussion was about compile-time type safety, and the
> > point is that C++ templates, being Turing complete, allow more
> > thorough compile type checking than is possible in Ada.
> 
> I fail to see what the one has to do with the other.

They _can_ be related, but in general are not.  An example of how
something like this might be useful can be seen in this (admittedly
artificial) example:

Allow a user/programmer to define a dictionary like object while
ensuring at _compile_ time that the size of the table implementing it
is a prime number.

That's something that is easy to do in Lisp.  It is at least
theoretically possible (if mind numbingly painful) to achieve with C++
templates.  I don't think you can achieve this with Ada without
writing some sort of external preprocessor.  If you can, it would be
neat to see.


> Indeed, I'd rather not write my own type checker in a lispish
> compile time language.

That wouldn't be so bad (or even such a big deal), but C++ templates
are nothing like this and are in general a clumsy giant PITA.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: Erasing inappropriate operations

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message
news:87vegcfsh1.fsf@ludovic-brenta.org...
> Randy Brukardt writes:
...
> The abstract subprogram is indeed considered in overload resolution.
> But since the resolution fails (the call is ambiguous), there is still
> no way to call the abstract subprogram.  So if I understand correctly,
> in Amendment 1, the call is no longer ambiguous and the first operator
> is called.  Correct?

Correct. It's not legal to call the abstract subprogram, but because it is
considered in expression resolution, the mere fact that it exists can make
some expressions that otherwise be legal illegal. That is a significant
problem for unit types, because you generally don't want the predefined
multiply and divide routines (that is meters * meters = meters is wrong).

I think you are correct that my example was wrong; I wrote it bunch of times
and kept finding problems (and didn't want to waste all afternoon trying to
figure it out). I think I meant:
   B : F1 := A * 1.0;
No, that isn't right either. Anyway, I wanted an example without a type
conversion (because if you're trying to do units checking, you're not going
to be converting seconds to meters). They're certainly possible, I just had
trouble coming up with an example.

                                       Randy.

Re: why learn C?

[Hyman Rosen]

jayessay wrote:
> C++ templates, other than being Turing complete, have absolutely nothing
 > to do with Lisp or Lisp like languages.  Nothing.  And to think otherwise
 > shows a complete ignorance of the matter.

Sorry, I'm afraid you're wrong about that. In fact, many C++ template
metaprograms use techniques that would be quite familiar to Lisp users.
For example, one might build up type lists as follows:

struct Nil { };
template <typename T1, typename T2 = Nil>
struct Cons { typedef T1 Car; typedef T2 Cdr; };

typedef Cons<int, Cons<bool, Cons<float> > > my3types;
my3types::Car an_int;
my3types::Cdr::Car a_bool;
my3types::Cdr::Cdr::Car a_float;

> Allow a user/programmer to define a dictionary like object while
> ensuring at _compile_ time that the size of the table implementing it
> is a prime number.
> 
> That's something that is easy to do in Lisp.  It is at least
> theoretically possible (if mind numbingly painful) to achieve with C++
> templates.

It's actually quite easy with templates, although the following may
hit compiler limits that a better algorithm would avoid. It takes
just three lines to implement straightforwardly the definition that
a prime number has exactly two divisors.

template<int N, int K> struct divNleK { enum { v = ((N % K) == 0) + divNleK<N,K-1>::v }; };
template<int N> struct divNleK<N, 1>  { enum { v = 1 }; };
template<int N> struct prime_test     { enum { v = divNleK<N,N>::v == 2 }; };

> That wouldn't be so bad (or even such a big deal), but C++ templates
> are nothing like this and are in general a clumsy giant PITA.

I don't agree at all.

Re: why learn C?

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> jayessay wrote:
> > C++ templates, other than being Turing complete, have absolutely nothing
>  > to do with Lisp or Lisp like languages.  Nothing.  And to think otherwise
>  > shows a complete ignorance of the matter.
> 
> Sorry, I'm afraid you're wrong about that. In fact, many C++ template
> metaprograms use techniques that would be quite familiar to Lisp users.

Again, this is just wrong.  I've tried to explain this before, but it
is a hard slog if you don't really know or use Lisp in anger.  Really,
there is nothing about templates that is remotely "lisp like".

> For example, one might build up type lists as follows:
> 
> struct Nil { };
> template <typename T1, typename T2 = Nil>
> struct Cons { typedef T1 Car; typedef T2 Cdr; };
> 
> typedef Cons<int, Cons<bool, Cons<float> > > my3types;
> my3types::Car an_int;
> my3types::Cdr::Car a_bool;
> my3types::Cdr::Cdr::Car a_float;

Please.  You are embarassing yourself with this.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[Hyman Rosen]

jayessay wrote:
> Please.  You are embarassing yourself with this.

I notice you have no comment on the lack of mind-numbingness
in my C++ template primality tester. Given that you're wrong
about C++, I have no trouble believing that you're wrong about
Lisp as well.

Re: why learn C?

[Ray Blaak]

Hyman Rosen <hyrosen@mail.com> writes:

> jayessay wrote:
> > Please.  You are embarassing yourself with this.
> 
> I notice you have no comment on the lack of mind-numbingness
> in my C++ template primality tester. Given that you're wrong
> about C++, I have no trouble believing that you're wrong about
> Lisp as well.

This is getting stupid. Jon probably knows both C++ templates and definitely
knows Lisp quite well.

The fact that you can code up a Car/Cdr abstraction in some programming
notation does note make it lisp like. You can code these list abstractions in
any language you choose, and that does not make a lisp.

What makes something a Lisp is a whole philosophy of symbolic, dynamic and
introspective (and protected!) programming that C++ simply is not natively
capable of. Also, Lisp's list syntax notation is also critical (Dylan be
damned!), as that syntax is what allows the whole "programs as data" paradigm
to practically work.

Your basic point that C++ templates need not be considered as a fundamental
evil is properly taken. In fact C++ in general tends to get a bad rap in
c.l.a. The simple fact of the matter is that a professional programmer worth
their salt should know how to use C++ properly so as to readily and easily
avoid its stupidities and program safely.

However, even with your demonstration of some cool templates, it is still the
case that "programming" like this with templates is fundamentally strange. One
has to think very differently compared to the usual programming languages.

More importantly, the need to program like this in templates I have strong
doubts about. If you really want to test a prime, for example, why on earth
would you not do so at run time, when you actually need the value? Even if
it's for a constant, you can compute it lazily, or during initialization,
making it externally read only, etc. That is a much much clearer and
understandable way to present things.

The proper way to program at compile time should be with traditional program
statements that happen to run in the "build" phase. This is much more direct
and clearer to understand. I note that you can actually do that with
Lisp/Scheme.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: why learn C?

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Hyman Rosen <hyrosen@mail.com> writes:
>
>> jayessay wrote:
>> > Please.  You are embarassing yourself with this.
>> 
>> I notice you have no comment on the lack of mind-numbingness
>> in my C++ template primality tester. Given that you're wrong
>> about C++, I have no trouble believing that you're wrong about
>> Lisp as well.
>
> This is getting stupid. Jon probably knows both C++ templates and definitely
> knows Lisp quite well.
>
> The fact that you can code up a Car/Cdr abstraction in some programming
> notation does note make it lisp like. You can code these list abstractions in
> any language you choose, and that does not make a lisp.

Not to defend Hyman (who in the past was rather quick to call me
"confused" when I discussed differences of C++ Templates vs. Ada
generics and the consequences as I see them -- and yes, I'm sometimes
a bit vengeful), but:

Hymans point here was, I think that the list expressions are evaluated
during compile time. Personally _I_ do not see the need for something
like this (if I want to dabble in new type systems I write a compiler
from an extended to the target language or I use something like Qi
where even type checking is user programmable), but from that Hyman
argues that Templates are "more powerful". Others denied this (the
premise that Template expressions are "like Lisp") , so he brought
this example.

I have to admit that I didn't check Hymans example and it's
limitations and I don't now templates well enough to do so in 2
minutes (and don't want to spent more time in anothe C++ vs. Ada
thread -- the weather is too beautiful today), but it seemd to me that
you have been missing the point that was made here. Is that possible?

> What makes something a Lisp is a whole philosophy of symbolic, dynamic and
> introspective (and protected!) programming that C++ simply is not natively
> capable of. Also, Lisp's list syntax notation is also critical (Dylan be
> damned!), as that syntax is what allows the whole "programs as data" paradigm
> to practically work.

I completely agree with that, though.

Regards -- Markus

PS: Perhaps this post was completely besides your point. I'm not
    sure. If so, please don't feel offended :-).

    

Re: why learn C?

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> jayessay wrote:
> > Please.  You are embarassing yourself with this.
> 
> I notice you have no comment on the lack of mind-numbingness
> in my C++ template primality tester.  Given that you're wrong
> about C++, I have no trouble believing that you're wrong about
> Lisp as well.

Ah, irrelevant non argument.  Believe what you wish - just don't
expect it to be close to reality.  Oh, and your "primality tester"
doesn't implement what I mentioned (though, as I say, I know it can be
done), so why should I comment on it?


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[jayessay]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
> > jayessay wrote:
> > > Please.  You are embarassing yourself with this.
> > 
> > I notice you have no comment on the lack of mind-numbingness
> > in my C++ template primality tester. Given that you're wrong
> > about C++, I have no trouble believing that you're wrong about
> > Lisp as well.
> 
> This is getting stupid. Jon probably knows both C++ templates and definitely
> knows Lisp quite well.
> 
> The fact that you can code up a Car/Cdr abstraction in some programming
> notation does note make it lisp like. You can code these list abstractions in
> any language you choose, and that does not make a lisp.

Exactly.  One wonders why that's hard to understand.


> What makes something a Lisp is a whole philosophy of symbolic,
> dynamic and introspective (and protected!) programming that C++
> simply is not natively capable of. Also, Lisp's list syntax notation
> is also critical (Dylan be damned!), as that syntax is what allows
> the whole "programs as data" paradigm to practically work.

Again, on the mark.


> Your basic point that C++ templates need not be considered as a
> fundamental evil is properly taken. In fact C++ in general tends to
> get a bad rap in c.l.a. The simple fact of the matter is that a
> professional programmer worth their salt should know how to use C++
> properly so as to readily and easily avoid its stupidities and
> program safely.

I agree with this also.


> would you not do so at run time, when you actually need the value? Even if
> it's for a constant, you can compute it lazily, or during initialization,
> making it externally read only, etc. That is a much much clearer and
> understandable way to present things.

Yes, as I stated, the example was artificial (and silly).


> The proper way to program at compile time should be with traditional
> program statements that happen to run in the "build" phase. This is
> much more direct and clearer to understand. I note that you can
> actually do that with Lisp/Scheme.

Yes.  Quite.  No "preprocessor" nonsense needed or wanted.  Also no
"funny weird extra little language" (aka templates) needed or wanted
either.  Full language, libs, external environment (databases,
networking, etc.) available at all phases for metaprogramming.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[Hyman Rosen]

jayessay wrote:
> Also no "funny weird extra little language" (aka templates)
 > needed or wanted either.

How odd. If I may quote from Abelson & Sussman, found here on the web,
<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>,

     "Metalinguistic abstraction -- establishing new languages -- plays
      an important role in all branches of engineering design. It is
      particularly important to computer programming, because in
      programming not only can we formulate new languages but we can also
      implement these languages by constructing evaluators ...

      We come to see ourselves as designers of languages, rather than only
      users of languages designed by others."

So again, I may believe some of the most respected names in the Lisp
pantheon, or I can believe you. Gee, let me think.

Re: why learn C?

[Hyman Rosen]

Ray Blaak wrote:
> it is still the case that "programming" like this with templates
 > is fundamentally strange. One has to think very differently compared
 > to the usual programming languages.

It is a declarative style involving immutable objects and pattern
matching. I understand that this is similar to the way functional
programming languages work in some respects. Thinking differently
isn't necessarily a flaw, either.

> If you really want to test a prime, for example, why on earth
> would you not do so at run time, when you actually need the value?

Because in C++, these values direct the compiler into different
code-generation pathways, allowing the generation of code that is as
efficient as if plain constants had appeared in the code. This is
generative programming, as expounded by Czarnecki & Eisenecker.

> The proper way to program at compile time should be with traditional
 > program statements that happen to run in the "build" phase.

C++ happened to find itself in a position where compile-time programming
became possible through a happy accident, and that has led to where it
is today. There are people working on more straightforward approaches to
this, and if they work out, they may make it into C++.

Re: why learn C?

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> jayessay wrote:
> > Also no "funny weird extra little language" (aka templates)
>  > needed or wanted either.
> 
> How odd. If I may quote from Abelson & Sussman, found here on the web,
> <http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>,

Nice quote, but totally irrelevant.

> So again, I may believe some of the most respected names in the Lisp
> pantheon, or I can believe you. Gee, let me think.

Let me think - you can stop making category errors.  Sheesh!


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> Ray Blaak wrote:
> > it is still the case that "programming" like this with templates
>  > is fundamentally strange. One has to think very differently compared
>  > to the usual programming languages.
> 
> It is a declarative style involving immutable objects and pattern
> matching. I understand that this is similar to the way functional
> programming languages work in some respects. Thinking differently
> isn't necessarily a flaw, either.

Declarative isn't the same as functional.  But even if it were, what's
the point?  I'm not sure, but I believe Ray's point was that using a
limited type language to do general computation is, shall we say,
convoluted.


> > If you really want to test a prime, for example, why on earth
> > would you not do so at run time, when you actually need the value?
> 
> Because in C++, these values direct the compiler into different

Yes, but really - as Ray points out this is a silly artificial example.


> is today. There are people working on more straightforward
> approaches to this, and if they work out, they may make it into C++.

Ah - even more Greenspunning.  *sigh*


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[jayessay]

Hyman Rosen <hyrosen@mail.com> writes:

> jayessay wrote:
> > Also no "funny weird extra little language" (aka templates)
>  > needed or wanted either.
> 
> How odd. If I may quote from Abelson & Sussman, found here on the web,
> <http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>,
> 
>      "Metalinguistic abstraction -- establishing new languages -- plays
>       an important role in all branches of engineering design. It is
>       particularly important to computer programming, because in
>       programming not only can we formulate new languages but we can also
>       implement these languages by constructing evaluators ...
> 
>       We come to see ourselves as designers of languages, rather than only
>       users of languages designed by others."

Oh, just so you might understand what he actually means by this: he
is, in general, talking about building domain specific languages.  You
build the _language_ up to the specific problem space.

More particularly in this context, the idea is to use "programmable
programming languages" to do this, i.e., to extend them _within
themselves_ to have the DSL.  This is connected to the last point Ray
made.

Really, I don't know why you are going on here.  From past postings, I
would say you are in general a fairly savy guy, but it's pretty clear
you don't have even a clue about this stuff.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[Ray Blaak]

jayessay <nospam@foo.com> writes:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
> > Ray Blaak wrote:
> > > it is still the case that "programming" like this with templates
> >  > is fundamentally strange. One has to think very differently compared
> >  > to the usual programming languages.
> > 
> > It is a declarative style involving immutable objects and pattern
> > matching. I understand that this is similar to the way functional
> > programming languages work in some respects. Thinking differently
> > isn't necessarily a flaw, either.
> 
> Declarative isn't the same as functional.  But even if it were, what's
> the point?  I'm not sure, but I believe Ray's point was that using a
> limited type language to do general computation is, shall we say,
> convoluted.

Right. I have no problem with declarative programming.

C++ template programming, however, achieves its ends as a "fortunate"
accidental side effect.

If the purpose is to do compile time computation, then the language should be
designed to be clear and understandable for that purpose, whether declarative
or functaional.

Note I am not saying that C++ templates are in themselves confusing for their
original purpose of parametized code generation (although they can be
justifiably criticized), but only that their application to the purpose of
compile time computation is confusing.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: why learn C?

[Ray Blaak]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> Hymans point here was, I think that the list expressions are evaluated
> during compile time. 

Sure, his example shows that, but 
a) list expressions don't make a lisp
b) template programming for compile time computations are a convoluted way of
achieving compile time computations.

> PS: Perhaps this post was completely besides your point. I'm not
>     sure. If so, please don't feel offended :-).

Given usenet, I could only be offended if you are *too* polite :-).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: why learn C?

[jayessay]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
> > Hymans point here was, I think that the list expressions are evaluated
> > during compile time. 
> 
> Sure, his example shows that, but 
>
> a) list expressions don't make a lisp
> b) template programming for compile time computations are a
> convoluted way of achieving compile time computations.

Couldn't have said it better.  Succinct and exact.


> > PS: Perhaps this post was completely besides your point. I'm not
> >     sure. If so, please don't feel offended :-).
> 
> Given usenet, I could only be offended if you are *too* polite :-).

It is indeed extremely difficult to not trip up on usenet and somehow
step on someone's toes without the slightest intent or knowledge of
it.  This is a big reason why I try not to post to usenet anymore.
Another problem involves individuals (such as exhibited in this
subthread) who appear more interested in scoring some "debating"
points in some sort of weird zero-sum game they are imagining than
furthering understanding or even accepting simple facts.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[jayessay]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> 
> from an extended to the target language or I use something like Qi
                                                                  ^^

A very interesting and impressive system.  Mark Tarver is a very
clever guy.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[Markus E Leypold]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>> Hymans point here was, I think that the list expressions are evaluated
>> during compile time. 
>
> Sure, his example shows that, but 

> a) list expressions don't make a lisp

I got that point later in your post. Therefore the postscript :-).

> b) template programming for compile time computations are a
> convoluted way of achieving compile time computations.

I completely agree with that. I even was on the verge of writing that
macros and pre processors are always evil and that I think it would be
better that people wrote domain specific languages as external
translators to their favorite target language. Then you post reminded
me that the Lisp macros are quit succesfull and don't seem to be the
problem I always experienced with macro languages. Still I have a bad
feeling with macros: They are a really big temptation to misuse
them. I'm not sure wether that isn't the feature that makes me really
mistrust Lisp and Scheme.

>> PS: Perhaps this post was completely besides your point. I'm not
>>     sure. If so, please don't feel offended :-).
>
> Given usenet, I could only be offended if you are *too* polite :-).

:-).

Regards -- Markus

Re: why learn C?

[jayessay]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> translators to their favorite target language. Then you post reminded
> me that the Lisp macros are quit succesfull and don't seem to be the
> problem I always experienced with macro languages.

The primary thing to realize here about this point is that Lisp
"macros" are not anything like the typical notion of macros from
pretty much any<where/thing> else.  They are not text substituters or
code templates, or code parameterizers, etc.  They are functions
which, like any other function, can make use of the entire language
(including the compiler and evaluator - which are part of the language
definition), any libs, external environment (databases, distributed
objects (via corba or other IDL/sockets), whatever), etc.

The difference is that they are 1) called at a special time (macro
expansion time - which most typically occurs during compile time), 2)
they are invoked with their arguments _un_evaluated (this is a big
part of why they can be so useful in creating new language level
constructs), and 3) they can be passed the current lexical environment
(this last was not properly fleshed out in the ANSI spec, but Franz
has done a very nice job of doing that and providing the spec and
implementation to the community).

Because of this, things like external "preprocessing" become empty and
irrelevant concepts.  It also means you can build layered families of
seamlessly interconnected domain level languages.

> Still I have a bad feeling with macros: They are a really big
> temptation to misuse them.

I would substitute "possibility" for "really big temptation".  Just
like for unchecked conversion, goto, and OOP.  Of course, YMMV.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com

Re: why learn C?

[Hyman Rosen]

adaworks@sbcglobal.net wrote:
> This tends to increase, not decrease, the dependability since each
 > instantiation is checked at compile-time.

Every C++ template instantiation is done, and therefore checked,
at compile-time. It's Ada that has run-time instantiation (with
compile-time checking).

>>           Time end = integrate_until(f1 * phase_shift(f2,start) / f3 + f4, q);
>>           even though f1, f2, f3, and f4 were possibly of different types.
> In fact, your acknowledgement of the "different types" is quite telling.

Telling of what? Automatic instantiation lets generic functions come
into being as programs use them.

> Further, the ad hoc pointer is potentially problematic.

What pointer? I see no pointer in this code.

> A similar construct in Ada, using an access to a function, requires the
 > function to be type conformant and parameter conformant prior to being
 > incorporated into the construct.

The C++ code has no pointers at all. The automatic instantiation done by
the C++ template mechanism is similar in its goals to Ada's operator
overloading. A universe of candidate functions is searched through a rules
system that picks one best choice or reports an error.

> However, typedef does not provide the level of type safety one would
 > expect in a corresponding Ada program.

Typedef merely creates a synonym for a type, another name by which that
type is known. It cannot increase or decrease safety in any way, although
it may increase abstraction.

Re: why learn C?

[Hyman Rosen]

jimmaureenrogers@worldnet.att.net wrote:
> I discovered that C++ template language does not allow the
> specification of a floating point value as a template parameter.

In C++, instantiations are considered the same if their
parameters are the same, and the standards committee did
not want the burden of defining T<3.0*(1.0/3.0)> vis a vis
T<1.0>.

> one cannot write a C++ template to handle range-specified
 > floating point classes.

Of course this is wrong. Every floating point number that you
write in a program is in fact a rational number, and therefore
depending on the purpose those numbers will have in the template,
they be represented using small sets of integers in a variety of
ways. The template itself can then assemble these parts into a
floating-point constant and use it. Or if that's too burdensome,
references to floating-point variables are permitted, so getting
what you want looks rather like Ada generic instantiation.

> But you cannot write a template equivalent to:
> type Voltage_Type is digits 11 range -5.0..5.0;

Using the variable reference approach, we can do

template <typename T, int digits, T const &lo, T const &hi> class FloatRange;
extern double const vtlo = -5.0;
extern double const vthi =  5.0;
typedef FloatRange<double, 11, vtlo, vthi> Voltage_Type;

Re: why learn C?

[Hyman Rosen]

Brian May wrote:
> - having a language where the compiler tries to guess what you meant

Then why does Ada have operator overloading?

Ada's generic model is different from C++ templates.
Automatic instantiation is a much less comfortable fit
in Ada for language design reasons, not safety reasons.
That's largely because C++ types are static compile-time
things, while Ada types are dynamic runtime things.

Re: why learn C?

[Hyman Rosen]

Georg Bauhaus wrote:
> And then, unfortunately, C++ doesn't have dynamic types
> (unless I'm missing something):
> 
> template <int left>
> int foo(int n)
> {
>   typedef class RangedInt<left, n> Int;

You are correct that C++ does not support this, but
incorrect that it is unfortunate. The purely static
types of C++ is what permits automatic instantiation
to work. Having dynamic types is what leads to Ada's
requirement of explicit instantiation.

Re: why learn C?

[Markus E Leypold]

Hyman Rosen <hyrosen@mail.com> writes:

> jimmaureenrogers@worldnet.att.net wrote:
>> I discovered that C++ template language does not allow the
>> specification of a floating point value as a template parameter.
>
> In C++, instantiations are considered the same if their
> parameters are the same, and the standards committee did
> not want the burden of defining T<3.0*(1.0/3.0)> vis a vis
> T<1.0>.

We have been through that discussion before. IMHO that this decision
was even necessarry indicates (in my eyes) the inferiority of the
automatic instantion approach. In C++ the "identity" of an instance
needs to be determined by the parameters. In Ada (and many other
languages with functors) by the act of instantiation.

>
>> one cannot write a C++ template to handle range-specified
>  > floating point classes.
>
> Of course this is wrong. Every floating point number that you
> write in a program is in fact a rational number, and therefore
> depending on the purpose those numbers will have in the template,
> they be represented using small sets of integers in a variety of
> ways. The template itself can then assemble these parts into a
> floating-point constant and use it. Or if that's too burdensome,
> references to floating-point variables are permitted, so getting
> what you want looks rather like Ada generic instantiation.

Groan. How ugly.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

Hyman Rosen <hyrosen@mail.com> writes:

> That's largely because C++ types are static compile-time
> things, while Ada types are dynamic runtime things.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How so? That is indeed news to me.

Regards -- Markus

Re: why learn C?

[Hyman Rosen]

kevin cline wrote:
> Preprocessor macros are quite out of fashion for C++ programming.

Unfortunately so. They're good for quite a bit of things,
especially when you want to code a little "database" table
of properties to be "queried" for the implementation.

#define QuotesTableData(IMPL) \
	IMPL(stock, "Security Name", string) \
	IMPL(date, "Quote Date", time_t) \
	IMPL(bid, "Bid Price", double) \
	IMPL(ask, "Ask Price", double)

struct QuotesTable {
	#define QuotesEnumImpl(name, title, type) name,
	enum { QuotesTableData(QuotesEnumImpl), N };
	#define QuotesMembersImpl(name, title, type) type m_##name;
	QuotesTableData(QuotesMembersImpl)
	#define QuotesPropertiesImpl(name, title, type) \
		type get_##name() const { return m_##name; } \
		void set_##name(const type &v) { m_##name = v; } \
		string title_##name() const { return title; }
	QuotesTableData(QuotesPropertiesImpl)
};

Re: why learn C?

[Dmitry A. Kazakov]

On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote:

> floating point number that you
> write in a program is in fact a rational number,

No, this is an incorrect statement. I can build hardware for floating-point
numbers with the radix e. These will not be rational numbers.

A correct statement is: the floating-point numbers are classes of
equivalence of real numbers. These classes are typically intervals and each
such interval contains a rational number.

But that alone, does not make the job of comparing classes of equivalence
much easier. Which is the reason why the notion of structural equivalence
(used by templates) is a can of worms.

> and therefore
> depending on the purpose those numbers will have in the template,
> they be represented using small sets of integers in a variety of
> ways. The template itself can then assemble these parts into a
> floating-point constant and use it.

Yes, but see above, you cannot tell which class of equivalence that
constant would denote. You cannot enumerate real numbers, so the approach
is fundamentally flawed. You need a type to identify the classes because
you have to know the delta and the radix when you compare "universal" real
literals.

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

Re: why learn C?

[Dmitry A. Kazakov]

On Thu, 12 Apr 2007 16:05:00 GMT, Hyman Rosen wrote:

> The purely static
> types of C++ is what permits automatic instantiation
> to work. Having dynamic types is what leads to Ada's
> requirement of explicit instantiation.

I would say that it is rather named (vs. structural) equivalence which
makes explicit instantiation necessary.

C++ has types algebra limited to compile-time only expressions. Is it good?
I don't think so. Does it imply a need in templates to evaluate some of
these expressions? I doubt it.

To me generics in a language merely indicate a lack of imagination of the
language designers.

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

Re: why learn C?

[Markus E Leypold]

Hyman Rosen <hyrosen@mail.com> writes:

> kevin cline wrote:
>> Preprocessor macros are quite out of fashion for C++ programming.
>
> Unfortunately so. They're good for quite a bit of things,
> especially when you want to code a little "database" table
> of properties to be "queried" for the implementation.
>
> #define QuotesTableData(IMPL) \
> 	IMPL(stock, "Security Name", string) \
> 	IMPL(date, "Quote Date", time_t) \
> 	IMPL(bid, "Bid Price", double) \
> 	IMPL(ask, "Ask Price", double)
>
> struct QuotesTable {
> 	#define QuotesEnumImpl(name, title, type) name,
> 	enum { QuotesTableData(QuotesEnumImpl), N };
> 	#define QuotesMembersImpl(name, title, type) type m_##name;
> 	QuotesTableData(QuotesMembersImpl)
> 	#define QuotesPropertiesImpl(name, title, type) \
> 		type get_##name() const { return m_##name; } \
> 		void set_##name(const type &v) { m_##name = v; } \
> 		string title_##name() const { return title; }
> 	QuotesTableData(QuotesPropertiesImpl)
> };


Without trying to understand ypur example in depth: This is -- of
course -- only necessary because C/C++ has no way to specify a
constant array (i.e. a "array literal").

Regards -- Markus

Re: why learn C?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

>...Having dynamic types is what leads to Ada's
> requirement of explicit instantiation.

I don't understand that.  Ada's types are entirely compile time, and
generic instantiation happens at compile time.  It is true that Ada's
subtypes can have dynamic constraints, and when you pass one to a
generic, there is some data stored at run time (array bounds or
whatever).  But I don't see any way in which that would prevent
me from designing an Ada-like language with implicit instantiation.

I think implicit instantiation is probably a good idea.  As you said in
another post, it's something like overloading of subprograms, and I
think it can be designed so that it's not too error prone.

If I remember, the C++ rules include preference rules, though.  Is that
correct?  Preference rules can cause Beaujolais effects, which in my
opinion are very bad.

- Bob

Re: why learn C?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> The C++ code has no pointers at all. The automatic instantiation done by
> the C++ template mechanism is similar in its goals to Ada's operator
> overloading. A universe of candidate functions is searched through a rules
> system that picks one best choice or reports an error.

Operator overloading is just one subset of subprogram overloading --
there's nothing special about operators, except they use a different
notation.  The same is true in C++, although C++ doesn't allow
top-down overload resolution, which is an annoying restriction.

- Bob

Re: why learn C?

[Dmitry A. Kazakov]

On Thu, 12 Apr 2007 22:54:02 +0200, Georg Bauhaus wrote:

> On Thu, 2007-04-12 at 18:39 +0200, Dmitry A. Kazakov wrote:
>> On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote:
>> 
>>> floating point number that you
>>> write in a program is in fact a rational number,
>> 
>> No, this is an incorrect statement. I can build hardware for floating-point
>> numbers with the radix e.
> 
> Will radix e hardware be digital hardware?

Why not? It is just about representation of numbers in the form

X = sum Xk e**k

That's computable.

Nothing requires us to have accurate rational numbers or any given number
in our system. I guess one could even have a system where 0 would be
represented by a non-periodic sequence of "digits". (:-))

http://en.wikipedia.org/wiki/Non-integer_representation
http://en.wikipedia.org/wiki/Golden_ratio_base

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

Re: why learn C?

[Dmitry A. Kazakov]

On Thu, 12 Apr 2007 23:40:47 +0200, Georg Bauhaus wrote:

> On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote:
>>  I can build hardware for floating-point
>>>> numbers with the radix e.
>>> 
>>> Will radix e hardware be digital hardware?
>> 
>> Why not? It is just about representation of numbers in the form
>> 
>> X = sum Xk e**k
>> 
>> That's computable.
> 
> Hm. Are you saying that e is computable using digital hardware
> in finite time?

Sure. Here it is: e.

The question is meaningless without specifying the language. In my language
e is computable, but 10 is probably not.

> Or that we interpret some discrete unit in the computer as
> a base named e?

Yes. Some computer states are associated with the variable x having the
value e. That is. It is no different from associating them x=0 or x=1.
Computer states are not numbers. We, humans, interpret them as numbers.

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

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-04-12 at 18:39 +0200, Dmitry A. Kazakov wrote:
> On Thu, 12 Apr 2007 15:47:36 GMT, Hyman Rosen wrote:
> 
> > floating point number that you
> > write in a program is in fact a rational number,
> 
> No, this is an incorrect statement. I can build hardware for floating-point
> numbers with the radix e.

Will radix e hardware be digital hardware?

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-04-12 at 16:05 +0000, Hyman Rosen wrote:
> Georg Bauhaus wrote:
> > And then, unfortunately, C++ doesn't have dynamic types
> > (unless I'm missing something):
> > 
> > template <int left>
> > int foo(int n)
> > {
> >   typedef class RangedInt<left, n> Int;
> 
> You are correct that C++ does not support this, but
> incorrect that it is unfortunate.

I beg to differ. When there are reasons not to support
this kind of nesting in C++, I still see nesting of things
including types as a feature of Ada that is valuable. Much
like local subprograms can act as a locally needed singleton
with suitably restricted visibility of its surroundings:
there is no need for a singleton at the service of a single
subprogram, say. But there are local packages, local types,
...,  and now inward closures.
  Is a std::unary_function so much more attractive for
the cases it can handle?

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote:
>  I can build hardware for floating-point
> >> numbers with the radix e.
> > 
> > Will radix e hardware be digital hardware?
> 
> Why not? It is just about representation of numbers in the form
> 
> X = sum Xk e**k
> 
> That's computable.

Hm. Are you saying that e is computable using digital hardware
in finite time?
Or that we interpret some discrete unit in the computer as
a base named e?

Re: why learn C?

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Thu, 2007-04-12 at 22:33 +0200, Dmitry A. Kazakov wrote:
>>  I can build hardware for floating-point
>> >> numbers with the radix e.
>> > 
>> > Will radix e hardware be digital hardware?
>> 
>> Why not? It is just about representation of numbers in the form
>> 
>> X = sum Xk e**k
>> 
>> That's computable.
>
> Hm. Are you saying that e is computable using digital hardware
> in finite time?

As much as I disklike Dmitry's disgressions in the obscure and
wonderful: But here he is right: A real number representation
  
  (X_n, ... X_0 ..., X_u) means X = sum X_k e**k

has a well defined meaning and those number representations can be
manipulated in finite time by some algorithm (hard or software) that
the operation corresponds to multiplication or addition.

The representations are just a bit long -- but so are those handled by
arbitrary precision libraries like GMP. And of course it tedious to
convert those representations to "normal" floats and most natural
numbers have no (that is no finite representation) in that
system. Fortunately 'e' has a finite representation - '1'.

Regards -- Markus

Re: why learn C?

[Hyman Rosen]

Georg Bauhaus wrote:
> On Thu, 2007-04-12 at 16:05 +0000, Hyman Rosen wrote:
>> You are correct that C++ does not support this, but
>> incorrect that it is unfortunate.
> I beg to differ. When there are reasons not to support
> this kind of nesting in C++, I still see nesting of things
> including types as a feature of Ada that is valuable.

Oh, sure, it's immensely valuable. It just isn't C++. The
type system in C++ is completely static, and that deeply
affects the language, especially templates. I think that
it's essentially impossible to shoehorn a dynamic type
system into the language and still retain its qualities.

Re: why learn C?

[Hyman Rosen]

Robert A Duff wrote:
> Operator overloading is just one subset of subprogram overloading

Sure. I was just replying to the notion that manual instantiation is
better than automatic because it avoids having the compiler pick your
functions for you, pointing out that Ada already does that.

> C++ doesn't allow top-down overload resolution,
 > which is an annoying restriction.

Yep. But given all of the automatic type conversions that C++ allows,
most of the time you would wind up in ambiguity land anyway.

Re: why learn C?

[Hyman Rosen]

Robert A Duff wrote:
> But I don't see any way in which that would prevent
> me from designing an Ada-like language with implicit instantiation.

Yes, I think you're right. I'm thinking of what can be done with C++
template metaprogramming. That requires specialization and the ability
to distinguish between types based on their names and template parameters,
and I don't know if that can be fitted into the context of Ada where
subtypes and generic instantiations depend upon local context.

> If I remember, the C++ rules include preference rules, though.  Is that
> correct?  Preference rules can cause Beaujolais effects, which in my
> opinion are very bad.

Yes, preference rules abound. They're applied one parameter at a time,
though, which helps limit the confusion.

Re: why learn C?

[kevin cline]

On Apr 12, 11:18 am, Markus E Leypold
<development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
> Hyman Rosen <hyro...@mail.com> writes:
> > jimmaureenrog...@worldnet.att.net wrote:
> >> I discovered that C++ template language does not allow the
> >> specification of a floating point value as a template parameter.
>
> > In C++, instantiations are considered the same if their
> > parameters are the same, and the standards committee did
> > not want the burden of defining T<3.0*(1.0/3.0)> vis a vis
> > T<1.0>.
>
> We have been through that discussion before. IMHO that this decision
> was even necessarry indicates (in my eyes) the inferiority of the
> automatic instantion approach.

Automatic instantiation allows one to write very powerful libraries in
C++ that are impractical to implement in Ada.  For a good example, see
the SPIRIT parser library (http://www.boost.org/libs/spirit/
index.html).  So the choice can comes down to hundreds of lines of C++
or thousands of lines of Ada.

Re: why learn C?

[Georg Bauhaus]

On Thu, 2007-04-12 at 18:19 +0200, Markus E Leypold wrote:
> 
> Hyman Rosen <hyrosen@mail.com> writes:
> 
> > That's largely because C++ types are static compile-time
> > things, while Ada types are dynamic runtime things.
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> How so? That is indeed news to me.

In this sense:

    type P is tagged null record;
 
    procedure here(n: Positive) is
	subtype S is Positive range 1 .. n;
	type T is array (S range <>) of Character;
	type D is new P with record
	    item: T(1 .. n);
	end record;
    begin
	pragma assert(S'last = 42);
	null;
    end here;
    

Re: why learn C?

[jimmaureenrogers]

On Apr 12, 9:47 am, Hyman Rosen <hyro...@mail.com> wrote:
> jimmaureenrog...@worldnet.att.net wrote:
> > one cannot write a C++ template to handle range-specified
>
>  > floating point classes.
>
> Of course this is wrong. Every floating point number that you
> write in a program is in fact a rational number, and therefore
> depending on the purpose those numbers will have in the template,
> they be represented using small sets of integers in a variety of
> ways. The template itself can then assemble these parts into a
> floating-point constant and use it. Or if that's too burdensome,
> references to floating-point variables are permitted, so getting
> what you want looks rather like Ada generic instantiation.
>
> > But you cannot write a template equivalent to:
> > type Voltage_Type is digits 11 range -5.0..5.0;
>
> Using the variable reference approach, we can do
>
> template <typename T, int digits, T const &lo, T const &hi> class FloatRange;
> extern double const vtlo = -5.0;
> extern double const vthi =  5.0;
> typedef FloatRange<double, 11, vtlo, vthi> Voltage_Type;

Your example relies upon passing pre-defined constants for the
parameters
lo and hi. It also allows you to specify whatever type is aliased by
typename T. How does this template ensure that typename T is an alias
for
a floating point type? It appears that T could be instantiated with
any
type, including for instance the String type.

C++ template syntax provides no way to pass float or double literals
for the parameters lo and hi. It also provides no syntax to ensure
that
typename T is a floating point type. These deficiencies render your
example not equivalent to the Ada example. Furthermore, they are
weaknesses that are not a problem in the Ada generic formal parameter
syntax.

Jim Rogers

Re: why learn C?

[Georg Bauhaus]

On Fri, 2007-04-13 at 16:18 -0700, kevin cline wrote:

> Automatic instantiation allows one to write very powerful libraries in
> C++ that are impractical to implement in Ada.  For a good example, see
> the SPIRIT parser library (http://www.boost.org/libs/spirit/

You've said this in August 2004, and were given your example
written in the (technically more powerful) Spitbol pattern matcher
of GNAT. Same LOC.
 Are there new properties of Boost::spirit that have changed
the relation?

> index.html).  So the choice can comes down to hundreds of lines of C++
> or thousands of lines of Ada.

Try this:

template <int x> int more(int y) { return x + y; }

int main(void)
{
  int result = 0;
  for (int p = 0; p < 100; ++p) { result += more<p>(5); }
  return result;
}

Re: why learn C?

[Markus E Leypold]

"kevin  cline" <kevin.cline@gmail.com> writes:

> On Apr 12, 11:18 am, Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
>> Hyman Rosen <hyro...@mail.com> writes:
>> > jimmaureenrog...@worldnet.att.net wrote:
>> >> I discovered that C++ template language does not allow the
>> >> specification of a floating point value as a template parameter.
>>
>> > In C++, instantiations are considered the same if their
>> > parameters are the same, and the standards committee did
>> > not want the burden of defining T<3.0*(1.0/3.0)> vis a vis
>> > T<1.0>.
>>
>> We have been through that discussion before. IMHO that this decision
>> was even necessarry indicates (in my eyes) the inferiority of the
>> automatic instantion approach.
>
> Automatic instantiation allows one to write very powerful libraries in
> C++ that are impractical to implement in Ada.  For a good example, see
> the SPIRIT parser library (http://www.boost.org/libs/spirit/
> index.html).  So the choice can comes down to hundreds of lines of C++
> or thousands of lines of Ada.

[] You know what you're talking about?

And, BTW, even if it were so, I'm not sure wether I wouldn't go for
the longer, readable and perhaps more likely correct code instead of
code which is terse, "smart", unreadable and therefore unreviewable
and probably wrong. 

As much issue as I have with some of the culture surrounding Ada
(i.e. a kind of corral mentality with respect to a number of topics),
the language itself as written in the ARM isn't a problem.

The number of instantiations you're referring to can probably be kept
under control by using hierarchies of generics and instantiation the
whole hierarchy in one line (see e.g. the Booch components).

Regards -- Markus

Re: why learn C?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
>> Operator overloading is just one subset of subprogram overloading
>
> Sure. I was just replying to the notion that manual instantiation is
> better than automatic because it avoids having the compiler pick your
> functions for you, pointing out that Ada already does that.

Right.

Ada also has the "is <>" default notation for generic formal parameters,
which is a similar sort of "implicit / behind-the-scenes-magic".
It means "pick something with the same name, visible at the 
place of the instantiation".  Some might consider that rather error
prone, but it's also rather useful.  It probably wouldn't mix well
with implicit instantiation.

- Bob

Re: why learn C?

[Robert A Duff]

Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> As much as I disklike Dmitry's disgressions in the obscure and
> wonderful: 

I think they're fun, and in some cases, even instructive.  ;-)

>...But here he is right: 
>...

Yup.

- Bob

Re: why learn C?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc647ybnsl.fsf@shell01.TheWorld.com...
...
> Ada also has the "is <>" default notation for generic formal parameters,

Only for *some* kinds of formal parameters. It clearly would be useful to
have defaults for *all* kinds of formal parameters; it would reduce the
effort to create explicit instantiations a lot.

(Of course, the ARG didn't have the will for this idea; see AI95-00299.)

               Randy.

Re: why learn C?

[Hyman Rosen]

Markus E Leypold wrote:
> This is only necessary because C/C++ has no way to specify a
> constant array (i.e. a "array literal").

Not really. The preprocessor stuff is generating program code as
well as data. Think about "properties" - you need to code a getter,
a setter, a place to hold the value, a type, a descriptive string,
and so forth. The language syntax may not allow all of this to be
in one place, and that's where macros can come in handy.

Re: why learn C?

[Hyman Rosen]

Markus E Leypold wrote:
> the inferiority of the automatic instantion approach.
 > In C++ the "identity" of an instance needs to be determined
 > by the parameters. In Ada (and many other languages with
 > functors) by the act of instantiation.

But without the C++ way of identity, and without specialization,
the language cannot do template metaprogramming, as is impossible
in Ada. That's a trade-off I'll gladly make.

> Groan. How ugly.

Well, maybe they'll add it in one day. But, Lord knows, this isn't
the ugliest workaround that C++ requires.

Re: why learn C?

[Dmitry A. Kazakov]

On Sun, 15 Apr 2007 00:55:19 GMT, Hyman Rosen wrote:

> Markus E Leypold wrote:
>> This is only necessary because C/C++ has no way to specify a
>> constant array (i.e. a "array literal").
> 
> Not really. The preprocessor stuff is generating program code as
> well as data. Think about "properties" - you need to code a getter,
> a setter, a place to hold the value, a type, a descriptive string,
> and so forth. The language syntax may not allow all of this to be
> in one place, and that's where macros can come in handy.

If the language does not provide abstract member interface (primitive
operations for ".Foo") that is a deficiency.

I think that the idea of having tools (and meta programming) instead of
fixing the language is wrong. Surely there exist border cases used rarely,
which aren't worth the efforts. But getter/setter is IMO not among them.

In your example type is superfluous, it should be determinable from the
value. The value and the string would be a tuple used in the setter. For
tuples one would also need user-defined aggregates, otherwise the string
length discriminant of the tuple could not be evaluated from the string
value. Maybe anonymous record types..., anyway, I think that the sugar

   X.Foo := (1.35, "Blah");

is solvable in a statically typed language without preprocessing.

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

Re: why learn C?

[Simon Wright]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> The number of instantiations you're referring to can probably be
> kept under control by using hierarchies of generics and
> instantiation the whole hierarchy in one line (see e.g. the Booch
> components).

One line per level, you'll find!

Re: why learn C?

[Markus E Leypold]

Hyman Rosen <hyrosen@mail.com> writes:

> Markus E Leypold wrote:
>> This is only necessary because C/C++ has no way to specify a
>> constant array (i.e. a "array literal").
>
> Not really. The preprocessor stuff is generating program code as
> well as data. Think about "properties" - you need to code a getter,
> a setter, a place to hold the value, a type, a descriptive string,
> and so forth. The language syntax may not allow all of this to be
> in one place, and that's where macros can come in handy.

Oooh -- don't know. In reality I found that if I really abstract of
attributes of objects (or ADTs in general), the attribute has no 1:1
representation in the implementation. Getting and setting become
fundamentally different then: i'd have to implement them separately
anyway. And often I only want to export the attribute read-only
(indeed that is the often default in base classes anyway), so I don't
want to provide a setter. Some "setter functions" don't even make much
sense when setting a single attribute. 

So overall I found I can well forgo using the pre processor like this.

And custom syntax should anyway be used very sparingly and only if you
do something really different or new AND know what you're doing: Else
the program becomes quickly unreadable locally. And most people with a
pre processor at their finger tipps don't realize that they shouldn't
and -- well -- the results a regrettable.

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

Hyman Rosen <hyrosen@mail.com> writes:

> Markus E Leypold wrote:
>> the inferiority of the automatic instantion approach.
>  > In C++ the "identity" of an instance needs to be determined
>  > by the parameters. In Ada (and many other languages with
>  > functors) by the act of instantiation.
>
> But without the C++ way of identity, and without specialization,
> the language cannot do template metaprogramming, as is impossible
> in Ada. That's a trade-off I'll gladly make.

Me too. I'll gladly forgo "template metaprogramming" for explicit
instantition.

>> Groan. How ugly.
>
> Well, maybe they'll add it in one day. But, Lord knows, this isn't
> the ugliest workaround that C++ requires.

No. Which in itself speaks volumes. C++ is only a big workaround
(around the deficiencies of C when use how it wasn't designed: As a
high level language).

Regards -- Markus

Re: why learn C?

[Markus E Leypold]

Simon Wright <simon.j.wright@mac.com> writes:

> Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:
>
>> The number of instantiations you're referring to can probably be
>> kept under control by using hierarchies of generics and
>> instantiation the whole hierarchy in one line (see e.g. the Booch
>> components).
>
> One line per level, you'll find!

Yes. That does not make one line per instance, but interesting enough,
one line per different parameter. I find that acceptable. 

Regards -- Markus

Re: why learn C?

[Brian May]

>>>>> "adaworks" == adaworks  <adaworks@sbcglobal.net> writes:

    adaworks> Unlike the C family of languages, which are generally no
    adaworks> help at all, an Ada compiler frequently eliminates the
    adaworks> need for extensive debugging of silly errors; e.g., the
    adaworks> kind that originate from case-sensitivity, wrong order
    adaworks> of arguments to parameters, improper spacing, missing
    adaworks> curly-braces, and the plethora of language "features"
    adaworks> that plague those who have chosen to use any member of
    adaworks> the C family of languages.

    adaworks> It has always seemed rather odd to me that people who
    adaworks> are as intelligent as programmers, rarely question the
    adaworks> silliness of using tools such as C and C++ for serious
    adaworks> work.  They simply take for granted that the kind of
    adaworks> errors that are so common in those languages are somehow
    adaworks> akin to the laws of nature.  Java inherits many of those
    adaworks> same properties and is not much better.  It is taken as
    adaworks> an article of faith that programming involves heavy use
    adaworks> of debuggers.  Instead of asking why this is so, they
    adaworks> simply believe it is a fundamental law of programming --
    adaworks> mainly because the languages they have chosen make it
    adaworks> so.

I thought the following links were interesting.

http://www.mega-nerd.com/erikd/Blog/CodeHacking/autoconf_ifdef.html

http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html

"Rusty says the key criteria for an interface is how easy it is to use
correctly or (by Murphy's Law) how hard it is to misuse. He delineates
a spectrum from best to worst, which is so good I am going to
shamelessly reproduce it here:

    1. Compiler/linker won't let you get it wrong.

    2. Compiler will warn if you get it wrong.

    3. The simplest use is the correct one.

    4. The name tells you how to use it.

    5. Do it right or it will break at runtime.

    6. Follow common convention and you'll get it right.

    7. Read the documentation and you'll get it right.

    8. Read the implementation and you'll get it right.

    9. Read the correct mailing list thread and you'll get it right.

    10. Read the documentation and you'll get it wrong.

    11. Follow common convention and you'll get it wrong.

    12. Do it right and it will break at runtime.

    13. The name tells you how not to use it.

    14. The obvious use is wrong.

    15. Compiler will warn if you get it right.

    16. Compiler won't let you get it right.

    17. It's impossible to get right. "
-- 
Brian May <bam@snoopy.apana.org.au>

Re: why learn C?

[adaworks]

"Hyman Rosen" <hyrosen@mail.com> wrote in message 
news:_esTh.11650$eC.2533@trndny03...
> adaworks@sbcglobal.net wrote:
>> This tends to increase, not decrease, the dependability since each
> > instantiation is checked at compile-time.
>
> Every C++ template instantiation is done, and therefore checked,
> at compile-time. It's Ada that has run-time instantiation (with
> compile-time checking).
>
As you note, the checking is done at compile-time in Ada.

   generic
        type Num is range <>;
   package ...

When I instantiate Num with some actual type, the unit containing
that type has already been checked at compile time of the instantiation
will not compile.   The package being instantiated is using that type
instead of some phantom type.

I have looked at the C++ instantiation model and I find it confusing
and error-prone -- especially at the human level.  Several months
ago I had to go over it with a colleague who was trying to unravel
its complexity in a piece of code he inherited.   He finally got it, but
not without a lot of head-scratching.

To suggest that C++ is more dependable in its template model, or in
any other way, than Ada, is simply wrong -- or a strained interpretation
of the relative language designs.

Richard Riehle 

Re: why learn C?

[Gautier]

> "Hyman Rosen" <hyrosen@mail.com> wrote in message 
>> Every C++ template instantiation is done, and therefore checked,
>> at compile-time. It's Ada that has run-time instantiation (with
>> compile-time checking).

adaworks@sbcglobal.net wrote:

> As you note, the checking is done at compile-time in Ada.  [...]

By the way, Hyman's "It's Ada that has run-time instantiation" is misleading, 
since it could be interpreted that Ada instantiations are systematically done 
at run-time, which is wrong...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!