Boost logo

Boost :

From: Corwin Joy (cjoy_at_[hidden])
Date: 2005-08-27 21:18:22

----- Original Message -----
From: "Sebastian Galkin" <paraseba_at_[hidden]>

> Maybe I'm missing something here :
>> Corwin Joy showed some example code that associates binding
>> conversion rules with types from DTL using RTTI names as the key
>> (snip)
> but are you using typeid(short).name() as a map key ? I think the
> standard doesn't guaranties uniqueness for the type_info::name.

This is what I did in DTL, but I don't advocate using RTTI for maintaining
the map of conversion rules here (though it worked well enough since every
compiler I have seen will consistently return the same result when called on
basic types). I think it is
cleaner to simply have typed binding functions. So what I would advocate
is a set of binding functions like this:

class Binding {


enum CType {};

enum DBType{};

PhysicalBufferInfo physical;

Binding operator>>(double &member) {

    CType = TargetType(member);

    DBType = DefaultDBType(member);

    physical = MakeBuffer(member);

    return *this;



class Bindings : map<tstring, Binding> {

// key = field name in the SQL table that the binding is associated with

// tstring = wide or narrow string


So, as before this gets used to bind a field via

struct Employee {

string Name;

double Salary;


MakeBindings(Employee &Emp, Bindings &cols) {

col["Name"] >> Emp.Name;

col["Salary"] >> Emp.Salary;


Notice a couple things about how I propose to do the binding syntax:

1. The binding functions are directly declared and do not use a template
syntax. When I did DTL I first declared binding functions via a template
syntax, but I found that compilers unevenly supported the "explicit" keyword
and I would get unwanted coversions in which binding function was called. I
therefore think it is better to just declare the bindings explicitly.

2. The binding stores

    - the name of the bound field in the database,

    - the type of the C field that is being bound,

    - the type of the SQL field to bind to (this type will have to be
further specialized by each type of DB layer, but maybe we could start with
a set of generic types in a base class that can be further specialized - or
perhaps we must template this on the driver type as well),

    - the address of where to write the data, and the size of the physical
buffer that is available (size only comes into play if one wants to store
fixed length strings - but there may be other things needed here as well).

3. The binding information is stored in an "enum" type fashion rather than
templating on

the member being bound so that these bindings can be created "on-the-fly" at

for queries which don't know the types at compile time.

Boost list run by bdawes at, gregod at, cpdaniel at, john at