* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
@ 2002-06-14 8:05 ` David Marceau
2002-06-14 12:31 ` Dale Stanbrough
` (3 more replies)
2002-06-14 8:25 ` Dmitry A. Kazakov
` (4 subsequent siblings)
5 siblings, 4 replies; 80+ messages in thread
From: David Marceau @ 2002-06-14 8:05 UTC (permalink / raw)
Dale Stanbrough wrote:
>
> Ted Dennison wrote:
>
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
>
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
>
> Just thinking about it, don't Ada's "non constructor" construcor
> functions require you to build items on the heap, then copy them
> into the variable, rather than bulding them inplace?
>
> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions to/from
> the appropriate format just to find out what -really- went wrong?
>
> ...and doesn't the representation of holey enumerated types cause
> a lot of run time processing?
I don't remember seeing anything in the ada95 rationale or the reference
manual mentioning
"minimize run-time processing" as part of the ada language design
intent.
IMHO I believe this is a feature since the ada run-time
deliberately sacrifices optimum execution speed
in order to achieve higher-levels of reliability
via many invisible implicit checks on stuff
every time you call a different service.
I grant java does some similar checks here but with the JIT tweaking
code, certainty in execution behaviour is reduced.
I grant the java exception handling similar to ada
however the java threading/runnable and concurrency infrastructure are
an after-thought
because they are not part of the java language itself.
In other words one of the best kept secrets on the planet is that ada
run-time and exception handling
is much richer than java in terms of depth and breadth when dealing with
tasking and concurrency.
As an example read in the ada rationale documentation what it has to say
about tasks and you will see what I mean. Lots of stuff here. It shows
much depth and breadth in terms of expertise went into the
documentation. Warns the user of issues that may need to be dealt with
in certain specified situations.
Then read the java thread/runnable docs and you will find it much
simpler and a joy to read. Just follow the recipe and everything will
be fine :)
Which one describes the more realistic scenario when concurrency is
involved? IMHO ada.
>
> I could go on, but i can't think of any others (at the moment!) :-)
>
> Dale
That's interesting IMHO these all ADA FEATURES and not ada bugs :)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 8:05 ` David Marceau
@ 2002-06-14 12:31 ` Dale Stanbrough
2002-06-14 15:08 ` Darren New
` (2 subsequent siblings)
3 siblings, 0 replies; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-14 12:31 UTC (permalink / raw)
David Marceau wrote:
> >
> > ...and doesn't the representation of holey enumerated types cause
> > a lot of run time processing?
> I don't remember seeing anything in the ada95 rationale or the reference
> manual mentioning
> "minimize run-time processing" as part of the ada language design
> intent.
Interesting, but that's not what the original question was.
The person was wondering what features of Ada caused it to
run slow (i'm not sure what the exact wording was). I'm answering
his question.
> That's interesting IMHO these all ADA FEATURES and not ada bugs :)
ok.
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 8:05 ` David Marceau
2002-06-14 12:31 ` Dale Stanbrough
@ 2002-06-14 15:08 ` Darren New
2002-06-17 0:17 ` Robert A Duff
2002-06-14 19:05 ` Wes Groleau
2002-06-16 3:32 ` Dale Stanbrough
3 siblings, 1 reply; 80+ messages in thread
From: Darren New @ 2002-06-14 15:08 UTC (permalink / raw)
David Marceau wrote:
> however the java threading/runnable and concurrency infrastructure are
> an after-thought
> because they are not part of the java language itself.
Of course they are. Or are you forgetting "synchronized"? That "Thread" is a
class in Java doesn't mean it's not built in. Or would you consider
controlled types not a part of the language in Ada?
> In other words one of the best kept secrets on the planet is that ada
> run-time and exception handling
> is much richer than java in terms of depth and breadth when dealing with
> tasking and concurrency.
But this is true. It's clear that Ada put a lot more effort into building
tasking that's useful and powerful for real applications, rather than
tasking to try to make synchronous I/O into asynchronous I/O.
Note to language and OS designers: Synchonous I/O is a special case of
asynchronous I/O, not vice versa!
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
My brain needs a "back" button so I can
remember where I left my coffee mug.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 8:05 ` David Marceau
2002-06-14 12:31 ` Dale Stanbrough
2002-06-14 15:08 ` Darren New
@ 2002-06-14 19:05 ` Wes Groleau
2002-06-16 3:34 ` Dale Stanbrough
2002-06-16 3:32 ` Dale Stanbrough
3 siblings, 1 reply; 80+ messages in thread
From: Wes Groleau @ 2002-06-14 19:05 UTC (permalink / raw)
> > ...and doesn't the representation of holey enumerated types cause
> > a lot of run time processing?
IF you declare such a type, then SOME operations
on that type MAY be a little slower. No other
operations will be affected.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 19:05 ` Wes Groleau
@ 2002-06-16 3:34 ` Dale Stanbrough
0 siblings, 0 replies; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-16 3:34 UTC (permalink / raw)
Wes Groleau wrote:
>
> IF you declare such a type, then SOME operations
> on that type MAY be a little slower. No other
> operations will be affected.
Yes, i wasn't saying that the (unused) presence of that feature in
the language causes a program to run more slowly.
I should have spelt it out more clearly, but I was simply throwing
out some quick pointers to someone who (IMHO) was doing an
assignment/had some other barrow to push.
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 8:05 ` David Marceau
` (2 preceding siblings ...)
2002-06-14 19:05 ` Wes Groleau
@ 2002-06-16 3:32 ` Dale Stanbrough
3 siblings, 0 replies; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-16 3:32 UTC (permalink / raw)
David Marceau wrote:
> I don't remember seeing anything in the ada95 rationale or the reference
> manual mentioning
> "minimize run-time processing" as part of the ada language design
> intent.
You haven't looked hard enough. It's in the introduction to design of
Ada83 (and prob. still in the intro to Ada95) that run time efficiency
was an important factor in the design.
They got it wrong in a couple of cases - notably rendezvous (as the
only sync mechanism), and holey representation clauses for enumeration
types (...when you iterate over them with a for loop, or use them
as an index into an array).
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
2002-06-14 8:05 ` David Marceau
@ 2002-06-14 8:25 ` Dmitry A. Kazakov
2002-06-14 12:19 ` Immanuel Scholz
2002-06-14 12:58 ` Larry Kilgallen
` (3 subsequent siblings)
5 siblings, 1 reply; 80+ messages in thread
From: Dmitry A. Kazakov @ 2002-06-14 8:25 UTC (permalink / raw)
On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:
>Just thinking about it, don't Ada's "non constructor" construcor
>functions require you to build items on the heap, then copy them
>into the variable, rather than bulding them inplace?
I believe, in worst case, they will be copied from the stack.
There are IMO more serious problems with OO in Ada, but most of them
can be addressed to other languages as well. Others, like non-OO task
and protected object types, can be excused by the fact that other
languages have no such types at all.
---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 8:25 ` Dmitry A. Kazakov
@ 2002-06-14 12:19 ` Immanuel Scholz
2002-06-14 14:51 ` Dmitry A. Kazakov
0 siblings, 1 reply; 80+ messages in thread
From: Immanuel Scholz @ 2002-06-14 12:19 UTC (permalink / raw)
Dmitry A. Kazakov wrote:
> On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
> <dale@cs.rmit.edu.au> wrote:
>
>>Just thinking about it, don't Ada's "non constructor" construcor
>>functions require you to build items on the heap, then copy them
>>into the variable, rather than bulding them inplace?
>
> I believe, in worst case, they will be copied from the stack.
Is there any difference (left alone cache missis) in copying from heap or
copying from stack?
> There are IMO more serious problems with OO in Ada, but most of them
> can be addressed to other languages as well. Others, like non-OO task
> and protected object types, can be excused by the fact that other
> languages have no such types at all.
no "protected" state is IMHO an advantage. I think protected members are
evil doing more harm than good, but this is antoher story.;-)
Immanuel Scholz
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 12:19 ` Immanuel Scholz
@ 2002-06-14 14:51 ` Dmitry A. Kazakov
2002-06-14 15:09 ` Darren New
0 siblings, 1 reply; 80+ messages in thread
From: Dmitry A. Kazakov @ 2002-06-14 14:51 UTC (permalink / raw)
On Fri, 14 Jun 2002 14:19:14 +0200, Immanuel Scholz
<news@kutzsche.net> wrote:
>Dmitry A. Kazakov wrote:
>
>> On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
>> <dale@cs.rmit.edu.au> wrote:
>>
>>>Just thinking about it, don't Ada's "non constructor" construcor
>>>functions require you to build items on the heap, then copy them
>>>into the variable, rather than bulding them inplace?
>>
>> I believe, in worst case, they will be copied from the stack.
>
>Is there any difference (left alone cache missis) in copying from heap or
>copying from stack?
Surely. Heap allocation/deallocation is very expensive as compared
with stack ones. Things getting even worse in a multiprocessor system
where heap is shared, so a spin lock must be taken. Then heap
management might have an unbouded time [=inacceptable for real-time
systems].
>> There are IMO more serious problems with OO in Ada, but most of them
>> can be addressed to other languages as well. Others, like non-OO task
>> and protected object types, can be excused by the fact that other
>> languages have no such types at all.
>
>no "protected" state is IMHO an advantage. I think protected members are
>evil doing more harm than good, but this is antoher story.;-)
Actually I meant Ada's protected objects and not the visibility rules.
There is a great need to have protected objects extensible (tagged).
At the same time it is not very clear (at least to me), how to do it.
As for protected members in C++ sense, I believe that Ada's "private"
is closer to C++ "protected", than to "private", when child packages
or derived types are considered.
---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 14:51 ` Dmitry A. Kazakov
@ 2002-06-14 15:09 ` Darren New
2002-06-16 22:49 ` Dmitry A.Kazakov
0 siblings, 1 reply; 80+ messages in thread
From: Darren New @ 2002-06-14 15:09 UTC (permalink / raw)
"Dmitry A. Kazakov" wrote:
> Actually I meant Ada's protected objects and not the visibility rules.
> There is a great need to have protected objects extensible (tagged).
> At the same time it is not very clear (at least to me), how to do it.
What's wrong with Java's approach to OO threading and protected objects?
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
My brain needs a "back" button so I can
remember where I left my coffee mug.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 15:09 ` Darren New
@ 2002-06-16 22:49 ` Dmitry A.Kazakov
2002-06-16 15:07 ` Jim Rogers
2002-06-17 3:59 ` Darren New
0 siblings, 2 replies; 80+ messages in thread
From: Dmitry A.Kazakov @ 2002-06-16 22:49 UTC (permalink / raw)
Darren New wrote:
> "Dmitry A. Kazakov" wrote:
>> Actually I meant Ada's protected objects and not the visibility rules.
>> There is a great need to have protected objects extensible (tagged).
>> At the same time it is not very clear (at least to me), how to do it.
>
> What's wrong with Java's approach to OO threading and protected objects?
I do not know Java good enough to judge. But the problems as I see them are
mostly with MD and MI. Java has no MD. Ada has neigher. But if it had, how
to call on an entry point that belongs to two protected objects, or else
tasks? Consider imaginary:
task type A;
task type B;
entry Do_It (First : in out A; Second : in out B); -- Of both A and B
task type C is new A with ...;
entry Do_It (First : in out C; Second : in out B); -- Overrides in A
X : A'Class := ...; Y : B'Class := ...;
begin
select
Do_It (X, Y); -- Dispatching entry call
...
What about freezing rules with MD? May I override barriers? How to override
the body an entry point of a task? How to inherit an entry point? How to
add a new entry point? From a caller view point, there is no difference
between entry points of tasks and protected objects, should then exist a
common parent type for them? Should caller know any difference between an
entry point and a subroutine? Isn't that an implementation detail? If so,
how to [efficiently] implement entry points with a return parameter? Or
should we introduce generic formal entry points, protected type, task type
parameters?
I suspect lots of pitfalls here. However, ask more knowledgeable people
than me ...
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 22:49 ` Dmitry A.Kazakov
@ 2002-06-16 15:07 ` Jim Rogers
2002-06-17 4:06 ` Darren New
2002-06-17 3:59 ` Darren New
1 sibling, 1 reply; 80+ messages in thread
From: Jim Rogers @ 2002-06-16 15:07 UTC (permalink / raw)
> Darren New wrote:
>
>
>>"Dmitry A. Kazakov" wrote:
>>
>>>Actually I meant Ada's protected objects and not the visibility rules.
>>>There is a great need to have protected objects extensible (tagged).
>>>At the same time it is not very clear (at least to me), how to do it.
>>>
>>What's wrong with Java's approach to OO threading and protected objects?
>>
There are actually a number of problems with Java's approach to OO
threading and protected objects.
The first problem is that Java does not have protected objects in the
Ada sense of the term. Java only provides synchronization blocks, which
are not even close to being protected objects.
Java's threading model works very well as long as your threads do not
communicate with each other, and they never need to be terminated.
Of course, many useful concurrent designs do need to have
communication between tasks, and those tasks need to be terminated
as some point in the program.
The only safe communication feature for Java threads is synchronized
blocks. The code in the synchronized block belongs to the shared
object. That object might be one of the threads, or a shared object.
Let's look at a classical concurrent design, the producer/consumer
model. Any decent threading implementation should be able to
properly support a producer/consumer model. Let's assume that our
application needs reliable communication between the producer thread
and the consumer thread. We will use a bounded queue between the
producer and the consumer. The producer must not write to the bounded
queue when it is full, and the consumer must not read from the
bounded queue when it is empty. In Ada this would be handled simply
using a protected object with two entries; one to add elements to
the bounded queue, and one to extract elements from the bounded queue.
In Java you will create your bounded queue class. You will provide two
methods, one to add elements to the queue and one to extract elements
from the queue. Each of these methods must be declared synchronized.
Under Java rules you must call the synchronized block, and obtain the
synchronization lock before you can check for conditions such as
queue full or queue empty. If the producer is calling the add element
method and the queue is full the wait() method must be called to
suspend the producer. Note that the producer class has no control
over this code. It merely calls the method defined in the bounded
queue class. There is no Java equivalent to the Ada timed select
statement allowing an Ada task to limit its suspension time on an
entry call. In Java the producer will be suspended until another
thread, in this case the consumer, calls the notify() or the
notifyAll() method. The notify() method randomly unsuspends one
suspended thread, no matter which synchronization block it is waiting
for. The notifyAll() method unsuspends all suspended threads, forcing
each to check whether or not it should proceed. If not, it must be
immediately re-suspended using a wait() call.
Note that all this re-checking and waiting is still occuring in the
code for the synchronized object, not at all under control of the
producer thread. How do we design this so that the producer can
have an effective timeout on its suspension? We could design the
bounded queue code so that it provides a fixed timeout period for
all threads that may be suspended. The problem here is that this
forces all threads calling this synchronized block to have
the same timing requirements. You could allow the calling thread
to pass a timeout value to the synchronized block. This forces you
to reveal internal state of your thread to another object, violating
encapsulation principles.
Given the behavior of the notify() and the notifyAll() methods there
is no guarantee that a given thread will ever progress past a set
of wait/notify calls to execute the bulk of the synchronized block.
Java provides nothing like an Ada entry queue. Thus, the order in
which threads are unsuspended is not deterministic.
Let's turn now to the issue of terminating a thread. Java provides a
stop() method to terminate a thread. Java has also deprecated the
use of this method because it has been found to be unsafe. The
problem is that the stop() method does not release any synchronization
locks currently held by the thread being stopped. This easily
results in starvation because no other thread will be allowed to
acquire the synchronization lock. The current Java solution is to
require the programmer to invent his own termination method which
some other method will call. Of course, that termination condition
will not be serviced until the "terminated" thread has returned from
all synchronized blocks, which as I have shown above, may never
happen.
Jim Rogers
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 15:07 ` Jim Rogers
@ 2002-06-17 4:06 ` Darren New
2002-06-17 4:52 ` Jim Rogers
0 siblings, 1 reply; 80+ messages in thread
From: Darren New @ 2002-06-17 4:06 UTC (permalink / raw)
Jim Rogers wrote:
> The first problem is that Java does not have protected objects in the
> Ada sense of the term. Java only provides synchronization blocks, which
> are not even close to being protected objects.
If every routine of a class is declared synchronized, I think you get
something close to protected objects as long as you're not doing real-time,
not worried about priority inversion, and etc. All of which Ada gets right,
of course. Which you amply demonstrate in your post.
> Java's threading model works very well as long as your threads do not
> communicate with each other,
Basically, you have to build your own entry queues in Java's threads, just
like you had to build your own protected objects in Ada 83.
> and they never need to be terminated.
I'm pretty sure you can force a Java thread to throw an error, thereby
terminating.
Anyway, I was commenting not on the fact that Java is better or worse than
Ada in terms of tasking. Clearly Ada wins hands down over any other GP
language. All I was addressing was
> >> like non-OO task
> >> and protected object types, can be excused by the fact that other
> >> languages have no such types at all.
and wondering why the poster felt that Java didn't have tasks or protected
types. I didn't literally mean "what's wrong with Java's threads", but
rather "why do you feel they're so broken that you don't even call them
threads?"
> problem is that the stop() method does not release any synchronization
> locks currently held by the thread being stopped. This easily
Ah. I was unaware that it was unsafe.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
My brain needs a "back" button so I can
remember where I left my coffee mug.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-17 4:06 ` Darren New
@ 2002-06-17 4:52 ` Jim Rogers
2002-06-17 9:45 ` David Marceau
2002-06-17 15:42 ` Darren New
0 siblings, 2 replies; 80+ messages in thread
From: Jim Rogers @ 2002-06-17 4:52 UTC (permalink / raw)
Darren New wrote:
> Jim Rogers wrote:
>
>>The first problem is that Java does not have protected objects in the
>>Ada sense of the term. Java only provides synchronization blocks, which
>>are not even close to being protected objects.
>>
>
> If every routine of a class is declared synchronized, I think you get
> something close to protected objects as long as you're not doing real-time,
> not worried about priority inversion, and etc. All of which Ada gets right,
> of course. Which you amply demonstrate in your post.
I disagree. You get a lot of object locking, but a protected object
is much more than simple object locking. You do not get the ability
to do shared reads of the object as you get from Ada protected
functions. You get no equivalent to entry queues. You have no
equivalent to the Ada select command. You simply have built-in
syntax for manipulating an object-wide mutex.
Note that it is also extremely difficult in Java to simulate an
Ada rendezvous.
>
>
>>Java's threading model works very well as long as your threads do not
>>communicate with each other,
>>
>
> Basically, you have to build your own entry queues in Java's threads, just
> like you had to build your own protected objects in Ada 83.
I tried to describe why you cannot simply build your own entry queues
in Java. The problem is the Java definition of the wait() and
notify() methods. They control thread suspension and activation due
to changes in shared object conditions. They provide completely
non-deterministic results when activating a suspended thread. You
have no access to the way they work, nor can you redefine their
operation without encountering rather nasty behaviors in the Java
memory model, which is generally NOT implemented as defined for the
Java Virtual Machine.
>
>
>>and they never need to be terminated.
>>
>
> I'm pretty sure you can force a Java thread to throw an error, thereby
> terminating.
Yes, you can force a thread to throw an exception, but that means that
all your threads must declare that they throw whichever exception
you want to used. This is clearly an uncommon design choice in Java.
>
> Anyway, I was commenting not on the fact that Java is better or worse than
> Ada in terms of tasking. Clearly Ada wins hands down over any other GP
> language. All I was addressing was
>
>
>>>>like non-OO task
>>>>and protected object types, can be excused by the fact that other
>>>>languages have no such types at all.
>>>>
>
> and wondering why the poster felt that Java didn't have tasks or protected
> types. I didn't literally mean "what's wrong with Java's threads", but
> rather "why do you feel they're so broken that you don't even call them
> threads?"
Java does have threads. It clearly does not have protected types.
Instead it has an overly simple and primitive view of object locking
using a classic mutex.
Jim Rogers
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-17 4:52 ` Jim Rogers
@ 2002-06-17 9:45 ` David Marceau
2002-06-17 15:42 ` Darren New
1 sibling, 0 replies; 80+ messages in thread
From: David Marceau @ 2002-06-17 9:45 UTC (permalink / raw)
>
> I tried to describe why you cannot simply build your own entry queues
> in Java.
Concerning building something like entry queues, the following
book: High Performance Java Platform Computing
http://www.toolsofcomputing.com/JavaThreads/
describes an entire infrastructure of java classes which attempts to
compensate
for the lack of concurrency capability in the java language.
For example it describes an infrastructure for building a threadpool and
then using a
runnablequeue to feed them as each thread completes a runnable's task.
The book even mentions the MEMO and MPI infrastructures at the end
however it was very brief
and left the reader to figure out what they meant in their code.
As it stands it is the best java thread book out there.
> The problem is the Java definition of the wait() and
> notify() methods. They control thread suspension and activation due
> to changes in shared object conditions.
> They provide completely
> non-deterministic results when activating a suspended thread.
I hear you. Like the java language itself, all the java threading books
I read did not help
to save time when debugging run-time
erratic behaviour(like what you said non-deterministic
results i.e. memory leaks) in the application
caused by a mix of a concurrency class infrastructure mixed with human
coders.
I guess that makes me a bad debugger guy eh?
> You
> have no access to the way they work, nor can you redefine their
> operation without encountering rather nasty behaviors in the Java
> memory model, which is generally NOT implemented as defined for the
> Java Virtual Machine.
I hear you concerning the memory model :)
Java claims Garbage-Collection. Java doesn't garbage collect Thread
Classes.
This makes for a lot of coding work-arounds.
At least c/c++ never claimed to have garbage collection before
displaying memory leaks behaviour.
At least c/c++ coders deep down inside know their code isn't bullet
proof
until they add the defensive programming(a reasonable amount of checks
and exception handling stuff) and test it on the target (anywhere)
platform.
At least c/c++/ada have a debugger that can go anywhere and attach to
any process even a java process.
Sant� bonheur,
David Marceau
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-17 4:52 ` Jim Rogers
2002-06-17 9:45 ` David Marceau
@ 2002-06-17 15:42 ` Darren New
1 sibling, 0 replies; 80+ messages in thread
From: Darren New @ 2002-06-17 15:42 UTC (permalink / raw)
Jim Rogers wrote:
> Java does have threads. It clearly does not have protected types.
> Instead it has an overly simple and primitive view of object locking
> using a classic mutex.
OK, I'll agree with that. :-) I'd more say it uses academic-style locking
primitives, more appropriate for proving equivalence of mathematical
descriptions of multiprocessing than getting real work done. The
wait()/notify() stuff is almost as classic as P() and V(). :-)
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
My brain needs a "back" button so I can
remember where I left my coffee mug.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 22:49 ` Dmitry A.Kazakov
2002-06-16 15:07 ` Jim Rogers
@ 2002-06-17 3:59 ` Darren New
2002-06-17 22:19 ` Dmitry A.Kazakov
1 sibling, 1 reply; 80+ messages in thread
From: Darren New @ 2002-06-17 3:59 UTC (permalink / raw)
"Dmitry A.Kazakov" wrote:
> I do not know Java good enough to judge. But the problems as I see them are
> mostly with MD and MI. Java has no MD. Ada has neigher. But if it had, how
> to call on an entry point that belongs to two protected objects, or else
> tasks?
If I understand what you're saying, this isn't a problem in Java because
Java uses distinguished-receiver notation.
A.do_it(b) or B.do_it(a).
> What about freezing rules with MD? May I override barriers? How to override
> the body an entry point of a task? How to inherit an entry point? How to
> add a new entry point?
None of these are problems, because Java doesn't work it the same way that
Ada does.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
My brain needs a "back" button so I can
remember where I left my coffee mug.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-17 3:59 ` Darren New
@ 2002-06-17 22:19 ` Dmitry A.Kazakov
0 siblings, 0 replies; 80+ messages in thread
From: Dmitry A.Kazakov @ 2002-06-17 22:19 UTC (permalink / raw)
Darren New wrote:
> "Dmitry A.Kazakov" wrote:
>> I do not know Java good enough to judge. But the problems as I see them
>> are mostly with MD and MI. Java has no MD. Ada has neigher. But if it
>> had, how to call on an entry point that belongs to two protected objects,
>> or else tasks?
>
> If I understand what you're saying, this isn't a problem in Java because
> Java uses distinguished-receiver notation.
>
> A.do_it(b) or B.do_it(a).
There cannot be a distinguished receiver with MD. If both arguments are
dispatching which one is distinguished? Then if an entry belongs to TWO
tasks, it means that rendezvous happens with BOTH of them. As I said I do
not know Java, but I am pretty sure that it does not have such a thing.
>> What about freezing rules with MD? May I override barriers? How to
>> override the body an entry point of a task? How to inherit an entry
>> point? How to add a new entry point?
>
> None of these are problems, because Java doesn't work it the same way that
> Ada does.
That is what I meant. Other languages simply did not attemted to integrate
tasks and protected objects as deep and consistently as Ada does. So they
have no problems like that. Which only means that it is a poor programmer,
who shall solve them.
--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
2002-06-14 8:05 ` David Marceau
2002-06-14 8:25 ` Dmitry A. Kazakov
@ 2002-06-14 12:58 ` Larry Kilgallen
2002-06-14 22:16 ` Dale Stanbrough
2002-06-14 14:59 ` Ted Dennison
` (2 subsequent siblings)
5 siblings, 1 reply; 80+ messages in thread
From: Larry Kilgallen @ 2002-06-14 12:58 UTC (permalink / raw)
In article <dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>, Dale Stanbrough <dale@cs.rmit.edu.au> writes:
> Ted Dennison wrote:
>
>> But if you want real numbers that mean something, get the compilers you
>> would use if you were to pick that language, and compare their output
>> for the types of code you will be generating. Speed has way more to do
>> with the effort your compiler writers put into optimization than with
>> the language.
>
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions to/from
> the appropriate format just to find out what -really- went wrong?
The spirit of exception processing is that it is supposed to be done
on an infrequent basis. Performing giant sort in Cobol is more costly
than a simple multiplication in the same language.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 12:58 ` Larry Kilgallen
@ 2002-06-14 22:16 ` Dale Stanbrough
2002-06-15 1:22 ` Larry Kilgallen
0 siblings, 1 reply; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-14 22:16 UTC (permalink / raw)
(Larry Kilgallen wrote:
> > ...and doesn't the fact that the only way to attach information
> > to an exception is via a string, requiring conversions to/from
> > the appropriate format just to find out what -really- went wrong?
>
> The spirit of exception processing is that it is supposed to be done
> on an infrequent basis. Performing giant sort in Cobol is more costly
> than a simple multiplication in the same language.
?Maybe, but when you do need to use it, you may want to attach
information to the exception so that you can determine what
went wrong more precisely.
Java allows you to throw objects descended from the Exception class;
this seems like it could be quite handy at times.
I've not used it though, so i'm not sure -how- useful it is.
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 22:16 ` Dale Stanbrough
@ 2002-06-15 1:22 ` Larry Kilgallen
2002-06-15 0:51 ` Dale Stanbrough
2002-06-15 21:45 ` Robert A Duff
0 siblings, 2 replies; 80+ messages in thread
From: Larry Kilgallen @ 2002-06-15 1:22 UTC (permalink / raw)
In article <dstanbro-3384C9.08152215062002@news-server.bigpond.net.au>, Dale Stanbrough <dstanbro@bigpond.net.au> writes:
> (Larry Kilgallen wrote:
>
>> > ...and doesn't the fact that the only way to attach information
>> > to an exception is via a string, requiring conversions to/from
>> > the appropriate format just to find out what -really- went wrong?
>>
>> The spirit of exception processing is that it is supposed to be done
>> on an infrequent basis. Performing giant sort in Cobol is more costly
>> than a simple multiplication in the same language.
>
> ?Maybe, but when you do need to use it, you may want to attach
> information to the exception so that you can determine what
> went wrong more precisely.
Ah, so the issue is programming effort. I thought it was performance.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-15 1:22 ` Larry Kilgallen
@ 2002-06-15 0:51 ` Dale Stanbrough
2002-06-15 11:49 ` Immanuel Scholz
2002-06-15 21:45 ` Robert A Duff
1 sibling, 1 reply; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-15 0:51 UTC (permalink / raw)
Larry Kilgallen wrote:
> Ah, so the issue is programming effort. I thought it was performance.
The original poster was asking about both.
I would imagine that transforming objects into strings
could result in some performance penatly as well as requiring
more programming effort.
To convert arbitrary information to a string is fairly
straight forward (even allowing for flattening),
but going the other way isn't necessarily,
esp. as you have to determine exactly what type of object
the string represents.
You could utilise the streams feature to convert it to/from
in a standardised way, but to me that seems a lot of work
compared to the Java equivalent.
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-15 0:51 ` Dale Stanbrough
@ 2002-06-15 11:49 ` Immanuel Scholz
0 siblings, 0 replies; 80+ messages in thread
From: Immanuel Scholz @ 2002-06-15 11:49 UTC (permalink / raw)
Dale Stanbrough wrote:
> You could utilise the streams feature to convert it to/from
> in a standardised way, but to me that seems a lot of work
> compared to the Java equivalent.
Yes, and also this would drop your coding style to a level of "unsage
typecasts".
(Theoretically you can cover _all_ variable types by just use a unique
string-representation and parse them at need ;-)
I think the idea of exceptions in Ada are more restrictive than in other
languages as Java. In Java it is a more or fewer "normal" exit state of any
function to raise an exception on error conditions (e.g. File not found,
Disk full, invalid xml-document etc.)
In Ada, I guess, exceptions have only to be thrown in real critical
situations, where something unpredictable have been done, as violating the
contract with a function. In this case, exception is more an assert than an
java.lang.Exception.
Am I right?
What is the real practise use of exceptions in Ada?
Immanuel Scholz
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-15 1:22 ` Larry Kilgallen
2002-06-15 0:51 ` Dale Stanbrough
@ 2002-06-15 21:45 ` Robert A Duff
1 sibling, 0 replies; 80+ messages in thread
From: Robert A Duff @ 2002-06-15 21:45 UTC (permalink / raw)
Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> Ah, so the issue is programming effort. I thought it was performance.
I think the issue is type safety.
If you're going to attach information to exceptions, you want to declare
the *type* of that information at the point of the exception
declaration, to ensure that the raiser and the handler agree on that
contract. Many languages, including Java, support that capability. In
Ada, you can't do it, because you have to convert any such data to
String.
- Bob
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
` (2 preceding siblings ...)
2002-06-14 12:58 ` Larry Kilgallen
@ 2002-06-14 14:59 ` Ted Dennison
2002-06-16 3:27 ` Dale Stanbrough
2002-06-14 15:00 ` Ted Dennison
2002-06-14 18:52 ` Jeffrey Carter
5 siblings, 1 reply; 80+ messages in thread
From: Ted Dennison @ 2002-06-14 14:59 UTC (permalink / raw)
Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>...
> Ted Dennison wrote:
>
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
>
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
You are missing the entire point. We could sit here all day and come
up with weird constructions for each language in question that go slow
on some compilers. What matters when you talk about speed is how
quickly the code generated by your compiler runs your kinds of
applications. If there's an unbelieveably slow feature in there, and
that feature isn't used in this particular person's code in a tight
loop somewhere, its not going to have any impact whatsoever on their
percieved performance.
--
T.E.D.
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - (temporarily down)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 14:59 ` Ted Dennison
@ 2002-06-16 3:27 ` Dale Stanbrough
2002-06-16 22:18 ` Wes Groleau
2002-06-16 22:38 ` Ted Dennison
0 siblings, 2 replies; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-16 3:27 UTC (permalink / raw)
Ted Dennison wrote:
> > async abort is one counter example of this. The definition is such
> > that programs take a hit in efficiency (or so i have read in this
> > newsgroup).
>
> You are missing the entire point. We could sit here all day and come
> up with weird constructions for each language in question that go slow
> on some compilers. What matters when you talk about speed is how
> quickly the code generated by your compiler runs your kinds of
> applications. If there's an unbelieveably slow feature in there, and
> that feature isn't used in this particular person's code in a tight
> loop somewhere, its not going to have any impact whatsoever on their
> percieved performance.
No, async abort requires the compiler to include all sorts of
extra mutexes (or polling points) throughout the code, to ensure
that abort deferred actions are, well, abort deferred!
The original questions were (partly) about features in Ada that make
it go slow, and async abort is one of them. Don't use it and your
code goes fast. Even the presence of it in an if statement...
if <some condition that is rarely true> then
abort <some task>;
end if;
causes the program to go slower. It doesn't really matter what
compiler you use.
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 3:27 ` Dale Stanbrough
@ 2002-06-16 22:18 ` Wes Groleau
2002-06-16 22:38 ` Ted Dennison
1 sibling, 0 replies; 80+ messages in thread
From: Wes Groleau @ 2002-06-16 22:18 UTC (permalink / raw)
> The original questions were (partly) about features in Ada that make
> it go slow, and async abort is one of them. Don't use it and your
> code goes fast. Even the presence of it in an if statement...
Even if you don't use it, support for it in the run-time
MIGHT slow you down. But if the compiler (or compiler vendor)
is smart enough....
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 3:27 ` Dale Stanbrough
2002-06-16 22:18 ` Wes Groleau
@ 2002-06-16 22:38 ` Ted Dennison
1 sibling, 0 replies; 80+ messages in thread
From: Ted Dennison @ 2002-06-16 22:38 UTC (permalink / raw)
Dale Stanbrough wrote:
>>You are missing the entire point. We could sit here all day and come
>>up with weird constructions for each language in question that go slow
>>on some compilers. What matters when you talk about speed is how
>>quickly the code generated by your compiler runs your kinds of
>>applications. If there's an unbelieveably slow feature in there, and
>>that feature isn't used in this particular person's code in a tight
>>loop somewhere, its not going to have any impact whatsoever on their
>>percieved performance.
>
> No, async abort requires the compiler to include all sorts of
..
> it go slow, and async abort is one of them. Don't use it and your
> code goes fast. Even the presence of it in an if statement...
(sigh)
So you yourself admit this doesn't slow anything down unless its used. I
know for a fact I've never used async abort, and I suspect if we took a
poll, we'd find exceedingly few Ada programs in general use it. There
are plenty of things in *any* language that you should avoid if you care
about speed, so this is hardly unique to Ada. If its an obscure feature
that's almost never used, why bring it up as something that "makes Ada
go slow", particularly when C++ is chock full of such features?
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
` (3 preceding siblings ...)
2002-06-14 14:59 ` Ted Dennison
@ 2002-06-14 15:00 ` Ted Dennison
2002-06-14 20:13 ` Wes Groleau
2002-06-14 18:52 ` Jeffrey Carter
5 siblings, 1 reply; 80+ messages in thread
From: Ted Dennison @ 2002-06-14 15:00 UTC (permalink / raw)
Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>...
> Ted Dennison wrote:
>
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
>
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
You are missing the entire point. We could sit here all day and come
up with weird constructions for each language in question that go slow
on some compilers. What matters when you talk about speed is how
quickly the code generated by your compiler runs your kinds of
applications. If there's an unbelieveably slow feature in there, and
that feature isn't used in this particular person's code in a tight
loop somewhere, its not going to have any impact whatsoever on their
percieved performance.
--
T.E.D.
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - (temporarily down)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 15:00 ` Ted Dennison
@ 2002-06-14 20:13 ` Wes Groleau
0 siblings, 0 replies; 80+ messages in thread
From: Wes Groleau @ 2002-06-14 20:13 UTC (permalink / raw)
> You are missing the entire point. We could sit here all day and come
> up with weird constructions for each language in question that go slow
> on some compilers. What matters when you talk about speed is how
> quickly the code generated by your compiler runs your kinds of
> applications. If there's an unbelieveably slow feature in there, .../
> [snip]
... then the solution is not automatically "use a different language."
It might be "use a different compiler."
I know that's what people have been saying;
I just thought I'd make sure it was clear. :-)
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 4:35 ` Dale Stanbrough
` (4 preceding siblings ...)
2002-06-14 15:00 ` Ted Dennison
@ 2002-06-14 18:52 ` Jeffrey Carter
2002-06-15 22:03 ` Robert A Duff
2002-06-16 22:20 ` Wes Groleau
5 siblings, 2 replies; 80+ messages in thread
From: Jeffrey Carter @ 2002-06-14 18:52 UTC (permalink / raw)
Dale Stanbrough wrote:
>
> Ted Dennison wrote:
>
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
>
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
A counter example of what? Of the languages under consideration, which
ones have async abort (in addition to Ada)? Of those, which ones have it
defined in such a way as to guarantee that implementations in those
languages must always be faster than implementations in Ada?
>
> Just thinking about it, don't Ada's "non constructor" construcor
> functions require you to build items on the heap, then copy them
> into the variable, rather than bulding them inplace?
No. The language allows initialization in place. It does not require it.
If it's important to you, then your compiler selection process should
take this into account.
>
> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions to/from
> the appropriate format just to find out what -really- went wrong?
This seems to be an incomplete sentence. If I interpret it correctly,
the Ada intent is that the information be carried primarily by the
exception name. You should not be using a single exception and
differentiating between logical exceptions by the information attached
to that exception.
Also, exceptions should only be used for exceptional situations, so this
does not impact normal processing at all.
>
> ...and doesn't the representation of holey enumerated types cause
> a lot of run time processing?
I think you misspelled "holy" :)
Only if they're misused.
--
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 18:52 ` Jeffrey Carter
@ 2002-06-15 22:03 ` Robert A Duff
2002-06-16 1:58 ` Jeffrey Carter
2002-06-16 22:20 ` Wes Groleau
1 sibling, 1 reply; 80+ messages in thread
From: Robert A Duff @ 2002-06-15 22:03 UTC (permalink / raw)
Jeffrey Carter <jrcarter@acm.org> writes:
> This seems to be an incomplete sentence. If I interpret it correctly,
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.
The problem with this view is that it forces the designer of an
abstraction to decide on the granularity of exception handling, when
this decision rightly belongs in the hands of the person designing the
*handler*. In fact, different handlers have different requirements:
e.g., one handler might want to handle all I/O errors, whereas another
one might want to handle disk_full_error specially. If the designer of
the abstraction decided to lump all I/O errors under one exception name,
then the fine-grained handler is impossible to write. On the other
hand, if the designer of the abstraction defined many exceptions for
different kinds of I/O errors, then the coarse-grained handler has to
mention them all, which is overly verbose, and unmaintainable, because
there might be a new kind of I/O error invented tomorrow.
So the designer of the abstraction is forced into a poor design for
*some* possible clients. This is not good for reusability.
In many other languages, this problem does not occur, because exceptions
are defined hierarchically.
> Also, exceptions should only be used for exceptional situations, so this
> does not impact normal processing at all.
I don't see how that's relevant. A bug in exception handling is a bug,
even though exceptions occur only rarely. (In fact, *all* bugs are rare
-- if the thing crashes within seconds most of the time you run it, the
programmer will notice it and fix it.)
- Bob
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-15 22:03 ` Robert A Duff
@ 2002-06-16 1:58 ` Jeffrey Carter
2002-06-16 3:19 ` Dale Stanbrough
0 siblings, 1 reply; 80+ messages in thread
From: Jeffrey Carter @ 2002-06-16 1:58 UTC (permalink / raw)
Robert A Duff wrote:
>
> Jeffrey Carter <jrcarter@acm.org> writes:
>
> > This seems to be an incomplete sentence. If I interpret it correctly,
> > the Ada intent is that the information be carried primarily by the
> > exception name. You should not be using a single exception and
> > differentiating between logical exceptions by the information attached
> > to that exception.
>
> The problem with this view is that it forces the designer of an
> abstraction to decide on the granularity of exception handling, when
> this decision rightly belongs in the hands of the person designing the
> *handler*. In fact, different handlers have different requirements:
> e.g., one handler might want to handle all I/O errors, whereas another
> one might want to handle disk_full_error specially. If the designer of
> the abstraction decided to lump all I/O errors under one exception name,
> then the fine-grained handler is impossible to write. On the other
> hand, if the designer of the abstraction defined many exceptions for
> different kinds of I/O errors, then the coarse-grained handler has to
> mention them all, which is overly verbose, and unmaintainable, because
> there might be a new kind of I/O error invented tomorrow.
I disagree. The designer of the abstraction has no choice; he must use
fine-grained exceptions so that a client with fine-grained handling
needs is not excluded. This is true regardless of whether the language
has hierarchical exceptions.
However, this is irrelevant to the original post to which I was
replying. It claimed that the use of String to attach information to an
exception made exceptions in Ada inherently slow.
> > Also, exceptions should only be used for exceptional situations, so this
> > does not impact normal processing at all.
>
> I don't see how that's relevant. A bug in exception handling is a bug,
> even though exceptions occur only rarely.
Again, this was in the context of exceptions impacting execution speed,
not of errors.
--
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 1:58 ` Jeffrey Carter
@ 2002-06-16 3:19 ` Dale Stanbrough
0 siblings, 0 replies; 80+ messages in thread
From: Dale Stanbrough @ 2002-06-16 3:19 UTC (permalink / raw)
Jeffrey Carter wrote:
>
> However, this is irrelevant to the original post to which I was
> replying. It claimed that the use of String to attach information to an
> exception made exceptions in Ada inherently slow.
I didn't say it made the language inherently slow. I said that it made
it more difficult to program some things in Ada.
It could also make it slower, however.
> Again, this was in the context of exceptions impacting execution speed,
> not of errors.
Your reply was...
> This seems to be an incomplete sentence. If I interpret it correctly,
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.
> Also, exceptions should only be used for exceptional situations, so this
> does not impact normal processing at all.
I didn't notice anything in your reply that mentioned execution speed.
My (malformed) comment was...
...and doesn't the fact that the only way to attach information
to an exception is via a string, requiring conversions to/from
the appropriate format just to find out what -really- went wrong?
which doesn't mention anything about speed. The real problem is
in determining what type the object is. If you want to retain type
information in a string, you'll have some problems. An alternative
is to have a hierachy of types (type Exceptions is tagged...), and
simply encode a pointer to the appropriate object as a string.
This is redoing what Java does (and my guess is that that's how
JGnat does it too).
Dale
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-14 18:52 ` Jeffrey Carter
2002-06-15 22:03 ` Robert A Duff
@ 2002-06-16 22:20 ` Wes Groleau
2002-06-17 1:57 ` Larry Kilgallen
2002-06-17 2:16 ` Jeffrey Carter
1 sibling, 2 replies; 80+ messages in thread
From: Wes Groleau @ 2002-06-16 22:20 UTC (permalink / raw)
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.
Indeed you shouldn't. You should use a single exception
and differentiate by information dropped into a global
ErrNo.
:-)
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 22:20 ` Wes Groleau
@ 2002-06-17 1:57 ` Larry Kilgallen
2002-06-17 2:16 ` Jeffrey Carter
1 sibling, 0 replies; 80+ messages in thread
From: Larry Kilgallen @ 2002-06-17 1:57 UTC (permalink / raw)
In article <3D0D0F4A.FCB346CD@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes:
>
>
>> the Ada intent is that the information be carried primarily by the
>> exception name. You should not be using a single exception and
>> differentiating between logical exceptions by the information attached
>> to that exception.
>
> Indeed you shouldn't. You should use a single exception
> and differentiate by information dropped into a global
> ErrNo.
>
> :-)
You can save the overhead of exception processing by just programming
the application to poll ErrNo at appropriate times.
also :-)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: ada paper critic
2002-06-16 22:20 ` Wes Groleau
2002-06-17 1:57 ` Larry Kilgallen
@ 2002-06-17 2:16 ` Jeffrey Carter
1 sibling, 0 replies; 80+ messages in thread
From: Jeffrey Carter @ 2002-06-17 2:16 UTC (permalink / raw)
Wes Groleau wrote:
>
> > the Ada intent is that the information be carried primarily by the
> > exception name. You should not be using a single exception and
> > differentiating between logical exceptions by the information attached
> > to that exception.
>
> Indeed you shouldn't. You should use a single exception
> and differentiate by information dropped into a global
> ErrNo.
What a wonderful idea! I wonder why no one ever thought of it before.
>
> :-)
--
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
^ permalink raw reply [flat|nested] 80+ messages in thread