Re: Update for borland builder (BCB6)

[Totte Karlsson]

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.

"Warren Young" <mysqlpp@stripped> wrote in message 
news:41D14E5E.9040404@ style="color:#666">stripped...
> Totte Karlsson wrote:
>>
>> The macro NO_LONG_LONGS had to be defined.
>
> There is probably a way to change platform.h so that is not necessary. You 
> probably just have to find out what Borland C++ calls its 64-bit integer 
> type, and supply the appropriate typedefs.
>
> NO_LONG_LONGS really only should be defined for systems that truly lack 
> any 64-bit integer support, like 486es and older.

Don't know of any 64 bit integers using borland..


>> In coldata.h the lines 96, 97, 153 and 154  was commented out
>> //  operator  longlong() const {return conv((longlong)0);}
>> //  operator  ulonglong() const {return conv((ulonglong)0);}
>
> If you supply the previous patch I requested, this code will probably work 
> fine.  If not, then you need to find out what is wrong that causes the 
> faked long-long support to not work here.  Either way, I cannot accept 
> this patch.

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

>> In custom.h line 74 was commented out
>> //#include "custom-macros.h"
>
> Definitely incorrect.  Again, find out what the real cause of the problem 
> is, don't hack around it.

What are these custom-macros doing anyway? If everyting compiles and runs, 
including the examples, then what are using them? I suggest that when 
finding code that is not used for anything is removed.

>> In null.h line 18 was commented out (caused a lot of warnings)
>
> What warnings?

//const null_type null = null_type();
Gives  a "cannot create precompiled header" warning. If everything works 
after commenting it out, it should be removed I think.

> A better approach is to change the code to avoid the warnings.  Failing 
> that, disable the warnings that are inconvenient to code around.  We take 
> both approaches for VC++ compatibility, for instance.

Are you saying that commenting it out breaks the library on other platforms? 
If so, commenting it out is not a good idea of course. The statement looks 
however very puzzling to me..

>> In row.h line 255-257 was changed from
>>    data.insert(data.end(), d[i] ? std::string(d[i], jj[i])  :
>> std::string("NULL"));
>>
>> to
>>        data.insert(data.end(), (d[i]   ? std::string(d[i], jj[i]) :
>> std::string("NULL")) );
>> i.e. missing parenthesis.
>
> The parentheses are not necessary with any Standard-conformant compiler.

I've heard that the borland compiler is pretty close to the standard, but 
I'm probably wrong.

>  Do you get an error or warning without them?
The above code gives a compiler error: "Type mismatch in paramater 
'__s'(wanted const _STL::string &', got '_STL::string)"

 I think the code is too complex anyway. The statement should be broken up 
for greater clarity. Code written like that is asking for trouble. My 
opinion.

 >> Line 4 in /example/util.h was changed from
>> #include <mysql++.h>
>> to
>> #include "mysql++.h"
>
> Wrong.  double-quotes are only for headers expected to be found in the 
> same directory as the #including file.  mysql++.h is always found through 
> the include path.

I don't know whats up with the use of <> for mysql++ headers. I believe is 
"wrong" the way mysql++ are using it. In borland, and I just assume, but may 
be wrong, the difference between <> and "" is how the compiler search for 
files. <> is used for standard headers and "" is used for user supplied 
headers. <> searches in the default directories and "" searches for user 
supplied headers in the following order

 - in the same directory of the file that contains the #include statement
 - in the directories of files that include (#include) that file
 - the current directory
 - along the path specified by the /I compiler option

I think of mysql++ as user supplied software, not as anything standard or 
"system". There seem to be belief that mysql++ is something "system". On 
windows, you would never blend any user headers with system headers such as 
string.h or iostream.h. Instead, when using a user supplied library, you 
will have to give the inlcude path to the headers, simply by using -I. That 
is how all major libraries I have ever used do it, except mysql++.
I think it is confusing, when looking in the mysql++ code, seeing a mysql++ 
header within <>, because it makes me believe it is a standard headers, and 
it is not, of course.

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.

regards
-totte