Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden)

[Dan Eble]

> On May 14, 2015, at 01:07 , address@hidden wrote:
> 
> On 2015/05/14 01:48:37, Dan Eble wrote:
>> Allow T::unsmob again (etc.)
> 
> Sorry, I must be really bad at being comprehensible.  Either that, or
> there are difficulties with my suggestion.  What I was suggesting was to
> get back to your original plan of only having one function unsmob<T>
> (which you called ly_unsmob<T> in your first patch) instead of
> differentiating between derived_unsmob<T> and unsmob<T>.

Oh.  The trouble was in communication.  I agree with you.  From the perspective 
of someone who tries to work on the C++ side of Lilypond without having 
achieved a comprehensive understanding of it, I would like having just unsmob<>.

> The disadvantage with that is that we are going to sacrifice the
> performance advantage of is_smob over unsmob for "base smobs".  The
> difference is not tied to the redundant dynamic_cast but rather to
> having to fetch the pointer at all (going through unsmob checks _both_
> the type of the smob as well as its pointer being non-zero.  The latter
> is always the case but the compiler does not know that).

Some template trickery could be used to select the more efficient 
implementation for the type.  I’ll leave a summary comment in the new unsmob<>.

> I also seem to remember using is_smob+unsmob (typical for use of
> LY_ASSERT_SMOB) only fetched the type once whereas unsmob+unsmob fetched
> type, pointer, type, pointer.  Maybe we should create some version of
> LY_ASSERT_SMOB leaving the fetched pointer in a variable.

Something like this?

template <class T>
inline T* noisy_unsmob (la la la)
{
  // test here; return smob
}

#define LY_ASSERT_SMOB(klass, var, number) noisy_unsmob<klass> (var, number, 
__FUNCTION__)

>  After all,
> that's the most frequent use, and then this consideration of avoiding a
> double unsmob would be moot, again making maintaining a separate is_smob
> in addition to a generic unsmob less attractive.

So in conclusion,
* use just unsmob<T> -- no is_smob<T> or derived_...<T>
* treat LY_ASSERT_SMOB specially for performance (test it)
* create a ticket suggesting a return value for LY_ASSERT_SMOB

Let me know if I got that wrong.  Thanks.
— 
Dan