Re: Why no Ada.Wide_Directories?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 27 Oct 2011 23:09:42 +0200, Yannick Duch�ne (Hibou57) wrote:

> if you do not expect to use dispatching  
> calls, you may not need classes.

No. If you don't expect to use the number 123, that does not imply that
integer numbers shall not have that value.

> Finally, I suppose if one want classes,  
> that means he/she want dispatching calls. If someone want dispatching call  
> on some high level custom types, that's OK; if someone wants dispatching  
> calls on general purpose and basic type like Boolean, that's not OK,

1. You should explain the difference. Why some types are more types than
others?

2. Dispatching never happens on *a* type, it does on a *set* of types. In
Ada you simply cannot have a dispatching call on a specific type. Ada is a
typed language.

> this cost too much, unless optimized.

Nope, it does not cost anything. You are comparing costs of using something
with the costs of not writing (and thus not executing) the program at all.
Non-existing programs consume no resources.

Again, in order to make comparison meaningful you have to consider
comparable cases. For example, having a class you can put class-wide
instances into a container. Without the class you have to write some
variant record wrapper type with alternatives of different types and the
discriminant playing the role of a tag. Now you could compare the
performance of this poor man's class implementation and one of the proper
class.

> To know when a call is dispatching or static, does not make dispatching  
> calls less costly. If you want dispatching call to cost not too much, you  
> have to optimize these calls,

Not in Ada, where specific and class-wide types are distinct. If you
statically know the type you declare the object of that type. If you don't
know the type, then presently for types which are not tagged, you cannot
write the program at all.

> Or else, what kind of classes was this all about ?

Class = set of types closed upon inheritance.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de