If I build a library using: typedef int foo; And then link to this library from code built using typedef int bar; Am I guaranteed that (for any compliant compiler on any system) if there's a foo'd match in the library for a bar'd function call in the main program, that these will link? Even if the type is a template? Even if one isn't a typedef but just 'int' or whatever? Even if one is a member function of a template class whose template parameter is this typedef? Even if another library uses the same typedef name to mean something different?

The fourth one could potentially get you into trouble. It violates the "one definition rule". Offhand, I can't think of any specific problems it would cause on compilers I'm familiar with--name mangling works on the actual type name, not the typedef name--but it's technically incorrect.

Thanks for your replies.
Here's why I'm asking:

- The fourth point is my main concern.

By using a different include path I can alter what a typedef means if the typedef is declared inside a header whose absolute location will vary based on the supplied include path list.

This way I can compile the same library for different variables without resorting to predefined macros. If the types are template parameters, I can provide different specialisations of the same template using the same code, and use them at the same time.

ie:
g++ -o proj/libs/mylib.char.o proj/src/mylib.cpp -I proj/mytype/char
... and more cpp files
ar... (can't remember ar syntax)
(where proj/mytype/char/type.hpp does: typedef char mytype)

g++ -o proj/libs/mylib.wchar_t.o proj/src/mylib.cpp -I proj/mytype/wchar_t
... and more cpp files
ar... (can't remember ar syntax)
(where proj/mytype/wchar_t/type.hpp does: typedef wchar_t mytype)

Now if I want to parse (with a templated parser) a wide-char text file and a byte-char text file using the same parser code within the same binary (for example a single-binary text-editor with RE's), I can, by including the two libraries above.
And I don't need to recompile the parser twice (for the two template versions) when I build the main app since it's defined externally in the two libraries, and not inlined.

It was a toss-up between providing macros or varying typedefs via include directories to the compiler, but I think include directories is more consistent for me.

Checking up on the One Definition Rule (via wikipedia), I don't think this is a technical violation, as each object file is built with only one version of the typedef, and I'm stating what I'm doing explicitly in comments.

Quote:Original post by yacwroy
Checking up on the One Definition Rule (via wikipedia), I don't think this is a technical violation, as each object file is built with only one version of the typedef, and I'm stating what I'm doing explicitly in comments.

The definition needs to be consistent across all compilation units, not merely one object file. It's actually not even possible to violate the ODR with only one object file. I think you may have misunderstood the ramifications of the rule.

Quote:Original post by yacwroy
Thanks for your replies.
Here's why I'm asking:

- The fourth point is my main concern.

By using a different include path I can alter what a typedef means if the typedef is declared inside a header whose absolute location will vary based on the supplied include path list.

This way I can compile the same library for different variables without resorting to predefined macros. If the types are template parameters, I can provide different specialisations of the same template using the same code, and use them at the same time.

Why not just use a template parameter with the typedef name, and instantiate the template with the various types?