[patch] row::operator[] - template version

#1

Here's the template version of the patch, for evaluation.

Applies to CVS.

- Chris

Index: lib/row.h
================================================== =================
--- lib/row.h (revision 1119)
+++ lib/row.h (working copy)
@@ -119,11 +119,10 @@
/// supposed to throw an exception, according to the Standard.
///
/// This function is just syntactic sugar, wrapping the at() method.
- /// The at() method is the only way to get at the first field by
- /// index, as row[0] is ambiguous: it could call either overload.
///
/// See operator[](const char*) for more caveats.
- const ColData operator [](size_type i) const
+ template <class IndexT>
+ const ColData operator [](IndexT i) const
{
return at(i);
}

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#2

(btw, please feel free to reply to the list... I know the list config doesn't
make that easy, but we need to have valuable input like yours archived) :-)

On Sat, Sep 17, 2005 at 11:35:37PM -0400, pps wrote:

Quote:

Chris Frey wrote:
Here's the template version of the patch, for evaluation.

Applies to CVS.
/// See operator[](const char*) for more caveats.
- const ColData operator [](size_type i) const
+ template <class IndexT
+ const ColData operator [](IndexT i) const
{

I had a similar problem where properties could be accessed by their
indeces or by their names. My first solution was also like this: one of
the functions is plain method and the other is templated. But I later
found out that there were some problems with it - it just worked on some
compilers (or something like this, not sure what the problem was
exactly, but I had to redo it)

I'd be interested in what kind of errors the above patch could cause.

I suppose the template/non-template could confuse some compilers. If so,
we could get rid of non-template members completely, and make a specialization
for the const char * version. That should work.

I haven't tried my patch on windows, so I don't know if there are funky
errors there. mysql++ can only be compiled on fairly recent compilers
(VC7.0 doesn't even do it, so I hear), so maybe this is a non-issue, since
all supported compilers may handle it.

Could you run a test compile and let us know, on WinXP?

Quote:

my final solution was two templated methods that use boost::enable_if &
boost::mpl::not_ & boost::is_integral
basicly, it enables int version for integral types and non-int for
non-integral types. (obviously it's better to use enable_if and
disable_if, but this combination has some problems on vc i think)

in short it looks something like this:
template<class T
typename enable_if< is_integral<T>, return_type>::type
operator[](const T& a){ ... }

template<class T
typename enable_if< not_<is_integral<T> >, return_type>::type
operator[](const T& a){ ... }

all the things used here (enable_if etc.) are really simple to implement.

That's good, because I don't think we can, or want to, add boost to the
build dependencies.

I'll have to read up on enable_if. Some of the things that boost manages
to do with C++ really surprise me. I just looked at the new parameter
library, and wow. :-)

Quote:

One another solution is to take only c-arays of chars, and not pointers
(row[] is almost always used in this way: either row["c-array"] or const
char a[] = "c-array"; row[a])
for this case something like this will work:

template<unsigned int N
return_type operator[](const char(&a)[N]){ ... }
return_type operator[](unsigned int){ ... }

This looks interesting, and similar to libpqxx, except for the templates.
I think const char* behaviour is worth keeping though.

Thanks for the feedback,
- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#3

Chris Frey wrote:

Quote:

(btw, please feel free to reply to the list... I know the list config doesn't
make that easy, but we need to have valuable input like yours archived) :-)

I'm used that in most other mailing lists reply replies to the list
(here I need to "reply all", but I forget sometimes)

Quote:

I had a similar problem where properties could be accessed by their
indeces or by their names. My first solution was also like this: one of
the functions is plain method and the other is templated. But I later
found out that there were some problems with it - it just worked on some
compilers (or something like this, not sure what the problem was
exactly, but I had to redo it)

I'd be interested in what kind of errors the above patch could cause.

I don't remember, but I really had to redo it

Quote:

I suppose the template/non-template could confuse some compilers. If so,
we could get rid of non-template members completely, and make a specialization
for the const char * version. That should work.

