Hacker News Reader

Comment by HelloNurse | Hacker News Reader

If names must be unique, shouldn't there be a way to resolve conflicts by renaming the modules?

For example, if we use libraries A and B and both want to define module "foo", straightforward compiler options passed when compiling their sources could make the undisciplined libraries produce instead, in the context of our project, modules fooA and fooB and accordingly consume fooA or fooB (found in our project's module stash) where they reference their own module "foo", as if the replacement names had been used in export and import clauses.

Are module names completely erased from actually compiled libraries and executables? What complications am I missing?

View on HN

If names must be unique you don't need to rename them because they are unique.

I'm not being facetious. It's a design choice. Many languages don't but Java and C# for example require modules to have globally unique fully qualified names.

Maybe this was the intention of the C++ committee. C++ does support hierarchical module names so Java style naming is possible. If everyone adopts it then name clashes won't be a problem.

"Everyone" is an awful lot of people. In practice, there will be conflicts and there must be a good plan for handling them. Editing third party source code to change names is not a good plan.

For example, without assuming wrong names on the part of third party developers, a project could compile multiple variants of the same library with the intent of segregating multiple copies of the same symbols (e.g. buried in other libraries as transitive dependencies, in different dynamic link libraries that are selected at runtime, in executable variants that are compiled collectively for convenience).

This would be manageable with explicitly controlled object and library file names, but ambiguous if linking is funneled through ambiguously named modules.

Global uniqueness works in Java. Modules are named with the organisation's DNS name in reverse (guaranteed unique) plus the module name or whatever additional structure you want. So Microsoft's evil module might be `com.microsoft.evil` or `com.microsoft.marketing.web.evil`.

But as you say, this doesn't solve the problem of including multiple versions of the same module.

> But as you say, this doesn't solve the problem of including multiple versions of the same module.

The solution that Java has for that is literally re-writing the bytecode of version A to be "in a different module" and re-writing the bytecode of the code that depends on version A to use the "new" module. That's not going to fly for C++ as I understand it, but maybe I'm missing something.

Java bytecode files are not only portable and well designed but specifically organized with tables of names (so that the bytecode proper can concisely refer to names by index).

The inconvenience of handling a binary format should be much smaller than the challenge of parsing C++ sources to find names.

Reply on news.ycombinator.com