I 'm following various posting in "comp.lang.ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.
May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?
Jul 23 '05
822  28881 
Ioannis Vranos <iv*@remove.this.grad.com> writes: Pascal Obry wrote:
Note that it is for this very reason that Java was born (a safer C++). Java
has indeed removed lot of unsafe constructs from C++.
Please do not start a real flame! Java is far behind C++. It is a silver
Sorry I do not intend to. This is history and as described by Java
creators. Please read my other post.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 Ki*******@SpamCop.net (Larry Kilgallen) wrote in message Nobody objects to someone using the name ADA in a program written in Ada.
The comments are about someone using improper capitalization in text
written in English, a language which is case-sensitive.
As many people on this thread noticed, it was only a (bad?) joke. I
simply wanted to remark that I was somewhat tired of reading the same
story of Ada L. when some innocent soul dared to write "ADA" :)
3. Many of you want us to believe that ADa performs ra nge checking
without loss of performance: it can be true at compile time with fixed
ranges, but it can't definitely be done without chechinkg array bounds
every time data is accessed if we don't know these bounds before
compiling (e.g.: typical cases where dynamic allocation of memory is
used)
As has been stated, it is _much_ more efficient that do-it-yourself
range checking written in C++, because the compiler has more data.
For those who insist on _no_ range checking (compute intensive inner
loops), turn off the range checking if it gets in the way for that
one area of code. But be certain it gets in the way first - it
is common to make bad guesses about whether range checking will
affect overall performance. Ada programmers are better able than
C* programmers to know that, because in Ada it is easier to turn
range checking on and off.
Yes, but consider the existence of STL that lets you not to
"do-it-yourself" when storing or accesing data ;)
mechanisms, only interfaces (pure virtual classes)[2]. To me, it
sounds reasonable to work with the last version of a compiler when
possible.
That does not seem so reasonable to people working on a mission-critical
30 year project. In many cases such circumstances warrant working with
the compiler originally used for the project.
You are right: if something works, it is usually better not to touch
it, but in this case, you are stuck with Ada83!
>"Interesting", indeed. ;-) Unfortunately, about half of this information is complete nonsense -- about both languages!
I would like to believe that people like you would point out the
nonsense preventing people like me from consuming it.
Ioannis Vranos wrote: Pascal Obry wrote:
package API is
pragma Remote_Call_Interface;
procedure Call_Me (Str : in String);
end API;
What is it doing?
pragma Remote_Call_Interface categorizes the package "API"
as a remote call interface library unit.
LRM E.2.3:
7. A remote call interface (RCI) is a library unit to which the pragma
Remote_Call_Interface applies. A subprogram declared in the
visible part of such a library unit is called a remote subprogram.
It might be worth mentioning that Ada programs can constist of
partitions. They can be distributed programs then. A remote
call interface is assigned to one partition.
Georg
Dmitry A. Kazakov wrote: Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?
Regarding Storage_Error exception, C++'s one is bad_alloc, which is
guaranteed to *never fail* in case of memory starvation.
About stack. Strictly speaking, C++ standard does not define any stack
apart from a stack container , but "automatic storage" and "dynamic
storage".
It is common though the first to be called "stack" and the second "heap"
or "free store".
It is an implementation's/platform's job to provide stack and heap.
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Ioannis Vranos wrote: Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Nope. And you can control in portable Ada how big the stack for a given
task must be.
Ioannis Vranos wrote: Regarding Storage_Error exception, C++'s one is bad_alloc, which is
guaranteed to *never fail* in case of memory starvation.
About stack. Strictly speaking, C++ standard does not define any stack
apart from a stack container , but "automatic storage" and "dynamic
storage".
It is common though the first to be called "stack" and the second "heap"
or "free store".
It is an implementation's/platform's job to provide stack and heap.
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
As is the case when I use a vector<int> for example. The object itself
is in the stack, however internally it allocates memory in the heap to
store its members, which releases with its destructor when it is
destroyed (e.g. in the end of its scope).
Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.
In summary RAII is a technique which is used to encapsulate resources
(as vector does for memory and is used as a general array, and string
also and is used as a string type), with the constructor allocating the
resources and the destructor releasing them, and thus producing
bullet-proof code.
When an exception is thrown or the object reaches the end of its scope,
the object gets destroyed releasing the resources via its destructor.
RAII can be used for any kind of resources, IP connections, memory,
files, etc. All standard library containers use RAII.
--
Ioannis Vranos http://www23.brinkster.com/noicys
In article <e3**************************@posting.google.com >, az****@yahoo.es (Alberto) writes: Ki*******@SpamCop.net (Larry Kilgallen) wrote in message
Somebody no longer attributed wrote: > mechanisms, only interfaces (pure virtual classes)[2]. To me, it
> sounds reasonable to work with the last version of a compiler when
> possible.
That does not seem so reasonable to people working on a mission-critical
30 year project. In many cases such circumstances warrant working with
the compiler originally used for the project.
You are right: if something works, it is usually better not to touch
it, but in this case, you are stuck with Ada83!
I have made many changes in the past 6 months to a 16 year old program
written in Ada 83. There are now about 200,000 source lines of code,
and since the changes were all to do "more of the same" I never felt
any lack of capability in the language. The problems I encountered
while debugging were almost all in three or so modules _not_ written
in Ada.
But similar to what we agreed about compilers, I am not about to
switch programming languages on those few modules at this point.
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:qe*****************************@40tude.net... On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:97*****************************@40tude.net...> 2. C++ is unable to allocate objects of indefinite size on the stack.
Well, we have alloca() for this ;)
Try to return such object from a function. Ada can
declare
Object : T'Class := Read_It_From_File;
Here neither the specific type, nor the size of the object are known at
compile time. Another example:
declare
Line : String := Read_Source_Line (File);
Or even:
Put_Line (Read_Source_Line (File));
The solution is simple here - just allocate your memory on the heap.
Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?
I believed the object might have to be returned? Read the post once again.
If this is so, you can not allocate it on the stack without having to copy
when you return the object. Surely the copy must be more expensive than the
allocation?
Ordinary heap-based speed is not so slow and if you need to get the last
cpu-cycle away, you can simply use an arena for your allocation.
Also you will of course use a smart pointer in the situation above. A C++
programmer with respect for himself only rarely uses new without putting the
result in some kind of smart pointer. Personally, I do not remember when i
did that last.
/Peter
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
"Alex R. Mosteo" <de*****@mailinator.com> skrev i en meddelelse
news:42**************@mailinator.com... Ioannis Vranos wrote: Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Nope. And you can control in portable Ada how big the stack for a given
task must be.
But you do not know the size of the object so how does that help you setting
the stack-size?
/Peter
On Fri, 11 Mar 2005 14:12:14 +0200, Ioannis Vranos wrote: Dmitry A. Kazakov wrote:
Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?
Regarding Storage_Error exception, C++'s one is bad_alloc, which is
guaranteed to *never fail* in case of memory starvation.
Even if exception object is 100GB large?
About stack. Strictly speaking, C++ standard does not define any stack
apart from a stack container , but "automatic storage" and "dynamic
storage".
It is common though the first to be called "stack" and the second "heap"
or "free store".
It is an implementation's/platform's job to provide stack and heap.
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Stack here means LIFO. It is not necessarily the machine stack, though in
most cases it will be. I think there is no need to explain why LIFO
allocation / deallocation strategy is in order of magnitude more efficient
than heap? Neither should I explain why local to task (thread) memory is
better than the global heap in any concurrent program and especially in
ones running on multi-processor machines...
Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.
= smart pointers. Yes. It is a widely used technique to regain the safety
lost while switching from stack to heap. It adds additional performance /
space penalty to what heap already has.
--
Regards,
Dmitry A. Kazakov http://www.dmitry-kazakov.de
Peter Koch Larsen wrote: "Alex R. Mosteo" <de*****@mailinator.com> skrev i en meddelelse
news:42**************@mailinator.com...
Ioannis Vranos wrote:
Usually the stack is limited in comparison to the heap, and it sounds
strange to me that in Ada there is a large stack. My guess is that you
are using the heap for data storage implicitly(?) and you think you are
using the stack.
Nope. And you can control in portable Ada how big the stack for a given
task must be.
But you do not know the size of the object so how does that help you setting
the stack-size?
I'm not sure what you want to imply here. The thing is that while in
stack terrain you're free of all dynamic memory additional
hazards/overheads, which in certain realtime environments is seen as
desirable. As parent said, stacks tend to be smaller than heaps, and in
Ada you can control that without going non-portable.
If we're talking of unknown sized objects, either a stack or a heap can
be too small. ?
"Hans Malherbe" <ha***********@gmail.com> writes: "Interesting", indeed. ;-) Unfortunately, about half of this
information is complete nonsense -- about both languages!
I would like to believe that people like you would point out the
nonsense preventing people like me from consuming it.
A fair comment.
I *did* post a few notes in this thread trying to set some things
straight. And I might post a few more, if I have time. But how do you
know whether to trust what *I* say over what anyone else says? ;-)
If you really want to know about these languages that are being
discussed (Ada and C++) nothing beats reading a textbook or two.
- Bob
Dmitry A. Kazakov wrote: Even if exception object is 100GB large?
I am talking about the exception class bad_alloc whatever the sizes of
other objects (even exceptions) are. It is guaranteed that there is
always free memory for bad_alloc.
Stack here means LIFO. It is not necessarily the machine stack, though in
most cases it will be. I think there is no need to explain why LIFO
allocation / deallocation strategy is in order of magnitude more efficient
than heap? Neither should I explain why local to task (thread) memory is
better than the global heap in any concurrent program and especially in
ones running on multi-processor machines...
Although I know the general difference between stack and heap (the last
storing things in a messy way), I have no knowledge about them in terms
of program's space (that is how the heap can be rearranged in the
background), so it is better someone else to answer this.
However in general what I know is that the additional time-cost of
dynamic storage in comparison to the automatic storage can be described
as the additional cost of new and delete calls. Are you familiar with "Resource Acquisition is Initialisation" (RAII)
technique? This is supported by C++ and used by all standard library
containers.
= smart pointers. Yes. It is a widely used technique to regain the safety
lost while switching from stack to heap. It adds additional performance /
space penalty to what heap already has.
Smart pointers, as also containers, but even for resources other than
memory.
--
Ioannis Vranos http://www23.brinkster.com/noicys
On Fri, 11 Mar 2005 14:28:26 +0100, Peter Koch Larsen wrote: "Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:qe*****************************@40tude.net... On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:97*****************************@40tude.net...>> 2. C++ is unable to allocate objects of indefinite size on the stack.
>
> Well, we have alloca() for this ;)
Try to return such object from a function. Ada can
declare
Object : T'Class := Read_It_From_File;
Here neither the specific type, nor the size of the object are known at
compile time. Another example:
declare
Line : String := Read_Source_Line (File);
Or even:
Put_Line (Read_Source_Line (File));
The solution is simple here - just allocate your memory on the heap.
Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures with
pointers. Do you want to add one more indirection layer - smart pointers,
or do it even worse by using GC?
I believed the object might have to be returned? Read the post once again.
If this is so, you can not allocate it on the stack without having to copy
when you return the object. Surely the copy must be more expensive than the
allocation?
The compiler can use multiple stacks so that arguments and the result might
be allocated on different stacks.
Ordinary heap-based speed is not so slow and if you need to get the last
cpu-cycle away, you can simply use an arena for your allocation.
Yes, some Ada compilers would probably use discontiguous object
representation and arenas for variable parts. The difference is that it is
still not the global heap. And it is controlled by the compiler which
exactly knows the scope of objects.
Also you will of course use a smart pointer in the situation above. A C++
programmer with respect for himself only rarely uses new without putting the
result in some kind of smart pointer. Personally, I do not remember when i
did that last.
I'd be happy if all C++ programmers would be ready and willing to
compensate deficiencies of the language through more careful and thoughtful
design. Actually, we are doing a lot of developing in C++, and due to my
job responsibilities time to time I have to review C++ code...
--
Regards,
Dmitry A. Kazakov http://www.dmitry-kazakov.de
Adrien Plisson wrote: Alberto wrote: 6. I don't know what's the point with "aDA being used in avionics
or rocket science". Planes and rockets are falling from the sky from
time to time;
Ada is also used in particular rockets called missiles, and its job
inside is just to make them fall... but fall gracefully.
--
rien
Would that happen to include the now-infamous Patriot Missles (the ones
that couldn't hit a barn after they'd been on for a while due to a
bug?)
--T Beck
Pascal Obry wrote: "Jerry Coffin" <jc*****@taeus.com> writes:
Your claim of fewer bugs is just the sort of unsupported anti-C
comment we see all the time.
Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html
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.
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.
In short, this is not a comparison to the C language as it exists
today, or has existed in well over a decade.
He also mentions C++ in passing, but (again, based on the timing) he
was clearly looking at C++ when it was still in an embryonic stage.
Worse, the understanding and use of the language were, if anything,
well behind the development of the language itself. The language itself
was clearly inferior to todays, but it's use was inferior by an even
larger margin.
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).
It's true that Ada has also been updated in the meantime, but the
changes in Ada have been _drastically_ smaller than those in C or C++.
Ada 83 already had generics, already had type-checking on the same
general order as that introduced into C with function prototypes, etc.
With Ada 95 you can probably expect a fairly substantialy improvement
in reuse, but only rather minor improvements elsewhere.
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.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Adrien Plisson wrote: Jerry Coffin wrote: Second, if the work had been done exclusively or primarily in
a language the DoD considered its own, I suspect opening it up
to the public would have taken even longer, if it was ever
allowed to happen at all.
but still ARPA-net was created by the United States Defense Advanced
Research Project Agency, part of... the DoD !
That was exactly my point: it started out as a DoD-funded project. The
question is about what happened then -- how willing the DoD was to open
the project to the public at large. As it was, the project was done
with DoD funding, but was really done at and by universities. While it
is openly acknowledged to have fulfilled its original intent extremely
well, nearly every choice in its design and implementation was about as
UN-military as possible. Despite this, it took 20+ years before it was
really open to the general public.
Had even ONE element in the design or implementation fit even slightly
more closely with the military mind-set, I doubt it would have been
opened up to the public yet, or possibly ever. To ensure that, connecting to this system would only be allowed
after passing an extensive (and expensive) certification process,
and only one OS in existence would be capable of passing -- and
it wouldn't be from a bunch of hackers like Microsoft either. It
would be from some place thoroughly professional, with a
thoroughly professional license fee (i.e. well out of reach of
over 99% of the people who currently use the Internet).
I don't remember running UNIX (implemented in C) was cheap at the
time ARPA-net was born ! also, one of the major Ada compiler is
available for free, so why would it be so expensive ?
Prices for computing in general were much higher at the time, but UNIX
was cheaper than most.
It seems difficult to believe that anybody would believe or even imply
that the cost of the compiler determines the cost of the final product.
Even ignoring that for the moment, you're using cirular logic -- you're
assuming the 'net would be built with GNAT, ignoring the fact that the
free availability of GNAT is largely a _result_ of the 'net's
existence.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Robert A Duff wrote:
[ ... ] If you really want to know about these languages that are being
discussed (Ada and C++) nothing beats reading a textbook or two.
Much as I hate to further my (undoubtedy bad) reputation for being
disagreeable, I still have to disagree.
If you follow-up the reading with some real use, it beats reading alone
by a wide margin, at least IME.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote: Ada features I would love to have in C++:
* "new types" and sub-ranges
Agree strongly. (with compiler-generated checking!)
* runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)
This would be nice!
* subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)
Agree strongly.
* packages. namespaces are nice, but packages make modularity of very
large system a lot easier. Especially now with "use type"
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation
* representation specifications!!!!
Agree.
C++ features I would to have in Ada:
* Implicit instantiation. Yeah, I know, it can be unsafe, but that is
one thing I really like about C++: the ability to automate repetitive
things.
Sometimes useful but is it more than "syntactic sugar"?
* actually having a class object encapulating the data and methods.
Yes. It might help if packages were first class objects instead
* reference (in out) types in functions (without resorting to
access types)
procedures usually suffice. The "Rosen Trick" works in most
cases. I'd like to be able to identify functions as "pure",
like in VHDL, and allow the compiler to discard or memoize
calls to functions marked as pure.
* meta-templates. very neat stuff. ugly, but neat.
I think I prefer Ada generics. I have yet to see how Meta-templates
really contribute to a program design.
* The STL!!! (though I hear something similar is coming?)
Yes. Agree strongly.
-------------------------------------------------------------
My list of Ada features I would love to have in C++ adds:
Concurrency. Tasks. Protected objects.
Distributed programs. Persistent variables.
Eliminate large swathes of the C++ standard which leaves
the semantics up to the compiler!
Named parameter association. Proper parameter modes
"out" and "in out" modes
clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)
Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.
More robust, more readable, less terse syntax, particularly
for complex templates (really!)
Portability without resorting to preprocessor directives
and conditional compilation
--------------------------------------------------------------
My list of C++ features I would love to have in Ada adds:
simple and direct interfacing to C/C++ header files - a *big*
drawback of Ada :(
template specialization
extra parameters with "new"
--------------------------------------------------------------
But what of features not present in either?
Introspection
Dynamic compilation/interpretation
parallel execution constructs (see Cilk, Occam's "par")
coroutines
configurations (from VHDL)
associative arrays (from Perl)
What else?
--
Adrian
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:u0****************************@40tude.net... On Fri, 11 Mar 2005 14:28:26 +0100, Peter Koch Larsen wrote:
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:qe*****************************@40tude.net... On Fri, 11 Mar 2005 10:42:51 +0100, Peter Koch Larsen wrote:
"Dmitry A. Kazakov" <ma*****@dmitry-kazakov.de> skrev i en meddelelse
news:97*****************************@40tude.net...
>>> 2. C++ is unable to allocate objects of indefinite size on the
>>> stack.
>>
>> Well, we have alloca() for this ;)
>
> Try to return such object from a function. Ada can
>
> declare
> Object : T'Class := Read_It_From_File;
>
> Here neither the specific type, nor the size of the object are known
> at
> compile time. Another example:
>
> declare
> Line : String := Read_Source_Line (File);
>
> Or even:
>
> Put_Line (Read_Source_Line (File));
The solution is simple here - just allocate your memory on the heap.
Heap is far slower than stack. Also stack is much safer, because objects
allocated on the stack have visible scopes, as compared to adventures
with
pointers. Do you want to add one more indirection layer - smart
pointers,
or do it even worse by using GC?
I believed the object might have to be returned? Read the post once
again.
If this is so, you can not allocate it on the stack without having to
copy
when you return the object. Surely the copy must be more expensive than
the
allocation?
The compiler can use multiple stacks so that arguments and the result
might
be allocated on different stacks.
Okay. If the Ada concept of a "stack" is the same as my hardware-oriented
one, I doubt i would have much trust to the performance of a such a type of
programming.
Ordinary heap-based speed is not so slow and if you need to get the last
cpu-cycle away, you can simply use an arena for your allocation.
Yes, some Ada compilers would probably use discontiguous object
representation and arenas for variable parts. The difference is that it is
still not the global heap. And it is controlled by the compiler which
exactly knows the scope of objects.
Also you will of course use a smart pointer in the situation above. A C++
programmer with respect for himself only rarely uses new without putting
the
result in some kind of smart pointer. Personally, I do not remember when
i
did that last.
I'd be happy if all C++ programmers would be ready and willing to
compensate deficiencies of the language through more careful and
thoughtful
design. Actually, we are doing a lot of developing in C++, and due to my
job responsibilities time to time I have to review C++ code...
If I were to review code with a regular use of new and delete, I would send
the code right back - and the responsible programmer on a course - hoping
for a substantial improvement in style.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
/Peter
Ioannis Vranos <iv*@remove.this.grad.com> writes: The bottom line is that as a language itself it has less abilities than C++,
the framework being another case.
Right. I agree. Don't get my message wrong. I never said that Java was
better. I just stated the original goal as expressed by Sun.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> skrev i en
meddelelse
news:pa****************************@linuxchip.demo n.co.uk.uk.uk... On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote: Ada features I would love to have in C++:
* "new types" and sub-ranges
Agree strongly. (with compiler-generated checking!)
This can be implemented mostly with templates.
* runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)
This would be nice!
How would you do that without "compiling on the fly"?
* subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)
Agree strongly.
This will be part of the next standard, I hope. Still i do not believe it to
be esential for use.
* packages. namespaces are nice, but packages make modularity of very
large system a lot easier. Especially now with "use type"
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation
* representation specifications!!!!
Agree.
Why? What is the purpose - if not to restrict portability?
C++ features I would to have in Ada:
* Implicit instantiation. Yeah, I know, it can be unsafe, but that is
one thing I really like about C++: the ability to automate repetitive
things.
Sometimes useful but is it more than "syntactic sugar"?
* actually having a class object encapulating the data and methods.
Yes. It might help if packages were first class objects instead
* reference (in out) types in functions (without resorting to
access types)
procedures usually suffice. The "Rosen Trick" works in most
cases. I'd like to be able to identify functions as "pure",
like in VHDL, and allow the compiler to discard or memoize
calls to functions marked as pure.
* meta-templates. very neat stuff. ugly, but neat.
I think I prefer Ada generics. I have yet to see how Meta-templates
really contribute to a program design.
* The STL!!! (though I hear something similar is coming?)
Yes. Agree strongly.
-------------------------------------------------------------
My list of Ada features I would love to have in C++ adds:
Concurrency. Tasks. Protected objects.
Distributed programs. Persistent variables.
I doubt that this should be part of the standard. What is needed is
specification of low-level features in e.g. multiprocessor environments.
Eliminate large swathes of the C++ standard which leaves
the semantics up to the compiler!
Most of these "implementation defined" parts are there for portability. To
many definitions will make it more difficult to port C++ to other platforms.
Named parameter association. Proper parameter modes
"out" and "in out" modes
I do not see the purpose of the out-parameter. Why not simply return the
value(s)?
As for named parameter associations, these can again be implemented in a
library.
clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)
For C++ portability from C was (and is) an important issue. Thus there is no
question about remocing e.g. pointer-arithmetic and decaying of arrays to
pointers. This simply can not happen. Also some of these features are needed
for an efficient implementation of low-level classes (e.g. std::vector).
What you can do is not use these features. And it is just a matter of
education to routinely use e.g. std::vector< t > and std::string instead of
arrays and char pointers.
Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.
There are some bad decisions in the type system - specifically i hate the
automatic conversions from double to integral value. But again - this is
something you have to live with.
More robust, more readable, less terse syntax, particularly
for complex templates (really!)
Right. The template stuff could possibly have been more elegant.
Portability without resorting to preprocessor directives
and conditional compilation
I am not sure i follow you here. In what way do you want portability? Are
you thinking of e.g. portability between an X-windows system and Windows? Or
portability of lower-level constructs such as multithreading or networking?
I wonder how Ada does this stuff.
--------------------------------------------------------------
My list of C++ features I would love to have in Ada adds:
simple and direct interfacing to C/C++ header files - a *big*
drawback of Ada :(
template specialization
extra parameters with "new"
--------------------------------------------------------------
But what of features not present in either?
Introspection
Dynamic compilation/interpretation
parallel execution constructs (see Cilk, Occam's "par")
coroutines
configurations (from VHDL)
associative arrays (from Perl)
I thought Ada supported generic programming. Isn't it then just a question
of creating a library?
What else?
--
Adrian
/Peter
Dr. Adrian Wrigley wrote: But what of features not present in either?
[...] associative arrays (from Perl)
Wouldn't that be std::map in C++?
Falk
"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pa****************************@linuxchip.demo n.co.uk.uk.uk... C++ features I would to have in Ada:
* Implicit instantiation. Yeah, I know, it can be unsafe, but that is
one thing I really like about C++: the ability to automate repetitive
things.
Sometimes useful but is it more than "syntactic sugar"?
No, probably not but unlike a lot of my colleagues, I like syntactic sugar.
That's why I love being able to overload operators in both languages. I can
add to the language, and make my new constructs look like they are part of
the language.
* reference (in out) types in functions (without resorting to
access types)
* meta-templates. very neat stuff. ugly, but neat.
I think I prefer Ada generics. I have yet to see how Meta-templates
really contribute to a program design.
The reason I prefer template (their power, not looks) is their ability to
"store" information using the type system. For example, recently on a
(personal) project, I had a set of object I wanted to be able to act upon
(like std::foreach does) and filter for various criteria. Using templates I
created a function to traverse the objects. This function takes two
template parameters, the operation to be perfomed, and the filter. I have
template classes for filters and operators for the boolean operators to
combine and build more advanced filters on-the-fly without creating functors
each time. Something like:
traverse_objects(objects, operation, filter1(stuff) && filter2(other-stuff)
|| !filter3());
This has to be done with templates and class types because the boolean
operations can't be done now, but "deferred" until called by operation. As
an example, this is a simplicist version of the "and" filter:
template<class A, class B>
struct and_filter {
and_filter(const A& a, const B& b) : m_a(a), m_b(b) {}
bool operator() (Object& o) {return m_a(o) && m_b(o);}
A m_a;
B m_b;
};
template<class A, class B>
inline and_filter<A, B> operator&& (const A& a, const B& b)
{
return and_filter<A, B>(a, b);
}
I know its less safe, but I like that I can use "anything" for the template
parameters that "fit" the syntax (i.e., using functions or class objects
that have the () operator defined).
Named parameter association. Proper parameter modes
"out" and "in out" modes
I would love have named parameters too. That way I would not have to
"agonize" over the "priority" of my default parameters (i.e., if there are
10 and I have to change the 10th from its default, I have to define the
first 9).
clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)
Yes, arrays are first-class objects!
Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.
I love that Ada enumeration don't pollute the global namespace and allow
fully qualified names. I wish I could do enum_name::element in C++ without
wrapping the enum declaration in a namespace.
More robust, more readable, less terse syntax, particularly
for complex templates (really!)
Completely agree!!
associative arrays (from Perl)
I assume you want more than that offered by std::map?
"Peter Koch Larsen" <pk*****@mailme.dk> wrote in message
news:2v*********************@news000.worldonline.d k... * runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)
This would be nice!
How would you do that without "compiling on the fly"?
Ada generics can do this without compiling on the fly. I think its a nice
feature. * representation specifications!!!!
Agree.
Why? What is the purpose - if not to restrict portability?
Actually rep. specs. enhance portability by explicitly defining the actual
sizes of types, the internal layout of records, etc. The only aspect (I
believe) that is implementation specific, it bit ordering (though, didn't
they add pragmas for this?)
Dr. Adrian Wrigley wrote: Ada features I would love to have in C++:
* "new types" and sub-ranges
I do not know what you mean exactly by that, however one can define his
own types rather than having everything as built-in.
C++ provides general purpose facilities with which one can build his own
special purpose libraries, rather than providing special purpose
facilities as built in.
Consider std::complex as a complex type, rather than a built in complex
type.
* runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)
This would be nice!
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.
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation
May I assume that packages are a form of precompiled dynamic-link
libraries, like dlls in Windows?
My list of Ada features I would love to have in C++ adds:
Concurrency.
Will be available in C++0x. Today is platform-specific, but there is
also a standard about C++, OpenMP (see below).
Tasks. Protected objects.
Distributed programs. Persistent variables.
Eliminate large swathes of the C++ standard which leaves
the semantics up to the compiler!
Named parameter association. Proper parameter modes
"out" and "in out" modes
clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)
Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.
More robust, more readable, less terse syntax, particularly
for complex templates (really!)
I assume you are right, concerning newcomers, but for me Ada's syntax is
the bizarre one (apart from the Pascal "subset"). :-)
Portability without resorting to preprocessor directives
and conditional compilation
These are used essentially for system-oriented code.
--------------------------------------------------------------
My list of C++ features I would love to have in Ada adds:
simple and direct interfacing to C/C++ header files - a *big*
drawback of Ada :(
template specialization
extra parameters with "new"
--------------------------------------------------------------
But what of features not present in either?
Introspection
Dynamic compilation/interpretation
This is against the systems programming bias of C++. Also there are C++
interpreters out there. Here is a nice, small one:
http://home.mweb.co.za/sd/sdonovan/underc.html
parallel execution constructs (see Cilk, Occam's "par")
coroutines
Today there is OpenMP:
http://www.openmp.org/drupal
configurations (from VHDL)
associative arrays (from Perl)
I am not sure if you mean this, however standard C++ library provides
map and multimap.
--
Ioannis Vranos http://www23.brinkster.com/noicys
REH wrote: Named parameter association. Proper parameter modes
"out" and "in out" modes
I would love have named parameters too. That way I would not have to
"agonize" over the "priority" of my default parameters (i.e., if there are
10 and I have to change the 10th from its default, I have to define the
first 9).
The many parameters passed by reference to be modified is an outdated C
style.
*Today* one may use a std::pair or a combination of std::pairs for
return values.
E.g.
//Returns 2 values
pair<int, int> somefunc();
// Returns 4 values
pair<pair<int, int>, pair<int, int> >somefunc();
// Returns 3 values
pair<pair<int, int>, int>somefunc();
Also this gets more syntactic sugar with the upcoming TR1 standard
library extension and more particularly with "Tuple types".
Here are the proposals that have been accepted for the upcoming TR1: http://www.open-std.org/jtc1/sc22/wg...al_report.html
Personally although more sugar-rich (and still built with the current
C++ facilities, which demonstrates the power and expressiveness of the
language), I am not sure we needed Tuple types, since std::pair does the
job. :-)
I suppose tuple types continue to be convenient for something like 10
return values, since it is just a returned object with the contained
values, but I think returning (or passing) so many values means
something is wrong. :-)
--
Ioannis Vranos http://www23.brinkster.com/noicys
"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1110569032.207770@athnrd02... Dr. Adrian Wrigley wrote:
Ada features I would love to have in C++:
* "new types" and sub-ranges
I do not know what you mean exactly by that, however one can define his
own types rather than having everything as built-in.
Ada allows you to define a primative type (int, etc.) that is "distinct"
from others. This is nice for overload resolution, etc.
C++ provides general purpose facilities with which one can build his own
special purpose libraries, rather than providing special purpose
facilities as built in.
I know, but being about to write "is new integer" is a lot simplier than
creating a class just to create a "unique" integer type. Plus. since it is
a unique type I can define its exact size in bits which make portabililty
easier:
type Byte is new integer range 0 .. 16#ff#;
for Byte'size use 8;
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation
May I assume that packages are a form of precompiled dynamic-link
libraries, like dlls in Windows?
No, they are compilation construct (and can be define in a hierarchy). The
are kind of like namespaces. If you ever used Borland's Turbo Pascal, they
are like units. They make it easy to separate interface and implementation.
Even inlines and generic bodys go in the body package, and not the
specification package, and can be used in a library without needing the
source present to be used. They also allow for the creation of an
elaboration (static construction) order between packages to be defined.
Ioannis Vranos wrote: Personally although more sugar-rich (and still built with the current
C++ facilities, which demonstrates the power and expressiveness of the
language), I am not sure we needed Tuple types, since std::pair does the
job. :-)
I suppose tuple types continue to be convenient for something like 10
return values, since it is just a returned object with the contained
values, but I think returning (or passing) so many values means
something is wrong. :-)
Since tuple types are to be used for more things than only returned and
passed values, I recall the above. :-)
--
Ioannis Vranos http://www23.brinkster.com/noicys
On Fri, 11 Mar 2005 19:32:31 +0100, Peter Koch Larsen wrote:
"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> skrev i en
meddelelse
news:pa****************************@linuxchip.demo n.co.uk.uk.uk... On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote: Ada features I would love to have in C++:
* "new types" and sub-ranges
Agree strongly. (with compiler-generated checking!)
This can be implemented mostly with templates.
the evidence I find is that these Ada features meet programmers'
needs (because they are widely used), yet the nearest equivalent
with templates is almost never used (I have never seen examples).
I don't think new template classes match the utility of new
types and subranges in practical terms (but I'm prepared to
be shown wrong!).
How, for example, do you create a new 2-D array indexed by
enumeration sub-ranges?
For example, what is the templated, range-checked equivalent of:
------------------------------------------
generic
type Index_T is (<>);
type Intensity_T is digits <>;
package CrossBright_P is
type CrossIntensity_T is array (Index_T, Index_T) of Intensity_T;
-- more subprograms here
end CrossBright_P;
type EMSpectrum_T is (Gamma_Ray, X_Ray, Ultra_Violet, Visible, Infra_Red, Microwave, Radio_Wave);
type Intensity_T is digits 6 range 0.0 .. 10_000.0;
type CrossSpectrumIntensity_T is array (EMSpectrum_T, EMSpectrum_T) of Intensity_T;
package MyCrossBright is new CrossBright_P (EMSpectrum_T, Intensity_T);
CrossIntensity : MyCrossBright.CrossIntensity_T := (others => (others => Intensity_T'First));
--------------------------------------------------------------
* runtime template instantiation (I think being able to instantiate
generics dynamically is the coolest thing!)
This would be nice!
How would you do that without "compiling on the fly"?
same way as in Ada!
* subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)
Agree strongly.
This will be part of the next standard, I hope. Still i do not believe it to
be esential for use.
It is sometimes handy to use the C preprocessor for local functions
* packages. namespaces are nice, but packages make modularity of very
large system a lot easier. Especially now with "use type"
Vital! C++ and C suffer a lot from not enforcing encapsulation,
allowing headers to break stuff etc. Better control of scope
and visibility. Better separation of interface and implementation
* representation specifications!!!!
Agree.
Why? What is the purpose - if not to restrict portability?
To get access to externally defined data storage!!
For example, hardware devices, network data representation,
interfacing to machine code etc.
.... -------------------------------------------------------------
My list of Ada features I would love to have in C++ adds:
Concurrency. Tasks. Protected objects.
Distributed programs. Persistent variables.
I doubt that this should be part of the standard. What is needed is
specification of low-level features in e.g. multiprocessor environments.
I think portable concurrent or distributed programming is a paradigm
poorly (non) supported by C++. The current situation is a mess.
Eliminate large swathes of the C++ standard which leaves
the semantics up to the compiler!
Most of these "implementation defined" parts are there for portability. To
many definitions will make it more difficult to port C++ to other platforms.
But at least any difficulty is addressed once per platform,
rather than once for each program!
Named parameter association. Proper parameter modes
"out" and "in out" modes
I do not see the purpose of the out-parameter. Why not simply return the
value(s)?
How do you return multiple values?
As for named parameter associations, these can again be implemented in a
library.
Again, they are widely used in Ada code, but very rarely in C++.
I found the library implementation kludgey. clarity over arrays. C++ gives you choice of pointers
C arrays, vectors. This is one example of where the
'C' facilities were too limited, and C++ added
alternatives, rather fhan fixing what existed in C.
(and char *, char arrays, string etc)
For C++ portability from C was (and is) an important issue. Thus there is no
question about remocing e.g. pointer-arithmetic and decaying of arrays to
pointers. This simply can not happen. Also some of these features are needed
for an efficient implementation of low-level classes (e.g. std::vector).
What you can do is not use these features. And it is just a matter of
education to routinely use e.g. std::vector< t > and std::string instead of
arrays and char pointers.
You can't routinely use only the new features, because library
code mainly uses the old features. (most libraries are supplied
via C-style header files) Strong(er) typing, better enumerations, fixed point types,
modular types *and* non-modular types. Basic type attributes.
There are some bad decisions in the type system - specifically i hate the
automatic conversions from double to integral value. But again - this is
something you have to live with.
(only if you have to use C++!) More robust, more readable, less terse syntax, particularly
for complex templates (really!)
Right. The template stuff could possibly have been more elegant.
Portability without resorting to preprocessor directives
and conditional compilation
I am not sure i follow you here. In what way do you want portability? Are
you thinking of e.g. portability between an X-windows system and Windows? Or
portability of lower-level constructs such as multithreading or networking?
I wonder how Ada does this stuff.
portability for different type sizes (eg pointer widths, char signedness,
basic type ranges, data alignment) associative arrays (from Perl)
I thought Ada supported generic programming. Isn't it then just a question
of creating a library?
it's a nuisance to have to define a suitable hashing function for
each type, particularly one you are several levels into a generic nesting!
The hashing function might need to be passed in at the top and
built in stages at each level. Not nice. (is there an alternative?)
--
Adrian
"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1110570242.82910@athnrd02... REH wrote:
Named parameter association. Proper parameter modes
"out" and "in out" modes
I would love have named parameters too. That way I would not have to
"agonize" over the "priority" of my default parameters (i.e., if there
are 10 and I have to change the 10th from its default, I have to define the
first 9).
The many parameters passed by reference to be modified is an outdated C
style.
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.
"Dr. Adrian Wrigley" <am**@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pa****************************@linuxchip.demo n.co.uk.uk.uk... * subprograms inside subprograms. I think it would be great for use
with the STL (i.e., using a local function with std::foreach)
Agree strongly.
This will be part of the next standard, I hope. Still i do not believe
it to be esential for use.
It is sometimes handy to use the C preprocessor for local functions
That would not work in the example above, i.e., for use as the operation
given to STL algorithms. Besides, inline is better for "quick" functions
than the preprocessor.
The closest thing I've seen in C++ is a locally define class with operator
() defines, but:
1) All the compilers I have used usually choke on this, especially with
optimization turned on (I don't know what the standard actually says about
doing this, though).
2) To access variables from "outer scopes" you would have to send them in
through the constructor.
"Jerry Coffin" <jc*****@taeus.com> writes: Robert A Duff wrote:
[ ... ]
If you really want to know about these languages that are being
discussed (Ada and C++) nothing beats reading a textbook or two.
Much as I hate to further my (undoubtedy bad) reputation for being
disagreeable, I still have to disagree.
If you follow-up the reading with some real use, it beats reading alone
by a wide margin, at least IME.
But I agree with that! Your reputation as disagreeable is ruined. ;-)
On the other hand, if you do "real use" by itself, you're liable to fall
into the trap of thinking that "what my compiler happens to do" is equal
to "the language definition".
- Bob
CTips <ct***@bestweb.net> writes: Dmitry A. Kazakov wrote:
On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote:
How easy is it to build an arena allocator in Ada?
It is trivial:
type Object is ...;
type Object_Ptr is access Object;
for Object_Ptr'Storage_Pool use My_Arena;
Here you are:
Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena
And how is My_Arena defined? Is it just a blob of memory? Or is it a
"class" that can invoke sbrk (or whatever) when it needs to?
Dmitry showed how to *use* an arena allocator. You (CTips) seem to be
asking how to write the code of the allocator itself.
Yes, it's ``a "class" that can invoke sbrk (or whatever)''.
That is, the code for Allocate and Deallocate are written by the
programmer to do whatever is necessary, and are called automatically by
"new" and "Unchecked_Deallocation". (Unchecked_Deallocation is like
free.) The "arena" allocator can of course do what it likes -- allocate
from a blob of memory, or allocate small pieces out of large chunks,
or request more memory from the OS (if there *is* an OS), etc.
I'm a little confused about what you (CTips) are asking.
Maybe you could clarify a bit... Note that Object can still be allocated on the stack or in any other
pool:
type Object_Universal_Ptr is access all Object;
This : Object;
-- This allocates it on the stack
That : Object_Universal_Ptr := new Object;
-- This will be in the(a) default pool (in the heap)
Given a processor with load-word-locked and store-word-conditional,
how would I build an atomic increment function?
Why should I have atomic increment function? Ada has native concurrency
support. But if somebody would need that extremely low level thing as
atomic integers, then:
protected type Atomic_Integer is
procedure Increment;
private
Value : Integer;
end Atomic_Integer;
-- Implementation
protected body Atomic_Integer is
procedure Increment is
begin
Value := Value + 1;
end Increment;
end Atomic_Integer;
Will that generate:
L0:
lwlock temp,&Value
add temp,temp,1
stwcond temp,&Value
if( failed ) goto L0;
or will it generate something much more heavy-weight.
It will generate something much more heavy-weight, but portable,
in most Ada compilers. If you want access to machine instructions,
you use machine code inserts, but of course you then lose portability.
I don't know of any Ada compiler that's smart enough to compile the
above into the most efficient code on machines that *do* have those
atomic instructions.
I thought this discussion was about C++ vs. Ada. Both allow
machine-code inserts. And (of course) machine-code is not portable.
I don't see any difference there.
- Bob fm**@tiscali.it wrote: In order to suppress all checks, with Ada we can use Pragma Suppress()
yet with C++ we have to write a totally different new code when you
don't want anymore checks (if using C++ "try .. catch" constructs).
And in the pragma, you can be explicit about which checks to suppress,
which entity to suppress them on, and what scope to do it in.
--
Wes Groleau
Trying to be happy is like trying to build a machine for which
the only specification is that it should run noiselessly.
-- unknown
Jerry Coffin wrote: Thinking of Java as a safer C++ betrays misundertanding of one (or
probably) both languages. Comparisons between Ada and C++ are at least
A misunderstanding shared by the inventors of Java?
I watched a 30-minute video tape in which they said
they kept having this and that problem, so they invented
a language that would not have those problems. One of them
held up for the camera a copy of some C++ book with lots of
things lined out and said something like, "Basically, we just
eliminated all this unsafe stuff."
--
Wes Groleau
There are some ideas so wrong that only a
very intelligent person could believe in them.
-- George Orwell
Pascal Obry wrote: That's not a misunderstanding. That's how Sun has described Java. They started
from C++ and have removed many unsafe features. They eventually stop the
process at some point and this has given birth to Java. That's history.
Although in at least one point they removed something that
Ada had already proved is not necessarily unsafe: operator
overloading. As a result, Java programmers either have to
give up both object-orienting and abstraction or use crap like
A.Multiply(2).Divide(B.negative().add(sqrt(B.squar ed().add(A.mult(2).mult(C)))
for things that are conceptually numeric.
--
Wes Groleau
If you put garbage in a computer nothing comes out but garbage.
But this garbage, having passed through a very expensive machine,
is somehow ennobled and none dare criticize it.
Jerry Coffin wrote: First of all, work on ARPAnet started out around the mid-1960's, but it
only became available to most of the public around the early 1990's or
so. Had development been delayed for 20 years or so until Ada compilers
were available, we'd be waiting another five years or so before it
became available to most of its current users.
And if development been delayed until C compilers were available?
--
Wes Groleau
"Grant me the serenity to accept those I cannot change;
the courage to change the one I can;
and the wisdom to know it's me."
-- unknown
Alberto wrote: As many people on this thread noticed, it was only a (bad?) joke. I
simply wanted to remark that I was somewhat tired of reading the same
story of Ada L. when some innocent soul dared to write "ADA" :)
From another newsgroup: "How can you expect to program in perl
if you can't even spell it?"
(not the exact words)
--
Wes Groleau
"Two things are infinite, the universe and human stupidity.
But I'm not so sure about the universe."
-- Albert Einstein
Dmitry A. Kazakov wrote: No, the difference is that the compiler *statically* knows that both I and
J will be in the bounds at run-time. There is no way (except for dirty
tricks with casting) how they might become out of the bounds. Therefore the
compiler can safely omit any checks.
Actually, the compiler will not allow any casting into
loop control variables. And if they were not loop control
variables, the compiler will add checks anywhere that can
be reached from code that has done such a conversion.
--
Wes Groleau
After the christening of his baby brother in church, Jason sobbed
all the way home in the back seat of the car. His father asked him
three times what was wrong. Finally, the boy replied, "That preacher
said he wanted us brought up in a Christian home, and I wanted to
stay with you guys."
"Jerry Coffin" writes: Short of using things like casts that are designed specifically to
_prevent_ the compiler from giving warnings (and which have their
counterparts in Ada) what practices on the "wrong side" do you see
that a C++ compiler can't warn about?
Aliasing?
--
Ludovic Brenta.
"Jerry Coffin" writes: Martin Dowie wrote: Jerry Coffin wrote: > The subject at hand was the use of C++ in the air traffic control
> system.
>
> As such, X running on top of Windows and/or UNIX becomes relevant
> ONLY when tied to the development of air traffic control
> software. This page shows exactly that. A page only about X on
> Windows or UNIX would not.
Well, I don't think this is *big* news to anyone!
Perhaps not -- but the strong implication that C++ was NOT used in
such systems, seems to leave only two possible conclusions: the
person who made the implication was either ignorant or lying.
I prefer to think this WAS big news, meaning the implication was
simply an honest mistake rather than an outright lie, or the result
of such a shallow view as to ignore the majority of the system.
Many ATC systems have a GUI which runs on top of X and Motif.
Toolkits such as the one you referred to are designed to avoid C or
C++ programming when creating the GUI. Instead, the GUI is generated
from point-and-click interfaces. That's fine by me.
Any tool that helps avoid mistakes or catch mistakes early is IMHO
good. Eventually, all tools end up generating machine code anyway.
It's just that Ada is better than C++ for safety-critical software.
Code generators can also help, even if they generate unreadable C or
C++ or machine code.
Even in Barco's avionics displays, part of the software is in C, but
generated from a GUI code generator. Our customers are usually
responsible for this (since they define the graphical appearance of
the display), so we don't worry too much about that. But buffer
overflows have been known to happen in the generated code during
testing :)
I maintain that most of Eurocontrol's software is written in Ada. I
think there was an old issue of the Ada User Journal detailing this.
I'm not sure about the GUI however; how much of it is generated I
don't know.
--
Ludovic Brenta.
Jerry Coffin wrote: Pascal Obry wrote:
"Jerry Coffin" <jc*****@taeus.com> writes:
Your claim of fewer bugs is just the sort of unsupported anti-C
comment we see all the time.
Just plain wrong, there is data (a PHD) see
http://www.adaic.com/whyada/ada-vs-c/cada_art.html
Ok, what about this paper: http://www.praxis-his.com/pdfs/c_by_...er_cheaper.pdf
In particular the company audited by the UK MoD on the 3rd page showed
interesting results. I work for the company audited and I'm sure the
audit is post-1995 by some margin (when I was no longer working there),
and by your own argument, by 1990 the compilers were pretty close to
standard C, yet this study still found a 10*defect rate in C than in
Ada... and a 100* defect rate compared to SPARK...
Yet, this sort of report seems all to common to me. Every language since
'C' has had at least 1 report that shows how brilliant it is at compared
to 'C', yet 'C' is still the most widely spread language. Why?
I think we perhaps need a psychologists view rather than looking at
language differences. Are humans 'hooked' on tracking down /really/
tricky null pointer dereference problems? Is it really just a fight for
'silver back status' coz 'my programs compile to 1 long word less than
yours'?...
Cheers
-- Martin
Martin Dowie wrote: interesting results. I work for the company audited and I'm sure the
That should have read "I worked for the...".
Cheers
-- Martin
REH wrote: Ada allows you to define a primative type (int, etc.) that is "distinct"
from others. This is nice for overload resolution, etc.
I know, but being about to write "is new integer" is a lot simplier than
creating a class just to create a "unique" integer type. Plus. since it is
a unique type I can define its exact size in bits which make portabililty
easier:
type Byte is new integer range 0 .. 16#ff#;
for Byte'size use 8;
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.
--
Ioannis Vranos http://www23.brinkster.com/noicys
Robert A Duff wrote:
[ ... ] If you follow-up the reading with some real use, it beats reading
alone by a wide margin, at least IME.
But I agree with that! Your reputation as disagreeable is ruined.
;-)
Pardon my being blunt, but Damn! The one thing I was good at is ruined!
On the other hand, if you do "real use" by itself, you're liable to
fall into the trap of thinking that "what my compiler happens to do"
is equal to "the language definition".
This, unfortunately, is all too true.
--
Later,
Jerry.
The universe is a figment of its own imagination. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mediocre Person |
last post by:
Well, after years of teaching grade 12 students c++, I've decided to
make a switch to Python.
Why?
* interactive mode for learning
* less fussing with edit - compile - link - run - debug -...
|
by: Gabriel Zachmann |
last post by:
This post is not strictly Python-specific, still
I would like to learn other university teachers' opinion.
Currently, I'm teaching "introduction to OO programming" at the undergrad
level. My...
|
by: andy_irl |
last post by:
Hi there
I have been asked to teach HTML to a group in our local village
community. It is nothing too serious, just a community development
grant aided scheme. It will be a 10 week course of two...
|
by: Pierre Senellart |
last post by:
I am going to teach a basic Web design course (fundamentals of HTML/CSS,
plus some basic client-side (JavaScript) and server-side (PHP, perhaps
XSLT) scripting). Most of the students do not have...
|
by: msnews.microsoft.com |
last post by:
I am teaching C# to my 11 year old child. One challenge is that all the C#
books I own and that I have seen in bookstores are full of language that is
not easily comprehended by a student at that...
|
by: Richard Aubin |
last post by:
I'm really new to vb.net programming and programming in general.
I would like to teach myself on how to program effectively and I have the
financial and time resources to do so.
Can I anyone...
|
by: e.expelliarmus |
last post by:
check this out buddies. kool website for:
* hacking and anti hacking tricks
* anti hackng tricks.
* registry tweaks
* orkut tricks
* small virus
* computer tricks
and loads of different...
|
by: JosAH |
last post by:
Greetings,
Introduction
This week's tip describes a few old tricks that are almost forgotten by most
people around here. Sometimes there's no need for these tricks anymore because
processors...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
