> On May 24, 2024, at 3:08, 'Sam Clegg' via emscripten-discuss > <emscripten-discuss@googlegroups.com> wrote: > > On Wed, May 22, 2024 at 10:03 PM キャロウ マーク <git...@callow.im > <mailto:git...@callow.im>> wrote: >> >> >>> On May 22, 2024, at 23:47, 'Sam Clegg' via emscripten-discuss >>> <emscripten-discuss@googlegroups.com >>> <mailto:emscripten-discuss@googlegroups.com>> wrote: >>> >>> On Tue, May 21, 2024 at 11:30 PM キャロウ マーク <git...@callow.im >>> <mailto:git...@callow.im>> wrote: >>>> When on the verge of releasing a major chunk of work, having a new version >>>> of the compiler throw up 4 errors is extremely, extremely disappointing. >>>> The disappointment is compounded by being unable to find any documentation >>>> describing the effect of the compiler changes and how to adapt one’s code. >>>> I have not found the documentation remotely helpful in understanding what >>>> is wrong. Must do better! >>> >>> Please try to be respectful and understanding here in this forum. >> >> What part of the paragraph do you feel was disrespectful? >> > > I found the tone of your comment to be very harsh. The folks who work on > emscripten are doing their best to build something that works for our users > and gets better over time. Calling things "extremely, extremely > disappointing" and demanding "Must do better!" could come across to some as > entitled. Just toning it down a little would likely be better received and > yield better outcomes, which we all want of course.
I agree the chiding at the end was harsh. I am sorry it upset you. The rest of
it was expressing my feelings. Make of them what you will. My feeling of
disappointment was compounded by discovering, on the same day, that another
compiler update was causing that compiler to not compile another part of my
project.
>>
>>
>> I have fixed my binding by changing it to use real constructors, which
>> return nothing, as constructors instead of functions with return values.
>> That is instead of
>>
>>>>
>>>> class_<ktx::texture>("ktxTexture")
>>>> .constructor(&ktx::texture::createFromMemory,
>>>> return_value_policy::take_ownership())
>>>> .constructor(&ktx::texture::create,
>>>> return_value_policy::take_ownership())
>>>> .constructor(&ktx::texture::createFromBuffer,
>>>> return_value_policy::take_ownership())
>>>> ;
>>
>> I have
>>
>> .constructor<const val>()
>> .constructor<const ktxTextureCreateInfo&,
>> ktxTextureCreateStorageEnum>()
>> .constructor<const val&, int, int, int, bool>()
>>
>> matching constructors in the C++ code.
>>
>> I created the binding too many years ago to recall why I used functions for
>> constructors. They look weird now. However embind still supports doing so.
>> It looks like an oversight to me that 3.1.60 does not support use of
>> return_value_policy in such constructors and a bug that is silently ignores
>> such when present.
>>
Should I open an issue about this? I am not sure function-as-constructor is
still a reasonable thing to do, if it ever was. If it is them I’m pretty sure
return_value_policy needs to be supported for that use.
Regards
-Mark
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/F7FDE8AD-0718-42A5-8BEE-E640F7123882%40callow.im.
signature.asc
Description: Message signed with OpenPGP
