[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: |
Dan Eble |
Subject: |
Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden) |
Date: |
Thu, 14 May 2015 08:19:05 -0400 |
> 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
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), dak, 2015/05/13
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), nine . fierce . ballads, 2015/05/13
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), nine . fierce . ballads, 2015/05/13
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), dak, 2015/05/14
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden),
Dan Eble <=
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), dak, 2015/05/16
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), nine . fierce . ballads, 2015/05/16
- Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by address@hidden), dak, 2015/05/17