GeSndInfo functions "issue"

On 12/09/2016 at 02:13, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   16+ 
Platform:      
Language(s) :     C++  ;

---------
Hi,

this is not really a bug report but a request. I didn't know where to post it otherwise (let me know if there is a spot to post API requests).

The GeSndInfo class member functions:
GetLength & GetSampleRate

Please make the API functions constant as the other member functions. There is no reason for them not to be. I mean it's just a simple open sourced class and I can change the API code accordingly myself but I shouldn't imo.

Currently I am using a wrapper instead so I don't have to touch the API itself but in any case this is unnecessarily annoying.

Thanks

On 12/09/2016 at 02:25, xxxxxxxx wrote:

For anyone running into the same problem, here is my hack to workaround this inconsistency:

  
class GeSndInfoAdapt : public GeSndInfo  
      {  
      private:  
          Float        c_sample_rate;  
          BaseTime    c_length;  
  
      public:  
          GeSndInfoAdapt(void) : GeSndInfo()  
          {  
          }  
          GeSndInfoAdapt(BaseSound *bs) : GeSndInfo(bs)   
          {  
              c_sample_rate = GeSndInfo::GetSampleRate();  
              c_length = GeSndInfo::GetLength();  
          }  
  
          void init()   
          {  
              c_sample_rate = GeSndInfo::GetSampleRate();  
              c_length = GeSndInfo::GetLength();  
          }  
  
          // return the sample rate in Hz  
          inline Float GetSampleRate(void) const { return c_sample_rate; }  
  
          // return the length as BaseTime  
          inline BaseTime    GetLength(void) const { return BaseTime(GetSampleRate() != 0.0 ? (Float)GetSampleCount() / GetSampleRate() : 0.0); }  
      };  

On 13/09/2016 at 04:57, xxxxxxxx wrote:

Hi Samir,

I'll forward your request to development.
In this case it probably won't matter much, but I'm not sure, if having a wrapper which creates copies of member variables doesn't introduce more problems than the missing const'ness of a member function.

On 13/09/2016 at 09:59, xxxxxxxx wrote:

Thanks first of all for forwarding.

Well the GeSnInfo class is really only holding the data retrieved by GetSoundInfo(), so I don't see a problem in copying the member variables. Can you elaborate what problems these could be? I cannot think of any here.

However, the inconsistent treatment of member function definition FORCES me to handle this because otherwise it is impossible to write an interface for my client user with the correct information.

i.e. I cannot define my function const just because GeSndInfo's member functions are not const and therefore the function I am exposing to my client would tell him that there indeed may be changes inside that functions (which is of course nonsense) or to members of the class the function belongs to. This is only the most obvious problem of insufficient function declaration.

Of course, if someone knows of a trick I don't to workaround this more elegantly and without requiring me to change my code design, please let me know. As I said, it's simply very annoying when working on a tight deadline and well, you know clients: "we don't care..get it done". And introducing new data structures is always s**tty, especially when it's only to workaround something to maintain code design. In the end this is about code quality.

Ok, now I got my steam off

On 13/09/2016 at 11:05, xxxxxxxx wrote:

As I said, it won't matter in this case. I just generally don't regard this (holding a copy of members) a good idea.

Just an idea, not sure if it works (and would probably be even more hacky), call via pointer and cast that one into a const, like so:

// private member:
	typedef Float(GeSndInfo::*tFnGetSampleRate)() const;
	tFnGetSampleRate MyConstGetSampleRate = reinterpret_cast<tFnGetSampleRate>(&GeSndInfo::GetSampleRate);
  
// and then:
	inline Float GetSampleRate(void) const
	{
		return (this->*(MyConstGetSampleRate))();
	}

This may crash badly, didn't test it here. If you try it, let me know the result.
In any case this shouldn't be considered a recommendation of MAXON's SDK Support.

On 13/09/2016 at 13:50, xxxxxxxx wrote:

Thanks Andreas for taking the time! Very appreciated.

I am not fully sure but wouldn't this collide with the C++11 standard 5.2.10 as the function type changes with the const qualifier(?) :

A pointer to a function can be explicitly converted to a pointer to a function of a different type. The effect of calling a function through a pointer to a function type that is not the same as the type used in the definition of the function is undefined. Except that converting a prvalue of type "pointer to T1" to the type "pointer to T2" (where T1 and T2 are function types) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified.

I gotta wrap up my knowledge about this (I am not a C++ guru but I try to keep up with the standard as much as possible), still it feels a bit unsafe (and keeping in mind that reinterpret_cast is just a compiler directive).

Though you are right, maybe there is no optimal way to workaround this (also not my member copies hack). The best option would be if the API would adapt here so we wouldn't need to have this conversation in the first place. : )

On 13/09/2016 at 23:24, xxxxxxxx wrote:

Well, I said it's a hack. But I think, it could work, as the const is also just a compiler directive. But I didn't want to suggest this as good practice. I hope, I made this clear. Your request tickled something in my brain and I was just wondering, if there were another workaround.
I'd say, stick with your approach. I forwarded the const request to development and while I won't promise anything, chances for integration are not that bad considering it's so small.

On 14/09/2016 at 03:33, xxxxxxxx wrote:

Yep, didn't take it otherwise!

Thanks for the input Andreas
Cheers