moc with same file names?

[wysota]

It's best to give those files different names as you'll avoid other problems this way. But you can also divide your project into two subprojects and compile them separately and link together later on.

[cjhuitt]

It's best to give those files different names as you'll avoid other problems this way.

Just out of curiosity, what other problems might this cause?

It might make a difference to mention that this is a reproduction of a problem I was having on a larger project. In the larger one, each different directory's files, while named the same, had different namespaces to distinguish them in the code. I was hoping to be able to avoid typing

#include "Images/ImagesCache.h"
[...]
{
    Images::ImagesCache cache;
    [...]
}

#include "Images/ImagesCache.h"
[...]
{
    Images::ImagesCache cache;
    [...]
}

To copy to clipboard, switch view to plain text mode 

And similar items, as the two mentions of "Images" on each line seem redundant. Of course, I could name the class something other than the file name, but on a large project we try to avoid doing that as well.

[wysota]

Just out of curiosity, what other problems might this cause?

For instance at some point in time you might want to use "-I" options to add include directories to your projects and if you added both directories, one of each dublets would become inaccessible.

It might make a difference to mention that this is a reproduction of a problem I was having on a larger project. In the larger one, each different directory's files, while named the same, had different namespaces to distinguish them in the code. I was hoping to be able to avoid typing

#include "Images/ImagesCache.h"
[...]
{
    Images::ImagesCache cache;
    [...]
}

#include "Images/ImagesCache.h"
[...]
{
    Images::ImagesCache cache;
    [...]
}

To copy to clipboard, switch view to plain text mode 

Then use -I to avoid having to add directory names in each inclusion and modify filenames of the includes.

And similar items, as the two mentions of "Images" on each line seem redundant. Of course, I could name the class something other than the file name, but on a large project we try to avoid doing that as well.

Use -I (that's INCLUDEPATH option in qmake AFAIR) and modify filenames or provide macros that will include proper files

[pdolbey]

Wouldn't the problem with the generated moc files also propagate to your .o (or my .obj) files when they're compiled into your single "Objs" directory before linking into the lib.

In this "single" libary pattern your total cost of ownership would be minimized by an "ImagesCache.h/cpp" rather than "Images/Cache.h/cpp" model - I then tend to combine all (or at least the public ones) the .h files for a library into a single /inc folder to avoid the worse "Images/ImagesCache.h" folder pattern.

You could still use namespaces to discriminate between same named classes, but I'd probably avoid that as well as it increases subsequent documentation effort , code readability, and re-useability - how many systems have to be patched with "std::" namespace to make them work on different platforms?

Just my 5c.

Pete

[cjhuitt]

Wouldn't the problem with the generated moc files also propagate to your .o (or my .obj) files when they're compiled into your single "Objs" directory before linking into the lib.

Yes, the current problem propogates to the object files as well; however, if I could find a relatively straightforward way to change the moc file target (turn Images/Cache.cpp into moc_Images_Cache.cpp, for example), the object files would then be unique as well.

In this "single" libary pattern your total cost of ownership would be minimized by an "ImagesCache.h/cpp" rather than "Images/Cache.h/cpp" model - I then tend to combine all (or at least the public ones) the .h files for a library into a single /inc folder to avoid the worse "Images/ImagesCache.h" folder pattern.

As I stated in the above reply (which you couldn't have seen before you wrote this), we decided as a team to break things up into subdirectories to help with the problem of finding files in a few hundred in any given directory, and also of knowing which subdirectory they are in if all you see in a given file is '#include "ImageCache.h"'.

You could still use namespaces to discriminate between same named classes, but I'd probably avoid that as well as it increases subsequent documentation effort , code readability, and re-useability - how many systems have to be patched with "std::" namespace to make them work on different platforms?

Personally, I think that namespaces don't add much to the documentation effort, but increase code understanding (not necessarily readability) and indirectly increase reusability. Using namespaces allows you to know what "area" or "module" of the code something is in, over and above specific classes, which I think helps understanding. Granted, the same could be done by prepending a given part of a name on all related modules, but that is what namespaces are for. As for reusability, if a lot of namespace scoping is going on, it is a warning sign that the code might lack cohesion, and should be re-examined and maybe refactored. Thus, the namespaces indirectly lead to more reusable code.

As for the problem with the std namespace, a significant factor in that was the delayed addition of the namespace to the code headers/compiler enforcement. In this case, since we will be using namespaces from the start of the project, it shouldn't be a problem.

[pdolbey]

Remember that the original Cache.cpp's have to be compiled as well - the moc files are only generated from the headers - this is where the primary naming conflict comes from.

Pete

[cjhuitt]

Remember that the original Cache.cpp's have to be compiled as well - the moc files are only generated from the headers - this is where the primary naming conflict comes from.

That's a good point, which I had forgotten about. So, in the end it appears easiest to keep the names different after all.

[pdolbey]

Well actually I thought about this on the way home. One negative point and one positive.

The negative point is the from a "re-usability" point of view the entire concept of two "cache" objects seems broken anyway - what about generic classes or templates?

However the positive thought was that if you wanted to follow your pattern, then it shouldn't be too difficult to generate your own version of qmake (qmake2) that for a line in the pro file like SOURCES += Images/Cache.cpp forces the compiler directives to emit Images_Cache.o into the Objs folder - this should also work for your moc_ files. After all this is open source...

Pete

[cjhuitt]

For instance at some point in time you might want to use "-I" options to add include directories to your projects and if you added both directories, one of each dublets would become inaccessible.

You are correct about the include paths, and we have talked about that in my team. Our decision was that, since our older project had a problem with so many files in one directory, we would be splitting them out in multiple subdirectories for our new project. Along with this was the decision to only put the base directories in the include directories options, so that the subdirectory paths would need to be included in order to include the header file. This way, if you were looking at one code file that included another, it would be easier to find the file being included. (Yes, we have had problems with finding the included file. Nothing a find can't solve, but that gets annoying after a while.)

Given that, I was hoping that there was some way to reduce the file names, but I haven't found a simple way to do that yet since the qmake/moc combo presents problems if the files have the same name.

Our current best bet solution is to have multiple subdir project files, until the actual code, but that presents other problems -- namely, not being able to intermix "general" code files in directories that have subdirectories, and generating a lot of smaller library files that will all need to be tracked and linked into the final executable.