The problem is that there's no such thing as partial template
specialization for members. If you have two templates with the same
signature, there's good chance a wrong template gets selected (resulting
in compile error or worse, wrong code being executed). For control of
instantiation of templates SFINAE (substitution-failure-is-not-an-error)
principle used. enable_if exploits this thing.

aproximately how it works:

template<bool B, class T> struct enableif{};
template<class T> struct enableif<true, T>{ typedef T type; };

template<class T> struct isint{ enum{ value= false};};
template<> struct isint<int>{ enum{ value= true};};

template<class T> struct isnotint{ enum{ value= true};};
template<> struct isnotint<int>{ enum{ value= false};};

struct test{
template<class T>
typename enableif<isint<T>::value, void>::type
operator[](const T&){ cout << "int version\n"; }
template<class T>
typename enableif<isnotint<T>::value, void>::type
operator[](const T&){ cout << "non-int version\n"; }
};
....
test x;
x[0];
x["dsds"];

but in this example long will be considered non-int also, unsigned int
also etc (extra specializations are needed for long, char, and
unsigned/signed versions).
Anyways boost::enable_if docs are worth to read to understad this
better. ( http://tinyurl.com/d2pqk ) It will probably be included in the
next cXX standard, as far as I'm concerned.

Quote:

I haven't tried my patch on windows, so I don't know if there are funky
errors there. mysql++ can only be compiled on fairly recent compilers
(VC7.0 doesn't even do it, so I hear), so maybe this is a non-issue, since
all supported compilers may handle it.

The problem was not with the old compilers - on the other had I had
problems only with some new I think (vc8 or g++34, not sure), anyways,
most of my code barely/rarely compiles on 2.95 so I don't care for these
compilers.
May be I'm little bit wrong about this problem for this case, as I
recall there was a problem because my class was also templated and you
cannot put specializations inside the class deffinition, but there were
no way to do it outside of the class (specialization of templated class)

Quote:

Could you run a test compile and let us know, on WinXP?

I don't know how to compile it !!!

I'll look around for the patch on the list to be able to compile it, or
I'll create my own project files from zero...

Quote:

That's good, because I don't think we can, or want to, add boost to the
build dependencies.

I'll have to read up on enable_if. Some of the things that boost manages
to do with C++ really surprise me. I just looked at the new parameter
library, and wow. :-)

all that stuff from boost are compile time only. probably it's not worth
to make it depended on boost anyways

), but it's ok to rip off that
parts if needed, boost allows that

Quote:

template<unsigned int N
return_type operator[](const char(&a)[N]){ ... }
return_type operator[](unsigned int){ ... }

This looks interesting, and similar to libpqxx, except for the templates.
I think const char* behaviour is worth keeping though.

I just remebered, later I changed design and the need for templated
version dissapeared I think

I wrote auxilary string class (str_range) that holds pointer and length
(or pointer to the end, whatever).
it's automatically created from arrays and pointers (it has non-explicit
constructors. For arrays it doesn't calculate the length)

and then I only had this:
ret_type operator[](int x){...}
ret_type operator[](const str_range& s){...}

and in case I used [0] then it would need to be converted from int to
pointer, then from pointer to str_range. So I think compiler desided
that it was easier to use int version

. Not sure if it's ok like this
- but it worked in all the cases and all compilers I use.

I asked some question related a bit to that my problem, I found it on:
http://tinyurl.com/atonx

I think the problem was only related to my case where the class itself
was templated and that caused the problem...

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#4

On Sun, Sep 18, 2005 at 12:30:49PM -0400, pps wrote:

Quote:

I'd be interested in what kind of errors the above patch could cause.

I don't remember, but I really had to redo it

I suppose the template/non-template could confuse some compilers. If so,
we could get rid of non-template members completely, and make a
specialization
for the const char * version. That should work.

The problem is that there's no such thing as partial template
specialization for members. If you have two templates with the same
signature, there's good chance a wrong template gets selected (resulting
in compile error or worse, wrong code being executed). For control of
instantiation of templates SFINAE (substitution-failure-is-not-an-error)
principle used. enable_if exploits this thing.

