Re: [Ecell-devel] [Ecell-cvs] SF.net SVN: ecell: [2853] ecell3/trunk

[Koichi T. <sh...@sf...>]

No, sorry, that RTTI doesn't work across shared objects was simply
new to me and I really meant it.

I did actually read through your message.  It seems
we are having some communication problem again.  Should be
talk on the phone again?  I might be offline for the next
48 hours or so but will arrive in Japan by then.

For the meantime, can we start with the following?
Without a reasonable agreement on such a fundamental thing like
this we cannot go anywhere.

 >>>> - A class name is the class name.
 >>>> - A base class is the base class of the class in C++
 >>>>    class hierarchy.
 >>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
 >>>>    the class with which we specialized the ModuleMaker.
 >>> Even sounds confusing :)




 >>> Again, how can it be done by RTTI which doesn't portably provide a
 >>> reasonable interface to determine the relevancy of given two types?
 >>> All we can do with the standard RTTI is check the identity of any two.

That is true C++ typeinfo can do only identify checks and partial
ordering.  However, it boils down that what we need in DMTool is
just a downcast, which is provided in ISO C++ as dynamic_cast.
We can use boost::polymorphic_cast to make use of this cleanly.
Pre-instantiation type check would be nice but as I wrote I don't
think it is not absolutely necessary.


 >>> I agree that the name __DM_TYPE is confusing. However we don't need to
 >>> change it in the E-Cell 3 branch otherwise it breaks ABI
 >>> compatibility. We have to take care of users who have a plenty of
 >>> precompiled DM's.

Ok let's think about doing this for ecell4.


 >>> The problem is that we designated two different tasks to ModuleMaker;
 >>> it is a module loader and an instantiator at the same time, where we
 >>> only expect the latter to be type-safe.

I think I understand what you mean.  Let's talk about this on the
phone or in person later.


 >>> What do you think is intrusive here? I don't think it is because it
 >>> doesn't break any binary compatibility nor source-level backwards
 >>> compatibility.

This is related to the point I raised repeatedly as to the relationship
between the class itself and the DM mechanism that makes the class a DM.
By intrusive I meant that if getTypeName() method is defined as a static
member it forces the class to *know* the DM base class.  Conceptually,
the dependency between the class and the DM framework
should be unidirectional, from the latter to the former.
To keep the design clean we have to make sure the class doesn't know
anything about the DM framework.  I know the current implementation
is not as clean as it should be but if we are putting additional
efforts on it we should go this way.


 >>> Practically such convention won't do well. Once the rule is broken, we
 >>> will have to be in for a mysterious bug because of unsafe type
 >>> conversion.

If the rule is broken nothing works reliably.  When we know there
can be exceptions, it is called exception handling.  When the
specification prohibits exceptions, what we implement is called
a bug catcher.

