lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue


From: dak
Subject: Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden)
Date: Thu, 14 May 2015 05:07:13 +0000

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>.

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).

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.  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.

https://codereview.appspot.com/231680043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]