Teaching new tricks to an old dog (C++ -->Ada)

[Ioannis Vranos]

I am pretty sure one can write a library that can enable just that.


Now that I am thinking of it, there are some, and let's begin from Boost:


http://www.boost.org/libs/integer/integer.htm


#include <boost/integer.hpp>


int main()
{
using namespace boost;

int_t<24>::least my_var;
}



with "least" being the smallest built-in type that supports the given
bit count.



You see, that's easy. Just "plug in" Boost.


I am sure there are other libraries too.

Actually the Boost type that you are probably looking for is:


"uint_value_t: The smallest built-in unsigned integral type that
supports the given value as a maximum. The parameter should be a
positive number."


This is the equivalent of 0..whatever.


Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

 

[Ioannis Vranos]

Actually the Boost type that you are probably looking for is:


"uint_value_t: The smallest built-in unsigned integral type that
supports the given value as a maximum. The parameter should be a
positive number."

So the example becomes:

#include <boost/integer.hpp>


int main()
{
using namespace boost;

// Value range 0..16
uint_value_t<16>::least my_var;

my_var= 9;
}

This is the equivalent of 0..whatever.


Myself thinks though that this whole range specialisation thing is
non-sense for regular application programming at least.

Indeed.

 

[Georg Bauhaus]

But what of features not present in either?
[...]

associative arrays (from Perl)

Wouldn't that be std::map in C++?

and in Ada 2005,

Ada.Containers.Hashed_Maps and Ada.Containers.Hashed_Maps


Georg

 

[Simon Wright]

Google shows me lwlock as a C function in the PostGres support groups;
I don't know what machine architecture has these instructions? PowerPC?

It could be used by any compiler as part of a low-level
implementation, of course, but it's hardly likely that a C compiler
could use it off its own bat. Why whould it want to unless you the
programmer tells it to?

If you're talking about assembler inserts in C -- for Pete's sake, we
can insert assembler in Ada as a last resort if it's needed.

What happens with lwlock about priority inversion?

No protected type implementations will be so light. This is impossible as it
brings far more than atomic integer. For an atomic integer it is possible to
declare :

Value : Integer;
pragma Atomic (Value);

I don't think this will make

Value := Value + 1;

atomic, though!

 

[Martin Krischik]

Perhaps you should reread this, paying paritcular attention to the
dates involved. According to the paper, they started switching from C
to Ada around 1986. C wasn't standardized until 1989, and (as you'd
expect) it was some time after that before most compilers implemented
the standard language.

Did they? Or did they just implemented some 80% of the new features? My
experience with C/C++ (and I have 10 years + of that) is that at no time
there was a fully compiant C compiler available. There where allways a lot
of compiler avaliable who claimed to be <small>almost</small> complinant -
but never one which realy was.

Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
there is not official testsuite to test a C/C++ compiler and runtime
library. Such an official testsuite would do C/C++ all sorts of good.

By 1990 or so when compilers conforming reasonably closely with the C
standard became available, it appears likely that essentially all new
development was being done in Ada. Under the circumstances, it would be
rather surprising if the C code was ever rewritten into standard C.

On the last project I was working with a 3rd party library which had not a
single "const" in its header files - probably to be compatible with old
compilers. So a major "savety" feature of C89 was still missing in current
code - and affected our current development - since I has to use that
library.

In short, this is not a comparison to the C language as it exists
today, or has existed in well over a decade.

What do you mean by "exists today"? C99 is 5 years old and still no compiler
is available which support all C99 features. "restrict" - missing in MS-C
(even thrue restrict can be implemented as "no operation") - VA - arrays
(savety critical feature) - missing in MS-C, buggy in GCC.

The most compatible C/C++ compiler AFAIK is digital mars
(http://www.digitalmars.com) with "only" 4 C99 features missing:
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).

But even digital mars aims only at the C++98 and not the current C++ 2003.
And there are still 4 features missing:
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

If anything, based on my own experience with standard C vs.
pre-standard C, I'd say his study shows rather the opposite of what you
think it does. Standard C was enough of an improvement over
pre-standard C that it would be rather surprising if standard C didn't
beat Ada in most areas studied (the primary exception being code
reuse).

