On Tue, 5 Feb 2013 01:53:27 +0000 Mateusz Loskot <[email protected]> wrote:
ML> Here are my findings: ML> ML> 1) Here is old thread "unsigned int and SOCI" from 2010 in which Maciej ML> explains reasoning behind certain decisions regarding lack of unsigned int ML> mapping: ML> ML> http://sourceforge.net/mailarchive/message.php?msg_id=24344961 ML> ML> 2) I found some forgotten work made by Julian Taylor: ML> ML> http://sourceforge.net/mailarchive/message.php?msg_id=26994744 Interesting, thanks. I have to say that I had no idea about this previous work (and probably would have avoided touching this code at all if I read the first thread and knew it was such a controversial area). My changes were motivated solely by the desire to avoid internal inconsistencies in SOCI. ML> 3) Latest changes related to integer types support were made by Vadim, ML> here are two important commits: ML> ML> a) Handle unsigned integer types as their signed versions. ML> ML> https://github.com/SOCI/soci/commit/2a8840505ba67b4413c6cd9192965d95f1d0805c I.e. this commit prevents SOCI from treating "unsigned short" as "unsigned long long" instead of "short". Arguably, having separate mapping for "unsigned short" and "short" might be even better but if we have to choose between the existing types, I hope everybody can agree that mapping it to "unsigned long long" doesn't make much sense. ML> b) Remove dt_unsigned_long and x_unsigned_long type constants. ML> There is no need for a separate type for "unsigned long" as we don't have ML> special types neither for "unsigned int" nor for "long" ... ML> ML> https://github.com/SOCI/soci/commit/4f8bc05242e6e5dfc6c4d003049c44ca62890cd9 This was also just an inconsistency, having dt_unsigned_long but not dt_unsigned_{short,int} didn't make any sense IMHO. ML> AFAIU, the action in 3) clears all the doubts discussed in 1) I don't think so. Ideally support for unsigned types in into() would check that we're really reading a positive value whereas currently I think it will happily cast a negative int to unsigned too (but I didn't check it). So ideally we'd need to perform the checks done in src/core/unsigned-types.h somewhere... ML> and also moves the work in 2) out of scope of SOCI. Right? Again, I'm not sure about this. I think having support for [u]intN_t could be useful as I did already have problems with sizeof(long) being different between platforms. OTOH I think support for these types should be added while preserving support for the normal C short/int/long types instead of replacing them as Julian Taylor's branch seems to do. ML> I believe, it's important to summarise the current status of integer ML> types support in SOCI, together with a few words of explanation why ML> certain decisions have been made. Such summary should go into docs. This would be definitely useful. ML> I'd like to do it, but I realised the current status is unclear to ML> myself too. Unfortunately I can't say I understand everything neither :-( ML> A few basic questions I'd like to clarify in the docs: ML> ML> 1. What C++ integer types are supported (mapped) and usable with into/use? I believe the answer is: char, [unsigned] short/int/long/long long. Somewhat surprisingly, not "unsigned char". ML> 2. What C++ integer types are not mapped? Why? AFAICS only "unsigned char" isn't. I don't know why, I think it's just an omission. ML> 3. When we decide what integer types to map, which side has the higher ML> priority, SQL types or C++ types? ML> IOW, do we aim to cover as many SQL types as possible, then decide ML> how to map them to C++ types; or we aim to map as many C++ types ML> as possible, and then decide how those fit the SQL types? I think the goal is to be able to save values of any standard C++ type in the database and read it back, so from this point of view you could say that C++ has priority. OTOH, in principle, we could also add custom types to represent SQL types not available in C++. So I don't see the 2 approaches as contradictory, rather they're complementary. ML> Also, If the C++ types have higher priority, then what about Julian's ML> proposal. Wouldn't it make sense to switch the API to C99-based integer ML> types? As I wrote above, I think it would be nice to have support for, say, uint32_t. But I don't believe it's a good idea to drop support for int or unsigned int, both should be available and the application programmers should use the one that is more appropriate. E.g. when writing some new code from scratch, it would probably make more sense to use intN_t types explicitly. But when adding database support to some existing code, which uses many int/long/unsigned variables it would definitely be much more convenient to work directly with them instead of having to convert them to/from sized types all the time. Regards, VZ
pgp6vC1luQG18.pgp
Description: PGP signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
