Hi All,

mingw64 is complaining about this:

long CppSound::getThis()
{
  return (long) this;
}

as losing precision.  This makes sense as long is defined as 32-bit
and the size of addresses with x86_64 is 64-bit.  Anyone have
suggestions?  I imagine someone is using this getThis() function, but
it must be problematic for anyone on 64-bit platforms.

BTW: I've gotten past this using intptr_t instead of long locally.
(That should adapt to be appropriate for a size of a pointer).  I'll
plan to use that when I make a commit unless someone raises an issue.

On Tue, Dec 29, 2015 at 2:50 PM, Steven Yi  wrote:
> Hi All,
>
> mingw64 is complaining about this:
>
> long CppSound::getThis()
> {
>   return (long) this;
> }
>
> as losing precision.  This makes sense as long is defined as 32-bit
> and the size of addresses with x86_64 is 64-bit.  Anyone have
> suggestions?  I imagine someone is using this getThis() function, but
> it must be problematic for anyone on 64-bit platforms.
>

Why not return void*? That would be guaranteed to fit the pointer.
Although a reason for why would one want to use this getThis instead
if &obj (or obj directly if it is already a pointer) eludes me.

On 29 December 2015 at 16:56, Steven Yi  wrote:
> BTW: I've gotten past this using intptr_t instead of long locally.
> (That should adapt to be appropriate for a size of a pointer).  I'll
> plan to use that when I make a commit unless someone raises an issue.
>
> On Tue, Dec 29, 2015 at 2:50 PM, Steven Yi  wrote:
>> Hi All,
>>
>> mingw64 is complaining about this:
>>
>> long CppSound::getThis()
>> {
>>   return (long) this;
>> }
>>
>> as losing precision.  This makes sense as long is defined as 32-bit
>> and the size of addresses with x86_64 is 64-bit.  Anyone have
>> suggestions?  I imagine someone is using this getThis() function, but
>> it must be problematic for anyone on 64-bit platforms.
>>
>> steven



-- 

Saludos,

long is 32bit in a 64bit OS? That's news to me.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 29 Dec 2015, at 19:50, Steven Yi  wrote:
> 
> Hi All,
> 
> mingw64 is complaining about this:
> 
> long CppSound::getThis()
> {
>  return (long) this;
> }
> 
> as losing precision.  This makes sense as long is defined as 32-bit
> and the size of addresses with x86_64 is 64-bit.  Anyone have
> suggestions?  I imagine someone is using this getThis() function, but
> it must be problematic for anyone on 64-bit platforms.
> 

intptr_t or void * should be fine. Steven is correct that what worked
for 32 bits will not work for 64 bits. There was a reason I did not
use void * which I have forgotten.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Dec 29, 2015 at 3:03 PM, Victor Lazzarini
 wrote:
> long is 32bit in a 64bit OS? That's news to me.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 29 Dec 2015, at 19:50, Steven Yi  wrote:
>>
>> Hi All,
>>
>> mingw64 is complaining about this:
>>
>> long CppSound::getThis()
>> {
>>  return (long) this;
>> }
>>
>> as losing precision.  This makes sense as long is defined as 32-bit
>> and the size of addresses with x86_64 is 64-bit.  Anyone have
>> suggestions?  I imagine someone is using this getThis() function, but
>> it must be problematic for anyone on 64-bit platforms.
>>

I'm not the author of this, but I suspect it was used from a wrapped
language (python?) and passed around like a pointer.  I'd rather we
just remove this method as I have no idea what its purpose is though.

On Tue, Dec 29, 2015 at 2:58 PM, Felipe Sateler  wrote:
> Why not return void*? That would be guaranteed to fit the pointer.
> Although a reason for why would one want to use this getThis instead
> if &obj (or obj directly if it is already a pointer) eludes me.
>
> On 29 December 2015 at 16:56, Steven Yi  wrote:
>> BTW: I've gotten past this using intptr_t instead of long locally.
>> (That should adapt to be appropriate for a size of a pointer).  I'll
>> plan to use that when I make a commit unless someone raises an issue.
>>
>> On Tue, Dec 29, 2015 at 2:50 PM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> mingw64 is complaining about this:
>>>
>>> long CppSound::getThis()
>>> {
>>>   return (long) this;
>>> }
>>>
>>> as losing precision.  This makes sense as long is defined as 32-bit
>>> and the size of addresses with x86_64 is 64-bit.  Anyone have
>>> suggestions?  I imagine someone is using this getThis() function, but
>>> it must be problematic for anyone on 64-bit platforms.
>>>
>>> steven
>
>
>
> --
>
> Saludos,

I wrote this method, It supports passing a pointer to the CppSound
object from scripting languages that don't normally support pointers
to something that needs a pointer, such as a native application that
embeds the scripting language, or as userdata to some callback.

Another use is to compile and dynamically load a shared library that
contains CppSound and not have to export from the library all the
functions in CppSound; it suffices to export or expose just getThis,
and then the header files permit every function of CppSound and the
Csound API in general to be called.

Both of these uses have been implemented at various times. I don't
currently use getThis, but I can't promise that nobody programming
with Csound does. so if you take it out you might break somebody's
code.

In general, there is a built-in conflict between our desire to
maintain backward compatibility in Csound, and our desire to have a
well-engineered piece of software with a simple and consistent
interface. This goes beyond just keeping around old opcodes and
syntaxes. Maybe we need to be clearer on what must be backwards
compatible, and what does not necessarily need to be backwards
compatible.

I think the attitude of the maintainers of Csound, including yourself
and myself, towards code that we do not understand should be to let it
alone unless it contains an obvious bug, in which case the bug should
be fixed if possible. Without an agreed definition of what needs to be
backward compatible and what does not, just taking stuff out for
reasons of personal taste or lack of knowledge amounts to dictating
the form and even the uses of Csound. I'm sure you don't intend to
convey this impression, but that is how it might look to somebody who
does not know you.

