/* Outputs */
struct sqlite3_index_constraint_usage {
int argvIndex; /* if >0, constraint is part of argv to
xFilter */
unsigned char omit; /* Do not code a test for this constraint
*/
} *const aConstraintUsage;
int idxNum; /* Number used to identify the index */
char *idxStr; /* String, possibly obtained from sqlite3
_malloc */
int needToFreeIdxStr; /* Free idxStr using sqlite3_free() if true
*/
int orderByConsumed; /* True if output is already ordered */
double estimatedCost; /* Estimated cost of using this index */
};
-----------------------------8<---------------------------
I'll try compiling it using the command line compilor however, this
won't rectify using it as a library (.lib) file. Obviously it doesn't
like the use of const without initializing values for integer types.
Suggestions welcome (I can post the entire .h file but that would be...
rediculous?) I appreciate any help (and yes I am very tired).
Stephen
> I'm getting a few puzzling messages especially since this has
> extern "C" {
> }
> defined around it ... BCB's compilor assumes the rules of C++ it appears
I think it's trying to be helpful, but isn't checking enough "stuff"
before it decides the code is wrong. For example, if there are no
constructors, but all data is public, it can still be initialized with
aggregate initialization syntax. But BCB appears to have forgotten to
check that case.
> -----------------------------8<---------------------------
> [C++ Error] sqlite3.h(1778): E2232 Constant member
> 'sqlite3_index_info::nConstraint' in class without constructors
> struct sqlite3_index_info {
> /* Inputs */
> const int nConstraint; /* Number of entries in aConstraint */
> const struct sqlite3_index_constraint {
> int iColumn; /* Column on left-hand side of constraint
> */
> unsigned char op; /* Constraint operator */
> unsigned char usable; /* True if this constraint is usable */
> int iTermOffset; /* Used internally - xBestIndex should
> ignore */
> } *const aConstraint; /* Table of WHERE clause constraints */
Hmm, I'll have to think about it. Are you compiling the library
yourself or trying to link to a binary with only a supplied header?
--
Chris (TeamB);
> Stephen Phillips <som...@someplace.com> writes:
> <duplication truncated>
>
> Hmm, I'll have to think about it. Are you compiling the library
> yourself or trying to link to a binary with only a supplied header?
>
Here is the current 'state' the module sqlite3.c compiles fine however
using the header file C++ spills it's guts all over me. :D
That about sums things up. I am wondering if I need to make some changes
to the compilor settings or start doing odd workarounds. It looks like it
assumes (the compilor) that a struct is a class. This seems a bit ... odd
for it's behavior.
Thanks for the ponderings.
It compiles as itself (IE as the module) fine however linking it with the
header file makes things go crazy. :D
Stephen
> Thanks for the ponderings.
>
> It compiles as itself (IE as the module) fine however linking it with the
> header file makes things go crazy. :D
Unfortunatly, I cannot test with newer versions of BCB to see if this
problem remains.
If you don't force the header to have "C" linkage, you said it works?
Can you simply build the library as C++ as well, and work around the
problem that way?
--
Chris (TeamB);
> Stephen Phillips <som...@someplace.com> writes:
>
> Unfortunatly, I cannot test with newer versions of BCB to see if this
> problem remains.
>
> If you don't force the header to have "C" linkage, you said it works?
> Can you simply build the library as C++ as well, and work around the
> problem that way?
>
Well it builds fine as C code it uses this
/*
** Make sure we can call this stuff from C++.
*/
#ifdef __cplusplus
extern "C" {
#endif
The only fix for this problem is to rewrite the offending section of code,
this will make it not conform to the proper typing conventions for the
struct but it may actually 'accept it'. Since the module is compiled in C
I can redefine it for __cplusplus only, and fix it. Although it seems a
very lame way to fix something like this to be honest.
Stephen
> Unfortunatly, I cannot test with newer versions of BCB to see if this
> problem remains.
>
> If you don't force the header to have "C" linkage, you said it works?
> Can you simply build the library as C++ as well, and work around the
> problem that way?
>
I broke down and removed the const statements and used an #ifdef
__BCBPLUSPLUS__ as to use const or no const in the offending code. This
rectifies the problem however I can't say I like it one bit.
Stephen