I have uploaded a new release to the vault. It contains : * support for the float type. Internals have been cleaned up to make it easier to add new types * SQLGetData is not used anymore, result_set uses bound variables to read results I am a bit concerned about compilation time. Guess I'll have to take a look at the template profiler as well. I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ... Opinions on this ? Jean-Louis
Jean-Louis Leroy wrote:
I have uploaded a new release to the vault. It contains :
* support for the float type. Internals have been cleaned up to make it easier to add new types
* SQLGetData is not used anymore, result_set uses bound variables to read results
I am a bit concerned about compilation time. Guess I'll have to take a look at the template profiler as well.
I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ...
Opinions on this ?
Jean-Louis
There is some precedent with this type of naming in phoenix and spirit. I have gotten used to the underscore convention and personally like it. I'm not a fan of the capitalization scheme though I suspect it might find more appeal to those who do more DB work than I. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Hi Jean, 2009/11/25 Michael Caisse <boost@objectmodelingdesigns.com>
Jean-Louis Leroy wrote:
I have uploaded a new release to the vault. It contains :
This looked interesting last time I checked. Do you have a direct link?
I use float_ (note: underscore) for the variable type for receiving float
values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ...
There is some precedent with this type of naming in phoenix and spirit. I have gotten used to the underscore convention and personally like it. I'm not a fan of the capitalization scheme though I suspect it might find more appeal to those who do more DB work than I.
+1 for using float_. The precendent for this is quite firmly set, I think. I don't like the uppercase SELECT, etc. though. While it does mimic SQL, it makes it looks like a macro. The Boost style guide recommends against using uppercase letters in names. Cheers, Darren
Darren Garvey wrote:
Hi Jean,
Jean-Louis or J-L please or the others are going to believe that I'm a girl ;-)
This looked interesting last time I checked. Do you have a direct link?
2009/11/25 Jean-Louis Leroy <jl@yorel.be>
Darren Garvey wrote:
Hi Jean,
Jean-Louis or J-L please or the others are going to believe that I'm a girl ;-)
Heh no problem, what about Jean Reno[1]? This looked interesting last time I checked. Do you have a direct link?
On a side note, have you ever looked at the syntax employed by litesql [2]? eg: class Person; // class definition generated from XML. Database db; // also generated. vector<Person> people = select<Person>(db).all(); Person jim = select<Person>(db, Person::Name = "Jim").one(); The source code for Person / Database would be generated from an XML database definition. I'm not entirely sure about the idea of that, but the final syntax is very nice to use. You've mentioned before that you eventually aim to use your library as a base for an ORM-style library, so hopefully you can take some inspiration from that library. Cheers, Darren [1] - http://en.wikipedia.org/wiki/Jean_Reno [2] - http://sourceforge.net/apps/trac/litesql/
Jean-Louis Leroy wrote:
I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ...
I'm troubled by something named so like a built-in type behaving differently (the length/null indicator). I know the names are in a namespace, but given a using directive, they won't be scope resolved. "FLOAT" is definitely out as it looks like a macro. "Float" is against Boost naming conventions. That would seem to leave only an affix to modify the type name. The affix should be short, too, for convenience. Here are a couple of ideas; some are too long: db_float rdb_float nullable_float optional_float "rdb_float" is troubling because it would appear in the "rdb" (perhaps "std::rdb") namespace, so "rdb" is duplicated. Perhaps using a name that deviates from the type name a bit, like "fp," "boolean," etc., would work well. You mentioned the potential conflict with select(). I doubt such code would be in the same translation unit, but even if it were, "rdb::select" and "::select" will remove the ambiguities. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Jean-Louis Leroy wrote:
I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ...
I'm troubled by something named so like a built-in type behaving differently (the length/null indicator). I know the names are in a namespace, but given a using directive, they won't be scope resolved.
"FLOAT" is definitely out as it looks like a macro. "Float" is against Boost naming conventions. That would seem to leave only an affix to modify the type name. The affix should be short, too, for convenience. Here are a couple of ideas; some are too long:
db_float rdb_float nullable_float optional_float
"rdb_float" is troubling because it would appear in the "rdb" (perhaps "std::rdb") namespace, so "rdb" is duplicated.
what about float_ living in rdb : rdb::float_ ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
joel falcou wrote:
Stewart, Robert wrote:
I'm troubled by something named so like a built-in type behaving differently (the length/null indicator). I know the names are in a namespace, but given a using directive, they won't be scope resolved.
what about float_ living in rdb : rdb::float_ ?
Allow me to quote me:
I know the names are in a namespace, but given a using directive, they won't be scope resolved.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Allow me to quote me:
I know the names are in a namespace, but given a using directive, they won't be scope resolved.
OK, I'm sorry to be dense atm, but I missing the point :( -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
joel falcou wrote:
Stewart, Robert wrote:
Allow me to quote me:
I know the names are in a namespace, but given a using directive, they won't be scope resolved.
OK, I'm sorry to be dense atm, but I missing the point :(
Given this: namespace std { namespace rdb { struct float_; } } You can have this: using namespace std::rdb; void f() { float_ f; } That is, the names lose the "rdb" part and you're left with "float_," that is spelled almost the same as the built-in type, but that has different behavior. At the least, float_ would include the length/null indicator, but it's behavior will be subtly different from that of float because we can't make UDTs behave completely like built-ins. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (6)
-
Darren Garvey -
Darren Garvey -
Jean-Louis Leroy -
joel falcou -
Michael Caisse -
Stewart, Robert