comp.lang.ada
 help / color / mirror / Atom feed
From: "Jon Orris" <jonorris@ieee.org>
Subject: Re: C++ STL Components and Ada
Date: Wed, 18 Jul 2001 14:00:38 -0400
Date: 2001-07-18T17:59:34+00:00	[thread overview]
Message-ID: <9j4iq6$ncp$1@bob.news.rcn.net> (raw)
In-Reply-To: 3B54FE7B.9EDF993C@worldnet.att.net

"James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3B54FE7B.9EDF993C@worldnet.att.net...
> Jon Orris wrote:
> >
> > "James Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
> > news:3B5450EF.7D82CCF5@worldnet.att.net...
> >> > C++ templates also have the disadvantage that their instantiations
> > > cannot
> > > be checked by the compiler. Instead, you must deal with runtime errors
> > > when making simple mistakes such as filling a container with values
> > > of Animal and then trying to read them out as values of Mineral.
> >
> > Could you provide an example of what you mean here? I've seen this claim
> > before, and have been unable to think of how this would occur. I've
never
> > had this sort of issue crop up when developing in C++.
> >
>
> Sure.
>
> All pointers to Objects in C++ are equivalent to class-wide access
> values in Ada. A pointer to an object can point to objects of all
> classes inheriting from the pointer's object base type.
>
> When instantiating a template you must specify the class of the
> objects to be contained by the generic container class. That
> class parameter allows objects of the class and all its
> subclasses to be stored in the container class. So far, so good.
>
> Now, what happens if you instantiate the C++ Vector class with
> class Airplane, followed by appropriate additions of Airplane
> objects to the container. However, you used the cut and paste
> method of programming, so one of your functions extracts data
> from the Vector and wants to assign it to a reference to the
> String class.

This isn't so, unless I'm completely misunderstanding your point. One
of the nice things about C++ templates is that they lead to greater type
safety. When using C++,  many template programming techniques can
get you closer to the degree of type safety offered by Ada.

In the following sample, assignString and noSuchMethod fail to compile
when instantiated.

class Airplane
{
public:
 Airplane(const char* name) : m_name(name)
 {
 }

 const std::string& GetName() const
 {
  return m_name;
 }

private:
 std::string m_name;
};

template<class T>
void works(const std::vector<T*>& vec)
{
 for(std::vector<T*>::const_iterator iter = vec.begin(); iter != vec.end();
++iter)
 {
  T* val = *iter;
  std::cout << val->GetName() << std::endl;
 }
}

template<class T>
void assignString(const std::vector<T*>& vec)
{
 for(std::vector<T*>::const_iterator iter = vec.begin(); iter != vec.end();
++iter)
 {
  std::string& foo = *iter;
 }
}

template<class T>
void noSuchMethod(const std::vector<T*>& vec)
{
 for(std::vector<T*>::const_iterator iter = vec.begin(); iter != vec.end();
++iter)
 {
  T* val = *iter;
  std::cout << val->DoSomething() << std::endl;
 }
}

int main()
{
 std::vector<Airplane*> planes;
 // Yes, this leaks memory.
 planes.push_back(new Airplane("first"));
 planes.push_back(new Airplane("second"));

 works( planes );
 assignString( planes );
 noSuchMethod( planes );

 return 0;
}

C:\dev\test>g++ foo.cpp
foo.cpp: In function `void assignString<Airplane>(const vector<Airplane *,
allocator<Airplane *> > &)':
foo.cpp:57:   instantiated from here
foo.cpp:36: conversion from `Airplane *const' to non-scalar type
`basic_string<char,string_char_traits<char>,
__default_alloc_template<false,0> >' requested
foo.cpp:36: cannot initialize `basic_string<char,string_char_traits<char>,
__default_alloc_template<false,0> > &' from `Airplane *const'
foo.cpp: In function `void noSuchMethod<Airplane>(const vector<Airplane *,
allocator<Airplane *> > &)':
foo.cpp:58:   instantiated from here
foo.cpp:46: no matching function for call to `Airplane::DoSomething ()'

> Your compiler is completely satisfied with this situation.
> The compiler does not check actual parameter types for template
> instantiation. All that is done at run time. When you test the
> program you find that you have some problems.

The compiler always checks parameter types at instantiation.

One thing that is a problem with C++ templates is that there are certain
bugs that won't show up until a template is instantiated, I.e.

template<class T>
void insane(const std::vector<T*>& vec)
{
 Airplane a = 17;
}
// compiles with insane call commented out.
int main()
{
 std::vector<Airplane*> planes;
 // insane( planes );
}

I'm still learning Ada, and am not very familiar with generics,
so hopefully this is something that Ada would fail to compile altogether.

Bwt, lest I give the wrong impression, I'm quite aware of the shortcomings
in C++,
and the STL. At my prior job, we avoided much of the STL, originally because
it
wasn't standardized and/or supported on all compilers, then because our in
house
container library was substantially safer. You had to be actively stupid to
cause problems
with it.

Even with my limited knowledge of Ada, I can see substantial advantages over
C++.
I used to play a 'game' of C++ vs. Ada. After several hours of tracking down
a hideous
defect in some departed engineer's code, I'd ask myself: "Would Ada's
compile or run
time checks have detected this automatically?" 9 out of 10 times, the answer
was YES.

Jon Orris
jonorris@ieee.org






  parent reply	other threads:[~2001-07-18 18:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-16  0:37 C++ STL Components and Ada James Rogers
2001-07-17  4:26 ` Brian Rogoff
2001-07-17 14:48   ` James Rogers
2001-07-17 19:47     ` Jon Orris
2001-07-18  3:09       ` James Rogers
2001-07-18 15:48         ` Matthias Benkmann
2001-07-18 18:00         ` Jon Orris [this message]
2001-07-19 20:48     ` Ray Blaak
2001-07-20  0:40       ` Brian Rogoff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox