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>
> > 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
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
From: Martin Krischik on 8 Jun 2010 04:53
Am 08.06.2010, 09:46 Uhr, schrieb Maciej Sobczak
> In other words, you have been exposed to the overly object-oriented
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)
From: Martin Krischik on 8 Jun 2010 05:00
Am 08.06.2010, 09:10 Uhr, schrieb Georg Bauhaus
> Is this true? Can you give a few use cases?
I was not thinking semantic or design level. Just syntactic similarities:
int f ()
int g ()
c i = new c ();
return i.g ();
function f returns Integer
package i is
g : Integer := 0;
i.g := i.g + 1;
As said just the boilerplate code is what I found amusing, paint-full and
kind of similar.
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;
> 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,
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 fi
. @ .