By: gallier2 (gallier2.delete@this.gmx.de),
Room: Moderated Discussions
Michael S (already5chosen@yahoo.com) on 6/7/10 wrote:
---------------------------
>gallier2 (gallier2@gmx.de) on 6/7/10 wrote:
>---------------------------
>>Michael S (already5chosen@yahoo.com) on 6/7/10 wrote:
>>---------------------------
>>>gallier2 (gallier2@gmx.de) on 6/7/10 wrote:
>>>---------------------------
>>>>? (0xe2.0x9a.0x9b@gmail.com) on 6/6/10 wrote:
>>>>---------------------------
>>>>>
>>>>>Another example: Let there be static functions FN1 and FN2 which are defined in
>>>>>a single file. Imagine a circular dependency between FN1 and FN2. Imagine the file
>>>>>got bigger and it is painful to maintain it. So, you are thinking about splitting
>>>>>the 1 file into 2 smaller files, placing FN1 and FILE1 and FN2 in FILE2. But, you
>>>>>don't want to expose the functions FN1 and FN2 to the outside world - you want to
>>>>>keep then hidden and be accessible only from the "module" that comprises from files
>>>>>FILE1 and FILE2. Can this be done in C? No, it can not. Imagine another language
>>>>>that is capable of expressing this idea - would you call the language feature that
>>>>>allows you to express this a "syntactic sugar"?
>>>>>
>>>>Easy, split your file as C files and include the .c files directly, it's not very
>>>>common but absolutely allowed and relativly easy to handle.
>>>
>>>It still puts the names in question into global name space. If names are too simple,
>>>project is huge and has no single Czar your solution is asking for trouble.
>>
>>Only for non static names. The statics are only visible inside the compilation unit.
>>The interface of extern objects does not have to change.
>>
>>> Prefix,
>>>as suggested by Linux, is much safer, but also more intrusive and makes textual comparison with old versions harder.
>>>
>>
>
>Sorry, I jumped to posting without really reading you suggestion :embarrassed:
>By now, except from being non-idiomatic and, as such, non-compliant with the principle
>of least surprise you solution should work just fine.
You're right and I wouldn't advocate the use of that solution. In the project I manage (about 200000 lines of C and Pro*C) there is 1 module (dynamic library) where I would need the feature of a third level of visibility besides the global and compilation unit one (a module visibility so to say) as it was built from the splitting of 1 huge Pro*C file. But even in this case I would not use my suggestion above.
> But back in the early 90s
>when namespaces we originally added to C++ language, separate compilation was still
>considered important even at scale of 2-3 modules.
>
In my view, it's more a linker and optimisation problem than anything else, especially with dynamic libraries. Name collisions are relatively rare with some discipline and not really difficult to resolve when encountered.
---------------------------
>gallier2 (gallier2@gmx.de) on 6/7/10 wrote:
>---------------------------
>>Michael S (already5chosen@yahoo.com) on 6/7/10 wrote:
>>---------------------------
>>>gallier2 (gallier2@gmx.de) on 6/7/10 wrote:
>>>---------------------------
>>>>? (0xe2.0x9a.0x9b@gmail.com) on 6/6/10 wrote:
>>>>---------------------------
>>>>>
>>>>>Another example: Let there be static functions FN1 and FN2 which are defined in
>>>>>a single file. Imagine a circular dependency between FN1 and FN2. Imagine the file
>>>>>got bigger and it is painful to maintain it. So, you are thinking about splitting
>>>>>the 1 file into 2 smaller files, placing FN1 and FILE1 and FN2 in FILE2. But, you
>>>>>don't want to expose the functions FN1 and FN2 to the outside world - you want to
>>>>>keep then hidden and be accessible only from the "module" that comprises from files
>>>>>FILE1 and FILE2. Can this be done in C? No, it can not. Imagine another language
>>>>>that is capable of expressing this idea - would you call the language feature that
>>>>>allows you to express this a "syntactic sugar"?
>>>>>
>>>>Easy, split your file as C files and include the .c files directly, it's not very
>>>>common but absolutely allowed and relativly easy to handle.
>>>
>>>It still puts the names in question into global name space. If names are too simple,
>>>project is huge and has no single Czar your solution is asking for trouble.
>>
>>Only for non static names. The statics are only visible inside the compilation unit.
>>The interface of extern objects does not have to change.
>>
>>> Prefix,
>>>as suggested by Linux, is much safer, but also more intrusive and makes textual comparison with old versions harder.
>>>
>>
>
>Sorry, I jumped to posting without really reading you suggestion :embarrassed:
>By now, except from being non-idiomatic and, as such, non-compliant with the principle
>of least surprise you solution should work just fine.
You're right and I wouldn't advocate the use of that solution. In the project I manage (about 200000 lines of C and Pro*C) there is 1 module (dynamic library) where I would need the feature of a third level of visibility besides the global and compilation unit one (a module visibility so to say) as it was built from the splitting of 1 huge Pro*C file. But even in this case I would not use my suggestion above.
> But back in the early 90s
>when namespaces we originally added to C++ language, separate compilation was still
>considered important even at scale of 2-3 modules.
>
In my view, it's more a linker and optimisation problem than anything else, especially with dynamic libraries. Name collisions are relatively rare with some discipline and not really difficult to resolve when encountered.