Maybe just maybe - if there realy was any standart compiler available - but
there isn't - the C/C++ compiler vendors are allways one release behind the
actual ISO standart.

By contrast, comparing modern C++ to the pre-standard C shows _large_
improvements in nearly all areas. This is due in part to the changes in
the language itself, but perhaps even more so to improved understanding
of how to use the language.

True - the former slim languages designed by individuals have become fad
languages desined by the ISO commitie ;-).

It is true that a programming language need some minimum features set to be
usefull. And that feature set is a lot larger then most belive. If a
successfull language does not provide that set it will be bolted on later.
If anything the current C/C++ ISO standards clearly show that the advocates
for slim languages hat been wrong all along.

Martin

 

[Peter Koch Larsen]

That's not what I mean. I mean I have a function foo that takes many
parameters. I can think of nothing beyond a contrived example:

void foo(int a= 1, int b = 2, int c = 3);

I usually try and determine which will change most often, and make that
the
first one, and on down the line. The is because if I need to define
parameter c in a call to foo, I need to define a and b also. In Ada I can
just say:

foo(c => 5);

I had one instance where I had many complex objects that took a lot of
constructor parameters. I ended up putting the parameters in related
groups, and making each group a struct, each with its own set of defaults
so
I would only have to define them if I cared about a particular group. I'm
sure there is probably a better design. I hope that was clear.

First off, I do not believe in procedures with many parameters. But if you
do want to use such a feature, look at boost, which lets you say e.g. foo(c
= 5) or foo(c = 4,a = 2). This is all outside the core language, relying on
some (vlever) template programming.

 

[Martin Krischik]

Aliasing?

There is this new "restrict" keyword in C99 - only MS-C does not support it
and so many 3rd party libraries won't use it and you can't use it (without
cast) because you need to use the library. It's a bit like the introduction
of const - only this time there is more legacy code and it will take even
longer until restrict is generaly accepted.

Martin

 

[Peter Koch Larsen]

Did they? Or did they just implemented some 80% of the new features? My
experience with C/C++ (and I have 10 years + of that) is that at no time
there was a fully compiant C compiler available. There where allways a lot
of compiler avaliable who claimed to be <small>almost</small> complinant -
but never one which realy was.

