Re: [Lilypond-auto] Issue 4365 in lilypond: Patch: Add ly_is_smob<T>(S) to check if S is a smob of type T.

[lilypond]

Comment #6 on issue 4365 by address@hidden: Patch: Add ly_is_smob<T>(S) to  
check if S is a smob of type T.
https://code.google.com/p/lilypond/issues/detail?id=4365

As an extra mechanism, dynamic_unsmob<class T> seems perfectly nice and  
uncontentious to me.  Since there is no collision of ::unsmob with  
klass::unsmob, one might even just use unsmob<class T> but then users will  
not know when and why to use which variant.

I introduced is_smob as a separate function to avoid an extra memory access  
when only the type of the expression is wanted.  Naturally this saving  
would not work when one needs to execute dynamic_cast anyway.

The compiler also cannot optimize the pointer fetch away even when it knows  
that dynamic_cast is trivial since the pointer itself might be 0 to start  
with (at least with the knowledge available to the compiler) even when it  
would not become so through dynamic_cast.

Catching this case at compile time would likely require the use of the  
C++11 type traits system.

Now we lived without is_smob previously.  I am not totally sure that we  
have a guarantee that several unsmob<class T> in different compilation  
units will share the same address for the same type, so that could affect  
address lookup in, uh, lily/function-documentation.cc.

So all being said, the addition of a dynamic_unsmob<T> for those cases  
currently using dynamic_cast, or derived_unsmob<T> (when the point of the  
template is masking the internals, it may make more sense to name it after  
its purpose than its internals) seems like a nice addition.  I am feeling a  
lot more ambiguous about the further possibilities.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings