Jay Pipes wrote:
Monty Taylor wrote:
Jay Pipes wrote:
Right. If it was included as:
#include "libmemcached/string.h"
I don't believe there would be any conflicts.
This might be bikesheddy stuff, but I'm in favor of not prefixing
filenames with "i" or "f" or stuff like that if there is a solution of
just using the proper #include directive...
I think this is important to work on - given the other cleanup we're
doing.
I know we had to prefix decimal.h with f in the field split - but I'm
not sure _why_. I think it was before we went to prefixing all includes
with full paths.
In fact - I just checked, and in fact, moving drizzled/field/fdecimal.h
drizzled/field/decimal.h works.
So...
My vote is for drizzled/item/string.h ... and if that breaks something,
lets try to figure that out.
+1.
-jay
Hi,
I just looked in C99, and if I understand section 6.10.2 correctly it
says that it will include the contents of the entire source file
identified by the specified sequence between the "". If that fails, it
will search as if you specified #include <>, and will search for a
header identified uniquely by the specified sequence between the <>.
The only way #include "something/string.h" can conflict with a header
provided by the compiler would be if "something" was included to the
standard (or if you choose a name that conflicts with a header such as
sys/types.h ;)
So I agrees with Jay and adds my +1 for: #include "drizzled/item/string.h"
Trond
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
