Re: Ada Annoyances

[pythoner6@gmail.com]

On Saturday, June 24, 2017 at 4:34:32 AM UTC-4, Maciej Sobczak wrote:
> Because tagging (like v-table in C++) is a language design artefact that enables dynamic binding, which has its costs and has nothing to do with automated lifetime management. These concepts are orthogonal and there is no need to entangle them together.

Yes, I definitely agree with that - which is similar to the reason I started this thread.

> This has practical implications. In C++ the auto_ptr or scoped_ptr (or similar) wrapper has literally zero cost, both in space and in time. If the raw pointer has 4 bytes (on a 32-bit machine), the scoped_ptr wrapper will have 4 bytes, too. Ada imposes unnecessary cost - again, both in space and time.

As I understand it, the penalty in Ada is going to some extra space for the tag (how big is this? I haven't found much info on the size of a tag, which I'm assuming is because this may be implementation dependent?), and the smart pointer will get passed around by reference, as opposed to by value which would make more sense. While for most part I'm not too concerned about the extra space required for the tag (in other cases), for a smart pointer that's probably about doubling the size which is unfortunate.

Method calls won't be dynamically dispatched unless you're dealing with a Smart_Pointer'Class and calling methods that take a Smart_Pointer (which I don't see much reason to do if you want a low overhead smart pointer), right?

> > And how is C++ much different - other than that you can make destructors non-virtual
> 
> In a class that is not intented for use in a class hierarchy (like said RAII wrappers) the destructor should *not* be virtual, as there is no reason for it to be.
> 
> > (and therefore never dynamically dispatch, though I think the advice I usually see is to make almost all destructors virtual to avoid the case where the wrong destructor gets called).
> 
> This is not a complete advice. If the class is not part of any hierarchy, there is only one destructor and always the right one will be called.

Sure - I'm not saying it's necessarily the best practice, but I've certainly seen that advice given. Now that C++ has the final keyword, I think it's probably safer to provide nonvirtual destructors as they can be marked final to ensure that the destructor cannot be accidentally overridden.

> > Again, I'm not quite sure I follow you here. What do you mean by "not compatible with the lifetime of its parts"?
> 
> In C++ when the object of derived class is constructed, its base class constructor is called first and at that time the object is considered to have the Base dynamic type, which makes sense, as the derived parts have not yet been initialized (they will be initialized in the Derived constructor, which will happen later). Only after the base constructor finishes, the dynamic type of the object is "promoted" to Derived. This means that virtual calls within the Base constructor will never dispatch to Derived variants, which is safer, as it prevents accidental access to not-yet-initialized parts of the object from virtual functions. We say that from within constructors (and destructors, where the same process goes in the reverse direction) the static type is equal to the dynamic type of the object.
> Ada does not have this feature and diaptching calls can access uninitialized components from derived parts by means of dispatching to the not-yet-born parts of the object.
> 
> In this sense and this particular context, C++ offers better and stronger (!) type safety than Ada.
> 
> -- 
> Maciej Sobczak * http://www.inspirel.com

Ah, I see.