Thanks for the detailed email. I had to read up on this to fully
understand it. Google's cache came in handy, as the most informative
site didn't respond: http://tinyurl.com/cemw6

But as you noted elsewhere in your email, we are not using this in a
templated class, so the only problem is that the template may match
more types than it should, for the integer case.

The good news is that the integer template case just calls row::at(),
which only has an integer argument. If I understand SFINAE correctly,
if the integer doesn't fit with at(), the template won't be considered.
It will fail with non-integer arguments in any case, which is fine. :-)

I don't know off hand, without testing, which style will produce the
clearest error messages for the user.

Quote:

Could you run a test compile and let us know, on WinXP?

I don't know how to compile it !!!

I'll look around for the patch on the list to be able to compile it, or
I'll create my own project files from zero...

The development site is: https://gna.org/projects/mysqlpp/
You can grab the latest makemake.bat file here:
http://svn.gna.org/viewcvs/mysqlpp/trunk/

- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#5

On Sun, Sep 18, 2005 at 12:30:49PM -0400, pps wrote:

Quote:

I'd be interested in what kind of errors the above patch could cause.

I don't remember, but I really had to redo it

I suppose the template/non-template could confuse some compilers. If so,
we could get rid of non-template members completely, and make a
specialization
for the const char * version. That should work.

The problem is that there's no such thing as partial template
specialization for members. If you have two templates with the same
signature, there's good chance a wrong template gets selected (resulting
in compile error or worse, wrong code being executed). For control of
instantiation of templates SFINAE (substitution-failure-is-not-an-error)
principle used. enable_if exploits this thing.

Thanks for the detailed email. I had to read up on this to fully
understand it. Google's cache came in handy, as the most informative
site didn't respond: http://tinyurl.com/cemw6

But as you noted elsewhere in your email, we are not using this in a
templated class, so the only problem is that the template may match
more types than it should, for the integer case.

The good news is that the integer template case just calls row::at(),
which only has an integer argument. If I understand SFINAE correctly,
if the integer doesn't fit with at(), the template won't be considered.
It will fail with non-integer arguments in any case, which is fine. :-)

I don't know off hand, without testing, which style will produce the
clearest error messages for the user.

Quote:

Could you run a test compile and let us know, on WinXP?

I don't know how to compile it !!!

I'll look around for the patch on the list to be able to compile it, or
I'll create my own project files from zero...

The development site is: https://gna.org/projects/mysqlpp/
You can grab the latest makemake.bat file here:
http://svn.gna.org/viewcvs/mysqlpp/trunk/

- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#6

Chris Frey wrote:

Quote:

Could you run a test compile and let us know, on WinXP?

I don't know how to compile it !!!

I'll look around for the patch on the list to be able to compile it, or
I'll create my own project files from zero...

The development site is: https://gna.org/projects/mysqlpp/
You can grab the latest makemake.bat file here:
http://svn.gna.org/viewcvs/mysqlpp/trunk/

I tried that makemake.bat, but it didn't work for me.
README.vc says that makemake vc creates makefiles and builds libraries,
but it doesn't build anything. running nmake produces this error:

cd lib && nmake BIN_DIR=debug all example_setup

Microsoft (R) Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.

makefile(27) : fatal error U1000: syntax error : ')' missing in macro
invocation

