Home » U++ Library support » U++ Core » Value: why not float support?
|
|
| Re: Value: why not float support? [message #30391 is a reply to message #30387] |
Mon, 27 December 2010 14:28   |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i dont mind handling float as double in cpu context, in functions etc. but in my case, sending and receiving is done with distinct types, float and double, unfortunately not interchangeable, it's compareable to storing things  .
well, my problem is actually, that i wanted to use Value as a cool implicit convertable container for arbitrary values (which it is). to save me the hassle of converting them manually, since a lot is already present. but lacking float makes it difficult to use in my case ofcorse. i might need to specify own converters which support float as well beeing a RichValue<>.
use case is indeed: an OSC Method handler receives i.e a Value as parameter, which is to be sent as float: so, if it is double, its converted, if it is int, also, if it's a String, it's tried to be parsed. etc.. thus the interface is really versatile and forgiving.
so i can set up different controls, that 'generate' internally different types (editfield a String, Option a bool/int value) but are sent as float etc.. so i dont need to care about types inside the controls already. i simply specify which type the OSC message should finally be sent as.
|
|
|
|
| Re: Value: why not float support? [message #30392 is a reply to message #30391] |
Mon, 27 December 2010 14:44 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Mon, 27 December 2010 08:28 |
i dont mind handling float as double in cpu context, in functions etc. but in my case, sending and receiving is done with distinct types, float and double, unfortunately not interchangeable, it's compareable to storing things .
well, my problem is actually, that i wanted to use Value as a cool implicit convertable container for arbitrary values (which it is). to save me the hassle of converting them manually, since a lot is already present. but lacking float makes it difficult to use in my case ofcorse. i might need to specify own converters which support float as well beeing a RichValue<>.
use case is indeed: an OSC Method handler receives i.e a Value as parameter, which is to be sent as float: so, if it is double, its converted, if it is int, also, if it's a String, it's tried to be parsed. etc.. thus the interface is really versatile and forgiving.
so i can set up different controls, that 'generate' internally different types (editfield a String, Option a bool/int value) but are sent as float etc.. so i dont need to care about types inside the controls already. i simply specify which type the OSC message should finally be sent as.
|
Well, if I understood well what you have just wrote, I see it as argument NOT TO introduce 'float' into Value... You can put float to Value now (as double). And you have to know the true signature of OSC method anyway, so that you can convert all parameters.
So introducing float would be no advantage here.
Mirek
|
|
|
|
| Re: Value: why not float support? [message #30402 is a reply to message #30392] |
Tue, 28 December 2010 13:47 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
naah...that was not what i meant
anyway, permit another question..
why does Value support int? int64 would do it just the same?
why bool? it's actually an int or even int64 for the cpu / compiler.
so breaking this down, the only meaningfull types would be double and int64, as representing the superset of possible types. which i suppose would be the perfect case.. but in terms of handling it'd be a nightmare, a lot of (int)myval, (bool)myval or myval = (double)myfloat and (int64)myint. why not have Value do all this mess?
if the user decides to represent it's data as double, or as float, or int or int64 he also decides on the resolution he needs, well knowing that this might 'implicitly' reduce some resolution, if coming from double precision i.e..
sorry to bother you with all that. i clearly can understand that you are not well with the thought of extending / breaking a working code just for the benefit of some marginal usecases. i'd do the same. mi point is, that i see a lot more potential in usage of Value than is currently possible. this is genious class that eases handling with types a LOT. but it needs some leverage of burdens.
just to demonstrate: i had to program a typed interface for a gui in our enterprise, and, just because i was 'scared' of Value, knowing it was not able to easy deal with float (because this is what our communication protocol uses the most) left it out to be used. instead, i took a templated approach, inveneted a custom database for objects, etc. etc.. now looking back, having better understood Value and having float support, i'd save me a LOOOT af work and headache.
generally, i'd recommend to enrich Value to support all types which differ in sizeof(), these are the signed variants.. this makes Value really attractive in usage in communication protocols.
bool
char
short
int
int64
float
double
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Mon Apr 29 10:44:38 CEST 2024
Total time taken to generate the page: 0.02960 seconds
|
Members
Pages
Help
Register
Login
Home
