From: Warren Young
Date: December 28 2004 9:37pm
Subject: Re: Update for borland builder (BCB6)
List-Archive: http://lists.mysql.com/plusplus/3858
Message-Id: <41D1D232.7080109@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Totte Karlsson wrote:
> The changes I supplied made the library compile with borland. Unfortunatley 
> I don't have time to change the code so I can only supply, as you are 
> saying, a hack.

Then you are going to have to continue to hack it every time you want to 
update a new version of MySQL++.  I will not break MySQL++ features just 
to make the library work with BCBuilder.

> What previous patch? Tell me and I'll try it.

The one where you find out how BCBuilder handles 64-bit integers.

> If everyting compiles and runs, 
> including the examples, then what are using them? 

That's a fine idea, except that all the examples do not compile and run 
without those macros.  They are required for custom*.cc.

> I suggest that when 
> finding code that is not used for anything is removed.

How do you know what everyone else's code looks like?  I sure don't. 
Just because the example programs don't use some piece of code doesn't 
mean that _no one_ uses that piece of code.

> Gives  a "cannot create precompiled header" warning. If everything works 
> after commenting it out, it should be removed I think.

No, you should turn off precompiled headers, or set them up so that the 
precompiled header mechanism stops before you #include mysql++.h. 
There's a #pragma for the latter option, I believe.

> Are you saying that commenting it out breaks the library on other platforms? 

I think it probably breaks any code that uses the 'null' feature of the 
library.

> The statement looks however very puzzling to me..

It seems to create a global constant called 'null', probably one that 
you can assign to fields to insert a null into the database.

> The above code gives a compiler error: "Type mismatch in paramater 
> '__s'(wanted const _STL::string &', got '_STL::string)"

That's bogus.  Type T can be turned into const T& at any time.  I think 
you have a compiler weakness here.  But we'll humor the poor compiler 
and add the parens.

> I think the code is too complex anyway. 

It's a perfectly straightforward statement.

> I don't know whats up with the use of <> for mysql++ headers. I believe is 
> "wrong" the way mysql++ are using it. 

Here are links to how this is handled on VC++ and GCC:

http://msdn.microsoft.com/library/en-us/vccore98/html/_predir_the_.23.include_directive.asp
http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html#Include-Syntax

> <> is used for standard headers and "" is used for user supplied 
> headers. 

That's an oversimplification.  Read the links I gave for the full story.

> Also, having header names such as tiny_int, custom, fields, defs and so on 
> is asking for trouble when mixing with other libraries. Therefore I think it 
> would be a good idea to prefix each header file name with mysqlpp or sqlpp 
> or something that makes the file names unique.

No, the solution is to include the files in their own directory.  Since 
the end user code only #includes mysql++.h, a very unique name, and the 
more generic names are always included with "", there should be no 
conflicts.