Type inconsistency

In the VST SDK, ParamID is defined to be uint32

typedef uint32 ParamID;			///< parameter identifier

uint32 is then defined this way

#if SMTG_OS_WINDOWS && !defined(__GNUC__)
	typedef long int32;
	typedef unsigned long uint32;
#else
	typedef int int32;
	typedef unsigned int uint32;
#endif

In VSTGUI, ccontrol.h defines this:

virtual void setTag (int32_t val);
virtual int32_t getTag () const { return tag; }

And so it uses int32_t which on Windows is defined to be int… which is not a long (like int32 is mapped to be).

Shouldn’t this API uses int32 instead of int32_t? Is this a bug or is there a very specific rationale for this usage?

Thanks
Yan

Hi,
VSTGUI is a separate module with no dependency to the VST SDK. That’s why some things are different.
Do you have any specific problem with this ?

Cheers,
Arne

I actually did. It is not a showstopper problem since I was able to work around it but yet it is a problem:

I ended up writing some generic code to create some parameters (in my framework), with APIs like those:

template<typename T>
GUIParam<T> registerParam(ParamID iParamID); // ParamID == uint32

template<typename T>
GUIParam<T> registerParam(TagID iTagID) { // TagID == int32
  if(iTagID < 0)
    return {};
  else
   return registerParam<T>(static_cast<ParamID>(iTagID));
}

And then in a view (which inherits from CControl) I end up writing:

void registerParameters() {
  fMyParam = registerParam<T>(getTag());
}

And this code worked fine with macOS/XCode but failed on Windows / Visual Studio Build tools with an error telling me that the call was ambiguous. I can fix the issue by doing:

void registerParameters() {
  fMyParam = registerParam<T>(static_cast<TagID>(getTag()));
}

but that made me realize that there was an inconsistency between the types (on Windows) since int32_t and int32 are NOT the same type. I wished I didn’t have to explicitly cast the tag since it doesn’t seem right to me because it should represent the same type as used in the VST world… It also took me a long time to realize what the actual problem was (especially when dealing with templated code and error messages that are not very friendly). I am sure other people will bump into similar issues one day or another.