what is your opinion on what needs to be maintained backwards
compatible? Opcodes? Sco and orc syntax? C API? C++ API? Language
wrappers for Python and Java? For Lua? For Lisp?

Best.
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Dec 29, 2015 at 4:05 PM, Steven Yi  wrote:
> I'm not the author of this, but I suspect it was used from a wrapped
> language (python?) and passed around like a pointer.  I'd rather we
> just remove this method as I have no idea what its purpose is though.
>
> On Tue, Dec 29, 2015 at 2:58 PM, Felipe Sateler  wrote:
>> Why not return void*? That would be guaranteed to fit the pointer.
>> Although a reason for why would one want to use this getThis instead
>> if &obj (or obj directly if it is already a pointer) eludes me.
>>
>> On 29 December 2015 at 16:56, Steven Yi  wrote:
>>> BTW: I've gotten past this using intptr_t instead of long locally.
>>> (That should adapt to be appropriate for a size of a pointer).  I'll
>>> plan to use that when I make a commit unless someone raises an issue.
>>>
>>> On Tue, Dec 29, 2015 at 2:50 PM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> mingw64 is complaining about this:
>>>>
>>>> long CppSound::getThis()
>>>> {
>>>>   return (long) this;
>>>> }
>>>>
>>>> as losing precision.  This makes sense as long is defined as 32-bit
>>>> and the size of addresses with x86_64 is 64-bit.  Anyone have
>>>> suggestions?  I imagine someone is using this getThis() function, but
>>>> it must be problematic for anyone on 64-bit platforms.
>>>>
>>>> steven
>>
>>
>>
>> --
>>
>> Saludos,

As far as I understand, we've largely been very conservative (and
rightfully so) on API breakages.  My own take is:

* Csound language: backwards compatibility is a must. If something
changes in the language, it should be to define previously undefined
behavior. Also, if behavior changes for something well established, it
must be done in a way that support previous uses of the feature.

* Internal to Csound: We have been largely following semantic
versioning and only introduce breaks at major version bumps.  I think
that's worked well and we should follow this.

In this case, the getThis() got changed to intptr_t which, as far as I
understand, is backwards compatible with the previous code for 32-bit
and now correct for 64-bit.  That'd be more of a fix to me than
arbitrary change. For Csound 7, we might consider removing if it isn't
often used and there are other alternatives.

On Tue, Dec 29, 2015 at 7:00 PM, Michael Gogins
 wrote:
> I wrote this method, It supports passing a pointer to the CppSound
> object from scripting languages that don't normally support pointers
> to something that needs a pointer, such as a native application that
> embeds the scripting language, or as userdata to some callback.
>
> Another use is to compile and dynamically load a shared library that
> contains CppSound and not have to export from the library all the
> functions in CppSound; it suffices to export or expose just getThis,
> and then the header files permit every function of CppSound and the
> Csound API in general to be called.
>
> Both of these uses have been implemented at various times. I don't
> currently use getThis, but I can't promise that nobody programming
> with Csound does. so if you take it out you might break somebody's
> code.
>
> In general, there is a built-in conflict between our desire to
> maintain backward compatibility in Csound, and our desire to have a
> well-engineered piece of software with a simple and consistent
> interface. This goes beyond just keeping around old opcodes and
> syntaxes. Maybe we need to be clearer on what must be backwards
> compatible, and what does not necessarily need to be backwards
> compatible.
>
> I think the attitude of the maintainers of Csound, including yourself
> and myself, towards code that we do not understand should be to let it
> alone unless it contains an obvious bug, in which case the bug should
> be fixed if possible. Without an agreed definition of what needs to be
> backward compatible and what does not, just taking stuff out for
> reasons of personal taste or lack of knowledge amounts to dictating
> the form and even the uses of Csound. I'm sure you don't intend to
> convey this impression, but that is how it might look to somebody who
> does not know you.
>
> what is your opinion on what needs to be maintained backwards
> compatible? Opcodes? Sco and orc syntax? C API? C++ API? Language
> wrappers for Python and Java? For Lua? For Lisp?
>
> Best.
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Dec 29, 2015 at 4:05 PM, Steven Yi  wrote:
>> I'm not the author of this, but I suspect it was used from a wrapped
>> language (python?) and passed around like a pointer.  I'd rather we
>> just remove this method as I have no idea what its purpose is though.
>>
>> On Tue, Dec 29, 2015 at 2:58 PM, Felipe Sateler  wrote:
>>> Why not return void*? That would be guaranteed to fit the pointer.
>>> Although a reason for why would one want to use this getThis instead
>>> if &obj (or obj directly if it is already a pointer) eludes me.
>>>
>>> On 29 December 2015 at 16:56, Steven Yi  wrote:
>>>> BTW: I've gotten past this using intptr_t instead of long locally.
>>>> (That should adapt to be appropriate for a size of a pointer).  I'll
>>>> plan to use that when I make a commit unless someone raises an issue.
>>>>
>>>> On Tue, Dec 29, 2015 at 2:50 PM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> mingw64 is complaining about this:
>>>>>
>>>>> long CppSound::getThis()
>>>>> {
>>>>>   return (long) this;
>>>>> }
>>>>>
>>>>> as losing precision.  This makes sense as long is defined as 32-bit
>>>>> and the size of addresses with x86_64 is 64-bit.  Anyone have
>>>>> suggestions?  I imagine someone is using this getThis() function, but
>>>>> it must be problematic for anyone on 64-bit platforms.
>>>>>
>>>>> steven
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,