Re: [boost] [std_rdb] [rdb] 0.2.02

Subject: Re: [boost] [std_rdb] [rdb] 0.2.02
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-12-07 09:14:59

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_at_[hidden]
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.