Once the rule is broken, we will have to handle a mysterious bug because
of unsafe type conversion.  The best way here is not to do unsafe type
conversion.  IF we can use dynamic_cast here that makes use of RTTI,
we avoid a unsafe type conversion by not relying on DM_TYPE field
and therefore we can avoid one possible niche of a mysterious bug.

 >>> Eitherway, we cannot use dynamic cast s here, that are not as
 >>> reliable when it comes to shared object. Some platforms may provide
 >>> type safety across different objects (including .so's), but others
 >>> don't.

Right.  That is why I asked the previous question.  It seems to me
any decent implementations of C++ RTTI would work but if it is
not in the ISO C++ spec and if there are important exceptions
(older VCs?) we need to give it a deeper thought.

Some DM classes use dynamic_cast internally across shared objects.
If it can fail in some platforms we will need to rewrite them.


koichi



> Hmm.. was there anything that helped you to doubt me? That totally
> depends on the implementation. The standards don't specify it, period.
> I understand you have very limited time right now, but please look
> through what I wrote in the previous mails to save the time.
> 
> Moriyoshi
> 
> 2007/7/25, Koichi Takahashi <sh...@sf...>:
>> Is it true that C++ RTTI doesn't support dynamically loaded
>> types?
>>
>>
>>>> Ok let us first define the terminology;
>>>>
>>>> - A class name is the class name.
>>>> - A base class is the base class of the class in C++
>>>>    class hierarchy.
>>>> - A DM base class (DM_BASECLASS/DM_TYPE or whatever) is
>>>>    the class with which we specialized the ModuleMaker.
>>> Even sounds confusing :)
>>>
>>>> You are right that the DM base of a class is not always the same
>>>> as the C++ base class.  However, it belogs to the C++ type system
>>>> in the sense that a DM instance is always a subclass of its DM base
>>>> class, either direct or indirect.
>>>> For this reason, theoretically, it should be possible to implement
>>>> it with the standard C++ RTTI.  Practically it might not be
>>>> straightforward but let us see how it goes for the moment.
>>> Again, how can it be done by RTTI which doesn't portably provide a
>>> reasonable interface to determine the relevancy of given two types?
>>> All we can do with the standard RTTI is check the identity of any two.
>>> Neither does it support dynamically loaded types.
>>>
>>>> So,
>>>>
>>>> 1. I think providing a way to access the __DM_TYPE symbol should be ok.
>>>>     Adding ModuleMaker::getTypeName() should be ok.
>>>>     We could give these better names, maybe?
>>>>     __DM_BASE_NAME and getDMBaseName() or something?
>>> I agree that the name __DM_TYPE is confusing. However we don't need to
>>> change it in the E-Cell 3 branch otherwise it breaks ABI
>>> compatibility. We have to take care of users who have a plenty of
>>> precompiled DM's.
>>>
>>>>     One drawback of this scheme is that if we rely on it
>>>>     we cannot make a DM that can be instantiated by different
>>>>     ModuleMakers.  For example, we might want to load SpecialFooClass
>>>>     from ModuleMaker<Class> and ModuleMaker<FooClass>.  This is
>>>>     possible in standard C++ RTTI but is problematic when we strictly
>>>>     check the __DM_TYPE thing when we instantiate it.
>>> The problem is that we designated two different tasks to ModuleMaker;
>>> it is a module loader and an instantiator at the same time, where we
>>> only expect the latter to be type-safe.
>>>
>>>> 2. I don't think the last line in this macro is a good idea.
>>>>
>>>>   #define DM_OBJECT( CLASSNAME, TYPE )\
>>>> - static TYPE* createInstance() { return new CLASSNAME ; }
>>>> + static TYPE* createInstance() { return new CLASSNAME ; }\
>>>> + static const char *getTypeName() { return #TYPE; }
>>>>
>>>>     Let us keep it non-intrusive as much as possible.
>>>>
>>> What do you think is intrusive here? I don't think it is because it
>>> doesn't break any binary compatibility nor source-level backwards
>>> compatibility.
>>>
>>>> 3.
>>>>
>>>> This
>>>>
>>>> Process* ProcessMaker::make( const std::string& aClassName )
>>>>
>>>> looks straightforward to write more concisely with dynamic_cast.
>>>> Here you can basically assume the class the DM .so contains is
>>>> a legitimate DM class that derives from the DM base class because
>>>> the DM compilation mechanism that names the classes and .so filenames
>>>> consistently takes care of it.
>>> Practically such convention won't do well. Once the rule is broken, we
>>> will have to be in for a mysterious bug because of unsafe type
>>> conversion. Eitherway, we cannot use dynamic cast s here, that are not as
>>> reliable when it comes to shared object. Some platforms may provide
>>> type safety across different objects (including .so's), but others
>>> don't.
>>>
>>> Moriyoshi
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Ecell-devel mailing list
>> Ece...@li...
>> https://lists.sourceforge.net/lists/listinfo/ecell-devel
>>
> 
>