Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Maciej Sobczak on 9 Jun 2010 17:22 On 9 Cze, 16:29, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > What is the common base class/interface for C++ or Ada containers? > > generic > type Element is private; > package Generic_Stack is > type Stack is limited private; > ... > end Generic_Stack; > > The common base is the [generic] interface of Stack, which all instances > share, which every programmer has in mind talking about stack. Do you mean that every container supports push and pop operations (actually Append, Last_Element, Delete_Last, etc.)? > > How can I use it? > > You cannot, which is the problem of generics. Or maybe not generics in general, but the specific approach to generics that was chosen by Ada. Remember, in C++ this is not a problem: #include <vector> #include <list> template <class ContainerOfInts> void appendThreeInts(ContainerOfInts & c) { c.push_back(7); c.push_back(42); c.push_back(123); } int main() { std::vector<int> vec; std::list<int> lst; appendThreeInts(vec); appendThreeInts(lst); } The appendThreeInts function uses the implicit common interface, even though vector and list do not share anything explicitly. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Yannick Duchêne (Hibou57) on 9 Jun 2010 19:09 Le Wed, 09 Jun 2010 23:22:53 +0200, Maciej Sobczak <see.my.homepage(a)gmail.com> a écrit: > Or maybe not generics in general, but the specific approach to > generics that was chosen by Ada. > Remember, in C++ this is not a problem: > > #include <vector> > #include <list> > > template <class ContainerOfInts> > void appendThreeInts(ContainerOfInts & c) > { > c.push_back(7); > c.push_back(42); > c.push_back(123); > } > > int main() > { > std::vector<int> vec; > std::list<int> lst; > > appendThreeInts(vec); > appendThreeInts(lst); > } > > The appendThreeInts function uses the implicit common interface, even > though vector and list do not share anything explicitly. > > -- > Maciej Sobczak * http://www.inspirel.com > > YAMI4 - Messaging Solution for Distributed Systems > http://www.inspirel.com/yami4 Although it would requires a different layout (actually, just more typing ;) ), the same is possible with Ada : just use a formal subrpogram parameter for pubsh_back. You would better use the notation: with My_Subprogram (...signature...) is <>; or even (left oftenly, while still valid and meaningful) with My_Subprogram (...signature...) is null; to get benefit from static polymorphism. About this kind of generic formal parameter, please, see [ARM 2005 12.16 (2.1/2)] and [ARM 2005 12.16 (10)] and [ARM 2005 12.16 (10.1/2)]. Static polymorphism is achieved when you use a consistent naming shame for similar subprograms in different areas or packages : ex. you define a Lists package with a Push procedure and a Stacks package with a Push procedure also (same name in both package). All of these, providing I have really understood what you were requesting for. -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Randy Brukardt on 10 Jun 2010 02:13 "Maciej Sobczak" <see.my.homepage(a)gmail.com> wrote in message news:c459b285-851b-4d6f-95fe-0c28b58ddf45(a)e5g2000yqn.googlegroups.com... 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). Maybe in C++, but in Ada, if you are defining OOP using pointers, you are doing something wrong. (Probably copying a crappy design from some other language.) There should be almost no visible access types (and I say almost only to allow the accessor magic of Ada 2012). When this is done, even the use of objects of 'Class can be managed with Ada.Containers, and any needed dynamic allocation can be completely hidden from the program. (And it rarely is needed in the first place.) Randy.
From: AdaMagica on 10 Jun 2010 02:19 On 10 Jun., 08:13, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote: > >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). > > Maybe in C++, but in Ada, if you are defining OOP using pointers, you are > doing something wrong. (Probably copying a crappy design from some other > language.) There should be almost no visible access types (and I say almost > only to allow the accessor magic of Ada 2012). > > When this is done, even the use of objects of 'Class can be managed with > Ada.Containers, and any needed dynamic allocation can be completely hidden > from the program. (And it rarely is needed in the first place.) > > Randy. Randy, which AI is the favoured solution (there are several proposals)? The current Amendment 2 RM is still Draft 8 which does not include this accessor magic.
From: Vadim Godunko on 10 Jun 2010 02:34
On Jun 10, 10:13 am, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote: > > Maybe in C++, but in Ada, if you are defining OOP using pointers, you are > doing something wrong. (Probably copying a crappy design from some other > language.) There should be almost no visible access types (and I say almost > only to allow the accessor magic of Ada 2012). > I want to known more about how to use OOP in Ada without access types! |