Stop.
(It's inside lib/Makefile)

I installed mysql using windows installer. the installation dir isn't
c:/mysql, how do I specify it, or I simply need to set enviroment
variable MYSQL_DIR??

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#7

Chris Frey wrote:

Quote:

For unix, if you're building from svn, you'll need to run all the autoconf
tools. There is a 'bootstrap' script to make that easy. So far I haven't
had any trouble with the autoconf side of things.

To specify a different compiler, I use a command line like this (assuming
I've built gcc-4.0.1 and installed it in /home/source5/rootdir-gcc401):

./configure --prefix=/usr/local \
CC=/home/source5/rootdir-gcc401/bin/gcc \
CPP=/home/source5/rootdir-gcc401/bin/cpp \
CXX=/home/source5/rootdir-gcc401/bin/g++ \
CXXCPP=/home/source5/rootdir-gcc401/bin/cpp

I can use a compiler built in any old home directory using this. To run the
results using a new compiler like gcc-4.0.1 when my system compiler is
gcc-3.3.6, I have to do:

export LD_LIBRARY_PATH=/home/source5/rootdir-gcc401/lib

After I downloaded mysqlpp using svn, what's the next step to do??
makemake.sh or configure?? I doesn't make alot of sence to me that it
has boostrap script or all autoconf tools - I don't really know that
therminology

Most of the distributions have a readme that tells what
to do and almost always it's ./configure && make install clean
with mysqlpp I don't know where to start from. (makemake.sh fails,
there's no configure script etc.)
I use FreeBSD, it has a really nice ports collection, but it has older
version of mysql++ (1.7.x); with freebsd all I'd need to do to install
mysqlpp would be: cd /usr/ports/databases/mysql++; make install clean;
which downloades sources, configures and installs it (with all dependent
software using the right compiler). With freebsd there's no need to
specify extra LD_LIB_PATH etc, all is needed is to use g++34 instead of
g++ - it figures out where correct library is located by itself...

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#8

On Mon, Sep 19, 2005 at 12:30:53AM -0400, pps wrote:

Quote:

Chris Frey wrote:
For unix, if you're building from svn, you'll need to run all the autoconf
tools. There is a 'bootstrap' script to make that easy. So far I haven't
^^^^^^^^^

Quote:

After I downloaded mysqlpp using svn, what's the next step to do??
makemake.sh or configure?? I doesn't make alot of sence to me that it
has boostrap script or all autoconf tools - I don't really know that
therminology

Most of the distributions have a readme that tells what
to do and almost always it's ./configure && make install clean
with mysqlpp I don't know where to start from. (makemake.sh fails,
there's no configure script etc.)

The configure script is in the tarball... it just doesn't make much sense
to put the configure script in SVN, since it changes so often, and is
purely a generated file. So when using SVN, you have to run ./bootstrap,
which handles the series of automake, autoconf, etc calls for you, and when
that's done, you'll have a ./configure that you can use normally.

Quote:

software using the right compiler). With freebsd there's no need to
specify extra LD_LIB_PATH etc, all is needed is to use g++34 instead of
g++ - it figures out where correct library is located by itself...

I only used LD_LIBRARY_PATH because the libs were not in a standard spot.
I like putting test compilers and software in home directories of their
own... makes it easier for me to tinker on things completely separate
from my normal system.

It's just how I do it... you likely won't need it if you have all the compilers
you need installed on your system.

- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#9

pps wrote:

Quote:

README.vc says that makemake vc creates makefiles and builds libraries,

That shouldn't be the case if you're reading the one from the
repository. The released version still says that, erroneously, because
it was true before the last release.

Quote:

running nmake produces this error:

We no longer use nmake on Windows. Use GNU make instead, per README.vc.

Quote:

I installed mysql using windows installer. the installation dir isn't
c:/mysql, how do I specify it,

There's a button that lets you customize the install. Or, you can edit
the Makefile.base files and re-run makemake.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#10

pps wrote:

Quote:

There seem to be to many dirrectories that are
hardcoded into makefiles:

"Hardcode" is too harsh a term here. It's not like this is a
distributed executable or something like that. It's easy to change the
Makefile.base files for your own needs.

Quote:

had to manually create config.h etc...

The Windows side doesn't depend on config.h at all, as far as I can see.
If you mean on the Unix side, then Chris's comments about the
bootstrap script are appropriate.

Quote:

I tried to run makemake.sh,

That's only used internally on the Unix side, to create the
Makefile.simple files. That's why it isn't documented.

Quote:

After when I replaced /usr/bash with something suitable for me it gave
out some warnings (line 32: [: ==: unary operator expected)

That's because it really, really, really does require bash.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw