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 07:35 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 9 Jun 2010 03:50 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 9 Jun 2010 04:10 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 9 Jun 2010 04:43 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 9 Jun 2010 05:24
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 |