Ada requires too much typing!
in [ADA]
|
Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Georg Bauhaus on 8 Jun 2010 03:10 On 6/8/10 8:43 AM, Martin Krischik wrote: > using local packages to add static variables to > Ada procedures. OTOH, I'd think a static local variable is most useful if and only if two condition are true - there is a single library level procedure operating on the variable, not two (otherwise a package contains both of them), and - the variable's subtype does not depend on the procedure Is this true? Can you give a few use cases?
From: Maciej Sobczak on 8 Jun 2010 03:46 On 7 Cze, 17:00, "Martin Krischik" <krisc...(a)users.sourceforge.net> wrote: > > It looks like virtual destructors amount for some 20-30% of all in my > > code. > > Now that is interesting. It's even more interesting than this, because in several cases I had to add the "virtual" keyword not because it was driven by design, but because the compiler complained about the lack of it. The g++ compiler gives a warning (-Wall) for each case where a class has at least one virtual function and non-virtual destructor. That is, in order to get a clean compile, I had to add the "virtual" keyword in several places where it was not necessary from the design point of view. In other words, the effective numbers are even lower than that. > It means that most of your classes are final as > the java guys would say. While I have always written under the premises > that my classes might become child classes for something else. (rather parent classes, or to use the C++ terminology - base classes) In many projects classes can be divided into two groups: 1. "public", making a user API of the project (typical for libraries) 2. "private", for the implementation details The types from the first group *might* become parents for something provided by the user and it makes sense to defensively prepare them for this role. Even this is not always the case, for example *none* of the STL classes has a virtual destructor. Types from the second group are fully controlled by the project designer - this includes the closure of eventual hierarchy and all usage patterns. If instances of these types are not deleted by pointer to base then there is *no reason* to make their destructors virtual. And I try to avoid using pointer if they are not necessary. Note: if the project is not a library, then the first group is empty. > BTW: you are aware that if the parent class uses a virtual destructor then > the child class does as well - even when not explicitly specified? I am pedantic in my coding conventions and I always mark virtual stuff as being explicitly virtual. > > then you are probably trying to write Java in C++. > > I learned C++ before Java using IBM Open Class Library In other words, you have been exposed to the overly object-oriented style. :-) Try some modern libraries like Boost or POCO - they are a lot less focused on object orientation. > A string class with lazy copy, C++ library authors resigned from this idea long time ago. It's very ineffective in the multithreading environment. > Well and 90% of the classes > descending form IVBase. Guess what the V stands for. As I've already said - this design approach is representative for '80s. There is a reason for why today's most acknowledged libraries are not designed this way. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Martin Krischik on 8 Jun 2010 04:53 Am 08.06.2010, 09:46 Uhr, schrieb Maciej Sobczak <see.my.homepage(a)gmail.com>: > In other words, you have been exposed to the overly object-oriented > style. And how is that any better then the over templatized way used today? > As I've already said - this design approach is representative for > '80s. There is a reason for why today's most acknowledged libraries > are not designed this way. Yes, but it's speed over everything again. This is why the why the STL “classes” have no virtual destructor. vector<> had to be as fast as the build in array. And the rest of the STL has been designed from there. Any design compromise acceptable as long as speed is not compromised. I don't like the STL much. The reason is that foremost I see myself as an OO programmer and the language is just a tool. I have done OO on C - including inheritance and virtual dispatch. For me an object must support inheritance and the STL does not. Therefore the STL is just a collections of utilities outside the OO framework. Reading the rest of you post I wonder if C++ has given up on being an object orientated language? Perhaps becoming a generic (metaprogramming) language instead. Martin -- Martin Krischik mailto://krischik(a)users.sourceforge.net https://sourceforge.net/users/krischik
From: Martin Krischik on 8 Jun 2010 05:00 Am 08.06.2010, 09:10 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de>: > Is this true? Can you give a few use cases? I was not thinking semantic or design level. Just syntactic similarities: int f () { class c { int g () { … }; } c i = new c (); return i.g (); } vs. function f returns Integer package i is g : Integer := 0; end i; begin i.g := i.g + 1; return i.g; end f; As said just the boilerplate code is what I found amusing, paint-full and kind of similar. Martin -- Martin Krischik mailto://krischik(a)users.sourceforge.net https://sourceforge.net/users/krischik
From: Niklas Holsti on 8 Jun 2010 06:10
Martin Krischik wrote: > just about as painful as using local packages to add static variables to > Ada procedures. Later Martin Krischik wrote: > function f returns Integer > > package i is > g : Integer := 0; > end i; > > begin > i.g := i.g + 1; > return i.g; > end f; If you mean the latter code to be an example of the former task (add static variable), I believe you are mistaken. The variable f.i.g is not "static" in the sense of being statically allocated. The nested package i is elaborated on each invocation of function f, which means that f.i.g is stack allocated, initialized to 0 on each invocation of f, then incremented to 1. Thus f always returns 1. To make a statically allocated variable, you need a library package. Perhaps you are thinking of the technique suggested by Mark Lundquist, at http://www.adapower.com/index.php?Command=Class&ClassID=Basics&CID=204 That technique uses a nested package inside a library package, but not within the subprogram using the variable. The nesting is used only to hide the variable from other subprograms that are in the same library package but are not in the nested package. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . |