Re: [ccmtools-devel] Changes in test/CppGenerator

[Teiniker E. <ego...@tu...>]

Hey Leif!

Quoting Leif Johnson <le...@am...>:
> But here are the things I've noticed so far
> about the tests :
>
> - facet, receptacle, facet_basic_types, receptacle_basic_types : Didn't
>   compile because my compiler complained about `assert' in
>   src/Hello_mirror_app.cc. I added `#include <assert>' but haven't
>   gotten a chance to test that it works.

Hmm, my compiler does not matter about it but a student of mine has had the
problem and fixed it with #include<cassert> I think.

> - attribute_interface : Apparently my compiler (g++ 3.2) isn't happy
>   about functions that return an abstract base class (i.e. an
>   interface).

In general, C++ seemed to be an unhappy language (hey J=F6rg it's a joke ;-)
We have to pass the abstract classes by reference instead by value. To handl=
e
the memory management we will use SmartPtr.
Don't care about that problem, I will fix it in the next week.


> - receptacle_multiple : The %(Identifier)sConnections type definition
>   for multiple receptacles somehow got lost in the shuffle. I tried to
>   define it in the MUsesDefIncludeMultiple template as :
>
>     typedef std::vector<CCM_Local::%(UsesType)s> %(Identifier)sConnections=
;
>
>   but it looks like this isn't quite right. I think maybe there was a
>   SmartPtr<CCM_Local::%(UsesType)s> in there or something. Could you fix
>   this up for me ?

OK, I have added the following lines to the MUsesDefIncludeMultiple template=
:

#ifndef __MAPPING__%(UsesType)s__%(Identifier)s__
#define __MAPPING__%(UsesType)s__%(Identifier)s__
typedef std::map<localComponents::Cookie,
CCM_Utils::SmartPtr<CCM_Local::CCM_%(UsesType)s> > %(Identifier)sConnections=
;
#endif

I also added a src/ subdirectory to test/CppGenerator/receptacle_multiple, t=
hus
the receptacle_multiple.sh test passes the check now.
The problems in the home_factory.sh and home_basic_types.sh tests are also
fixed.

> I noticed the _user_types tests didn't even generate code ; I'll work on
> that tomorrow.

Excellent!
As soon as the IDL user types can be generated, I will add the remote compon=
ent
generator stuff to bring all the code together.

:-) Egon