Partily because - unlike Ada (http://en.wikipedia.org/wiki/ISO_18009) -
there is not official testsuite to test a C/C++ compiler and runtime
library. Such an official testsuite would do C/C++ all sorts of good.

I do not believe that to be the problem. There is a standard and there are
commercial libraries out there to test conformance. The problem rather lies
in other areas such as:

- compiler vendors wanting to be backwards compatible.
- compiler vendors wanting to get a grip on their customers by ofering
"extensions" to the language.
- compiler vendors who don't care if their product is standards-compliant.

On the last project I was working with a 3rd party library which had not a
single "const" in its header files - probably to be compatible with old
compilers. So a major "savety" feature of C89 was still missing in current
code - and affected our current development - since I has to use that
library.

You could use another library out there. Cars are not bad just because one
manufacturer ships buggy cars out.

What do you mean by "exists today"? C99 is 5 years old and still no
compiler
is available which support all C99 features. "restrict" - missing in MS-C
(even thrue restrict can be implemented as "no operation") - VA - arrays
(savety critical feature) - missing in MS-C, buggy in GCC.

The most compatible C/C++ compiler AFAIK is digital mars
(http://www.digitalmars.com) with "only" 4 C99 features missing:
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#c_unimplemented).

But even digital mars aims only at the C++98 and not the current C++ 2003.
And there are still 4 features missing:
(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

Did you have a look at Comeau C++?

Maybe just maybe - if there realy was any standart compiler available -
but
there isn't - the C/C++ compiler vendors are allways one release behind
the
actual ISO standart.

If you look at C++ (i can't comment on C), all major vendors i know of have
a high level of compliance.

True - the former slim languages designed by individuals have become fad
languages desined by the ISO commitie ;-).

This is simply not true. The "ISO commitie" you refer to consists of people
using C++ in daily life.

It is true that a programming language need some minimum features set to
be
usefull. And that feature set is a lot larger then most belive. If a
successfull language does not provide that set it will be bolted on later.
If anything the current C/C++ ISO standards clearly show that the
advocates
for slim languages hat been wrong all along.

I have to disagree again. C/C++ has been most succesfull as a language if
you measure that by the number of applications written in that language.

/Peter

 

[Martin Krischik]

I do not know what you mean exactly by that, however one can define his
own types rather than having everything as built-in.

explicit typedef int My_Integer;

As you know "explicit" deactivates implicid type convertions. Sadly it can
only by applied to type convertion contructors and not to types itself.

See: http://en.wikibooks.org/wiki/Programming:Ada:Subtypes#Type_declaration

The other would be

explicit typdef int <1, 31> Day_Of_Month;

See: http://en.wikibooks.org/wiki/Programming:Ada:Types:range

C++ provides general purpose facilities with which one can build his own
special purpose libraries, rather than providing special purpose
facilities as built in.

Shure you can create a template for the problem above - but without the
"explicit typdef" you always have the problem of

template Range <int Min, int Max> class {....}

typedef Range <1, 12> Month_Of_Year;
typedef Range <1, 12> US_Hour;

I have 10+ years experience of C/C++ - I already know the little tricks you
could do to circumvent the problem above. It would be nicer without tricks.

From my (perhaps limited) experience of .NET where run-time generics
are also available to C++ (with the upcoming C++/CLI, .NET 2 and VC++
2005 - currently Beta), run-time generics are more limited than
compile-time templates. Also since they are run-time they are less
efficient.

I think they are more free:

template <int Size> Bounded_Array class {...};

void F (int size)
{
auto Bounded_Array <size> Data;
}

And yes: that works in Ada.

May I assume that packages are a form of precompiled dynamic-link
libraries, like dlls in Windows?

No - usualy they result in .obj files. Ada packages consist of a
specification file and a body file which result into object file and some
form of precompiled header file. The Ada language more or less demands some
form of precompiled header files (very simply speaking).

Some Ada compilers use a library database to store the objects and the
compiled specifications.

See: http://en.wikibooks.org/wiki/Programming:Ada:Packages

These are used essentially for system-oriented code.

No, almost all header files need:

#if defined (X_INCLUDED)
#define X_INCLUDED)

#endif

Which brings us back to the packages ;-) .

Martin

 

[REH]

Indeed.

Not all of us do "regular application programming." I write
mission-critical systems. In such an environment, it is non-sense NOT to
define ranges for data types that have them. I would rather it "failed
loudly" when a variable strayed out of range and raised an exception I can
recover from, then continuing to run, causing unknown or undefined behavior.

 

[REH]

I am pretty sure one can write a library that can enable just that.


Now that I am thinking of it, there are some, and let's begin from Boost:


http://www.boost.org/libs/integer/integer.htm


#include <boost/integer.hpp>


int main()
{
using namespace boost;

int_t<24>::least my_var;
}



with "least" being the smallest built-in type that supports the given bit
count.



You see, that's easy. Just "plug in" Boost.

Yes, I'd used Boost. It's an amazing library, but the above is not
equivalent to what I wrote. The major different, and the feature I'd mainly
like to see in C++ in that the definition of Byte above is a unique type.
It can participate in overload resolution. Different typedefs using
int_t<24> are not distinct. I know this can be achieved with an extra
template parameter, enums, or classes, but I don't want to go to that kind
of effort just to tell the compiler to treat it as a unique type. Another
difference, in C++ you cannot create an array of int_t<3> and have all the
element be exactly 3 bits. Using 'size and 'component_size (or even pragma
pack), in Ada you can. I can also specify a range other than zero to max.
You may not care (as your other post suggests), but for fault tolerance, I
do.

Don't get me wrong. I'm not one of the C++ bashers (I think
language-bashing is nonsense). C++ is my favorite language. But Ada has
some really nice features I'd like to see in it. I don't care about the
forced range checking. I don't think that "fits" C++. I would however,
like to be able to easily define unique types of primatives. Being able to
portable and explicitly define its size in bits (so that arrays and structs
obey) would be nice, too.

 

[Ioannis Vranos]

Not all of us do "regular application programming." I write
mission-critical systems. In such an environment, it is non-sense NOT to
define ranges for data types that have them. I would rather it "failed
loudly" when a variable strayed out of range and raised an exception I can
recover from, then continuing to run, causing unknown or undefined behavior.

If you are having for loops with arrays in mind, a simple high level
safe C++ solution exists. Consider:


#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>someArray(10, 1);

// ...

transform( someArray.begin(), someArray.end(),
someArray.begin(), doubleF );


This can't ever be out of bounds.

 

[REH]

If you are having for loops with arrays in mind, a simple high level safe
C++ solution exists. Consider:


#include <algorithm>
#include <vector>

inline int doubleF(const int &arg) { return 2*arg; }

// ...

vector<int>someArray(10, 1);

// ...

transform( someArray.begin(), someArray.end(),
someArray.begin(), doubleF );


This can't ever be out of bounds.

Much more just array accesses. Variables of particular units that must stay
within range (i.e., lat/long, BAMS, radians, velocities, altitudes, depths,
etc.). I'm not saying this can't be done in C++, because I've done it.
It's just easier in Ada.

 

[Robert A Duff]

This is not ok, P3 deeper than PA.

<<
procedure Demo is

type PA is access procedure;

procedure P (Proc : in PA) is
begin
null;
end P;

procedure P1 is
begin
null;
end P1;

procedure P2 is
procedure P3 is
begin
null;
end P3;
begin
P (P3'Access);
end P2;

begin
null;
end Demo;

However, it will be legal to pass a nested procedure in Ada 2005,
and GNAT already supports that. The rules still prevent dangling
pointers:

procedure P (Proc : access procedure(...)) is
begin
Proc;
end P;

procedure P2 is
P2_Local: Integer := 0;
procedure P3 is
begin
P2_Local := P2_Local + 1;
end P3;
begin
P (P3'Access);
end P2;

In Pascal's example, P can assign Proc into a global variable, and it
can be called after P2 returns, which is why it is forbidden to pass
P3. In my example, on the other hand, you can pass P3, but P cannot
assign Proc into a global variable. Either way, no dangling pointers,
unless you play some low-level tricks.

Yes.

I think he meant "can generic instantiation be recursive", and the
answer is "no, it cannot". A generic procedure can call itself,
but that's not the same thing.

Not sure to understand everything. But yes, if you have:

Value : constant String := "whatever";

It will never be able to mutate Value.

.... and 'in' mode parameters can't be modified, and you can't modify
what an access-to-constant points at.

I think it's a bit more difficult to "cast away const" in Ada,
and the results can be bad news.

- Bob

 

[Robert A Duff]

I believe Ada also has exceptions, but I don't know if
they work in the same manner. Does Ada have some equivalent
of C++ constructors and destructors?

Yes. I believe that the C++ exception design was based on Ada
exceptions, and the Ada finalization stuff was based on the C++
features. The differences in these areas are fairly minor.
I guess the biggest one is that a C++ exception is a first-class
object, so you can pass extra information along with a thrown exception
in a straightforward way, whereas in Ada, the mechanism for passing
extra information is an ugly kludge.

Another difference is that Ada doesn't rely so heavily on constructors
-- there is something like a constructor in Ada, but the *usual* way to
create objects is simply to call a function that returns one, as in:

X: Int_Set := Empty_Set;
Y: constant Int_Set := Singleton_Set(17);

- Bob

 

[Robert A Duff]

Even Bliss has nested functions. What Ada has that Pascal has in addition
to nested functions is uplevel addressing, allowing an inner function to
access data declared in outer scopes.

Heh? Pascal has that. In fact, practically every programming language
outside the C family has this feature. It's quite useful -- almost
essential in multi-threaded programs.

- Bob

 

[Martin Krischik]

I do not believe that to be the problem. There is a standard and there are
commercial libraries out there to test conformance. The problem rather
lies in other areas such as:

- compiler vendors wanting to be backwards compatible.
- compiler vendors wanting to get a grip on their customers by ofering
"extensions" to the language.
- compiler vendors who don't care if their product is standards-compliant.

How very true.

You could use another library out there. Cars are not bad just because one
manufacturer ships buggy cars out.

It was a very special lib with only a very few alternatives out there.

(http://www.digitalmars.com/ctg/ctgLanguageImplementation.html#cpp_unimplemented).

Did you have a look at Comeau C++?

No. Got a link to have a look?

If you look at C++ (i can't comment on C), all major vendors i know of
have a high level of compliance.

For the '98 standart yes - but how about the '03 standard. As I said - one
release behind.

And they havn't got 100% compliance - as the Ada compiler vendors have. And
they can indedd claim that - Ada has the ACATS test - pass the test you are
100% compliant - fail the thest and (almost) no customer will consider your
offer.

This is simply not true.

Shure it is true: The C++ ISO standard has ruffly 200 pages more then the
Ada ISO standard. The C standard is a few pages shorter - but C hasn't got
object orientation, concurency, real time and distributed system included.

The "ISO commitie" you refer to consists of
people using C++ in daily life.

So are the Ada commitie memebers. Still Ada was/is bashed for beeing a
commitie language and C++ isn't.

I have to disagree again. C/C++ has been most succesfull as a language if
you measure that by the number of applications written in that language.

Shure C/C++ are successfull I never said any different - I just pointed out
that C/C++ are not slim and lightweight languages any more. They have
become fat over time. Only the fat does not show - because theree so many
implit features which only show when you read the ISO standart itself.

And since the very successfull C/C++ have become as big as they are I
rightfully claim the the advocates for slim languages hat been wrong all
along.

But prove me wrong and show me any successful slim language - which has not
become fat (either by language or by build in library) withing 10 years of
becomming successfull.

Martin

 

[Ioannis Vranos]

For the '98 standart yes - but how about the '03 standard. As I said - one
release behind.

C++03 is C++98 bug fixed. You can have a look at the list of fixes:

http://www.acceleratedcpp.com/authors/koenig/c++std/revisions.pdf

And they havn't got 100% compliance - as the Ada compiler vendors have.

Today in the latest compiler releases of the major vendors, compliance
is at least >98% (*there are* 100% compliant implementations).

And
they can indedd claim that - Ada has the ACATS test - pass the test you are
100% compliant - fail the thest and (almost) no customer will consider your
offer.

There are compliance tests for C++ too.

 

[CTips]

Google shows me lwlock as a C function in the PostGres support groups;
I don't know what machine architecture has these instructions? PowerPC?

Yes, and alpha.

It could be used by any compiler as part of a low-level
implementation, of course, but it's hardly likely that a C compiler
could use it off its own bat. Why whould it want to unless you the
programmer tells it to?

If you're talking about assembler inserts in C -- for Pete's sake, we
can insert assembler in Ada as a last resort if it's needed.

Can you do the following in Ada: use an assembler inset for just stwcond
and lwlock, and use C for everything else, and then get the expected
assembly code.

What happens with lwlock about priority inversion?

You don't need it. Thats one of the big advantages about lock free schemes.

Umm ... look at the set of lock-free data-structures out there. Quite
heavy-weight structures can be implemented, including a queue where a
thread can be adding elements while other threads are removing elements.

 

[CTips]

Not all of us do "regular application programming." I write
mission-critical systems. In such an environment, it is non-sense NOT to
define ranges for data types that have them. I would rather it "failed
loudly" when a variable strayed out of range and raised an exception I can
recover from, then continuing to run, causing unknown or undefined behavior.

Thats another problem with Ada's run-time checking. If you're using it
in an environment where the hardware may "fail" [e.g. alpha particles
randomizing memory], the checks are quite often in the wrong place.

For example, look at the Ada equivalent of the following code.
typedef enum {0, 1, 2, 3} four_val;
four_val x;

x = (four_val) some_int;
....
assert( x < 4);

The compiler will drop in a check at the cast to ensure that the wrong
value is not getting stored into x. Then, it will proceed to eliminate
the check that x < 4, because it knows that 0..3 are the only legal
values of x. However, if there is a hardware bug, the value of x will
get changed between the definition point and the use point.

When bringing up hardware, I like to have a little more control over
where the run-time checks are going to be placed. This is another niche
situtation in which the compiler's "automatic" checking does the wrong
thing.