From: Georg Bauhaus on
On 08.06.10 12:10, Niklas Holsti wrote:
> 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.

I thought, too, that a new variable decl inside the local package
would still be elaborated each time. The initilization of g
confirms when tested.

But then I thought, surprise!, doubted everything I thought
I had learned about Ada. Looking at this:

with Ada.Text_IO; use Ada.Text_IO;

procedure Sttc is

type T is range 0 .. 10;

procedure A is
package P is -- local package
V: T; -- presumably static?
end P;
begin
if P.V'Valid then
P.V := P.V + 1;
else
P.V := T'First;
end if;
Put_Line (T'Image(P.V));
end A;

begin
A; A; A;
end Sttc;


$ ./sttc
0
1
2
3
$

Compiled with or without -gnatVa. But this seems to be accidental,
V is just a variable that isn't initialized, living on the stack.
Confirmation:

with Ada.Text_IO; use Ada.Text_IO;

procedure Sttc is

type T is range 0 .. 10;

procedure A is
package P is
V: T;
end P;
begin
if P.V'Valid then
P.V := P.V + 1;
else
P.V := T'First;
end if;
Put_Line (T'Image(P.V));
end A;

procedure Ovrwrt_Stk is
X : T;
begin
X := T'First;
end Ovrwrt_Stk;

begin
A; Ovrwrt_Stk; A; Ovrwrt_Stk; A; Ovrwrt_Stk; A;
end Sttc;

$ ./sttc
0
1
1
1
$

Phew. Back to normal.
From: Maciej Sobczak on
On 8 Cze, 10:53, "Martin Krischik" <krisc...(a)users.sourceforge.net>
wrote:

> > 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?

You mean - how is that any worse. :-)

The overly object-oriented style (OOO (tm)) promotes or even relies on
overly dynamic memory management model.
This naturally leads to Pointers Everywhere Driven Development (PEDD).

The overly templatized way has its disadvantages, but at least allows
to preserve the value-oriented design approach, which is simply safer.
With a reasonable use of typedefs (type renamings) I find it very
appropriate and readable.

> > 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.

No. I perceive it as safety over everything.

(yes, I'm intentionally provocative here, but there is a point,
really)

> This is why the why the STL  
> “classes” have no virtual destructor.

No. The STL classes have no virtual destructors, because they also
have no virtual functions and as such it makes absolutely no sense to
derive from them.

In other words, they are not intended for polymorphic use.

For comparison, think about IOStreams - this *is* a polymorphic
framework with lots of virtual functions. Take it as a proof that
design decisions in C++ are not "speed over everything". Polymorphism
just makes sense for IOStreams and it just does not for containers. Or
at least this is what C++ thought.

> vector<> had to be as fast as the  
> build in array.

Not really - it uses the dynamic memory, while built-in arrays do not
have to.

> Any  
> design compromise acceptable as long as speed is not compromised.

See IOStreams for contradiction of your claims.

> I don't like the STL much.

The designers of Ada.Containers did. ;-)

> The reason is that foremost I see myself as an  
> OO programmer and the language is just a tool.

I see myself as a software engineer and the paradigm is just a tool.

(again intentionally provocative here)

> Reading the rest of you post I wonder if C++ has given up on being an  
> object orientated language?

It has not given up anything, as the OO was never the focus. C++ is a
multi-paradigm language, like Ada. It supports OO but does not force
it.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on
On Wed, 9 Jun 2010 00:50:17 -0700 (PDT), Maciej Sobczak wrote:

> No. The STL classes have no virtual destructors, because they also
> have no virtual functions and as such it makes absolutely no sense to
> derive from them.
>
> In other words, they are not intended for polymorphic use.

No, they are for parametrically polymorphic use.

Templates -> parametric (static) polymorphism
Virtual functions -> dynamic polymorphism
[ Overloading -> ad-hoc (static) polymorphism ]

> Polymorphism
> just makes sense for IOStreams and it just does not for containers.

Polymorphism is the essence of generic programming = programming in terms
of sets of types. That is what STL is all about, per fact and per intent
too (see Stepanov's interview).

>> Reading the rest of you post I wonder if C++ has given up on being an �
>> object orientated language?
>
> It has not given up anything, as the OO was never the focus. C++ is a
> multi-paradigm language, like Ada. It supports OO but does not force
> it.

I am tempted to re-phrase a saying that multiple opinions on the same issue
(paradigms?) manifests freedom when in a society and schizophrenia when in
someone's head (language?).

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Maciej Sobczak on
On 9 Cze, 10:10, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:

> > In other words, they are not intended for polymorphic use.
>
> No, they are for parametrically polymorphic use.

By "polymorphism" I meant the parametrisation based on dynamic
dispatch, also known as object-orientation.
Note, for example, that containers in C++ have no common base class/
interface. In Ada this is similar.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on
On Wed, 9 Jun 2010 01:43:56 -0700 (PDT), Maciej Sobczak wrote:

> On 9 Cze, 10:10, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>>> In other words, they are not intended for polymorphic use.
>>
>> No, they are for parametrically polymorphic use.
>
> By "polymorphism" I meant the parametrisation based on dynamic
> dispatch,

This is a specific form of polymorphism.

> also known as object-orientation.

There are different opinions on whether OO is limited to dynamic
polymorphism.

> Note, for example, that containers in C++ have no common base class/
> interface. In Ada this is similar.

There is a common base, which is just not explicit. This is one of the
weaknesses of parametric polymorphism that it does not provide any
substitute for the class (= set of types) embedded in the language. E.g.
you cannot name "all instances of a generic thing."

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de