Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » signature of the stou function
signature of the stou function [message #833] Fri, 03 February 2006 20:05 Go to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
Wouldn't it be better & more type-safe if the type of the endptr parameter in these functions would be const char **, and const wchar ** ?

unsigned stou(const char *s, void *endptr, unsigned base)
uint64 stou64(const char *s, void *endptr, unsigned base)
unsigned stou(const wchar *s, void *endptr, unsigned base)
Re: signature of the stou function [message #854 is a reply to message #833] Sun, 05 February 2006 16:50 Go to previous messageGo to next message
rylek is currently offline  rylek
Messages: 79
Registered: November 2005
Member
Perhaps you're right. The main practical reason for the above declarations is to avoid the need to have two versions of the function with the 'endptr' argument of type char ** and const char ** (note that, unlike with char * and const char *, char ** cannot be automatically converted to const char **). But perhaps it's better to sacrifice three more lines of code for the sake of clarity, so I'll discuss it with Mirek and I guess we'll agree on changing it.

Regards

Tomas
Re: signature of the stou function [message #871 is a reply to message #854] Mon, 06 February 2006 14:09 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
Another thing I am finding strange is the completely different naming for string->unsigned int and string->signed int conversion functions. Different function name, different parameter name (radix/base). I believe they should rather follow the same naming scheme: ScanInt and ScanUInt.
unsigned      stou(const char *ptr, void *endptr = NULL, unsigned base = 10);
unsigned      stou(const byte *ptr, void *endptr = NULL, unsigned base = 10);
unsigned      stou(const wchar *ptr, void *endptr = NULL, unsigned base = 10);
int           ScanInt(const char *ptr, const char **endptr = NULL, int radix = 10);
int           ScanInt(const wchar *ptr, const wchar **endptr = NULL, int radix = 10);
Re: signature of the stou function [message #873 is a reply to message #871] Mon, 06 February 2006 14:15 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
...different function...

There is an improtant difference - ScanInt etc... are designed to return Null in the case there is no number (U++ way). That is quite a difference from stou etc., which just suplement C library. Note that there is no Null defined for unsigned...

Mirek
Re: signature of the stou function [message #876 is a reply to message #873] Mon, 06 February 2006 14:26 Go to previous messageGo to next message
hojtsy is currently offline  hojtsy
Messages: 241
Registered: January 2006
Location: Budapest, Hungary
Experienced Member
stou returns 0xFFFFFFFF in case of error. Maybe that could be considered as Null for unsigned.
Anyway I think that converting a string to unsigned int, signed int, and double are similar operations and should have similar interface for the client code. So if you can not or do not want to provide an invalid return value, then one more parameter should be added for success indication, or the client code should check the endptr to see if the conversion succeeded. It is not really intuitive for the client programmer to call stou and check for 0xFFFFFFFF for unsigned integers, and call ScanInt and check for Null for signed integers.
Re: signature of the stou function [message #877 is a reply to message #876] Mon, 06 February 2006 14:34 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I see your point, your arguments are correct, however I am not going to define (dword)Null as 0xffffffff - if there are any relations between Null-able types, Null should be < than all other values...

Mirek
Previous Topic: bits/atomicity.h
Next Topic: Xmlize and double
Goto Forum:
  


Current Time: Fri Mar 29 07:38:19 CET 2024

Total time taken to generate the page: 0.03064 seconds