3 ms·

But "string" in std isn't ambiguous, precisely because it's in the std namespace. As to why a program would have two classes called string... well, there's a f

by to3m 9y ago

But "string" in std isn't ambiguous, precisely because it's in the std namespace. As to why a program would have two classes called string... well, there's a funny thing there, because it didn't, at least not until it started using this library that does "using std::string" in its header... (Anyway, why is it the library author's concern? They're writing a library! Not only is this the tail wagging the dog, but they're actually making it harder to use, and easier to say no to. Exactly the wrong thing.)

blackflame7000 9y ago
I think we're viewing the issue from 2 different stand points. You are correct that from a library authors perspective they shouldn't impose undue restrictions. I was thinking more along the lines of code maintenance within the same library module where it could be helpful to signal to others that come along that the stl string is the expected default. I think most people would agree that (using...) in the header is a bad idea if the header is intended to be apart of the Public API for the library but I think its use can be justified in a few select instances of internal headers in order to impose cohesive coding convention. If its my library and I don't want other maintainers adding additional string classes internally, I can at the very least force them to use fully qualified names for their alternative string classes to avoid ambiguity. I hate working on code that has 5 different versions of the same freaking thing because each developer decided to implement their own version when the standard way would have sufficed. That was the point I was trying to make. Just like putting const and override on functions, it's a way to help maintainers avoid doing dumb things.
- usefulcat 9y ago
  It kind of sounds like you're looking for technical means by which to "signal to others". In that case, perhaps some documentation (for other contributors/maintainers) could be of use? Beyond that I'm not sure what to suggest. The problem is that even if you have a Really Good Reason for what might otherwise appear to be a bit of gratuitous incompatibility, it's rather unlikely that others will figure out what that reason is without some explanation. IME anyway.
  - blackflame7000 9y ago
    Documentation is only good if people read it... which most developers don't. If someone tried to make a class called string in my module, they would receive immediate feed back from the compiler that there are now multiple definitions of string which should tell them that they are creating another copy of something that already exists. Nevertheless, I'll concede that its not the best way to go about things. But it is something you can do and I wanted to highlight a case of why a "Never do This" feature is even allowed in the first place.
leohotfn 9y ago
Thank you. I have already solved this problem.
deleted 9y ago
[deleted]

by to3m 9y ago

blackflame7000 9y ago

I think we're viewing the issue from 2 different stand points. You are correct that from a library authors perspective they shouldn't impose undue restrictions. I was thinking more along the lines of code maintenance within the same library module where it could be helpful to signal to others that come along that the stl string is the expected default. I think most people would agree that (using...) in the header is a bad idea if the header is intended to be apart of the Public API for the library but I think its use can be justified in a few select instances of internal headers in order to impose cohesive coding convention. If its my library and I don't want other maintainers adding additional string classes internally, I can at the very least force them to use fully qualified names for their alternative string classes to avoid ambiguity. I hate working on code that has 5 different versions of the same freaking thing because each developer decided to implement their own version when the standard way would have sufficed. That was the point I was trying to make. Just like putting const and override on functions, it's a way to help maintainers avoid doing dumb things.

usefulcat 9y ago
It kind of sounds like you're looking for technical means by which to "signal to others". In that case, perhaps some documentation (for other contributors/maintainers) could be of use? Beyond that I'm not sure what to suggest. The problem is that even if you have a Really Good Reason for what might otherwise appear to be a bit of gratuitous incompatibility, it's rather unlikely that others will figure out what that reason is without some explanation. IME anyway.
- blackflame7000 9y ago
  Documentation is only good if people read it... which most developers don't. If someone tried to make a class called string in my module, they would receive immediate feed back from the compiler that there are now multiple definitions of string which should tell them that they are creating another copy of something that already exists. Nevertheless, I'll concede that its not the best way to go about things. But it is something you can do and I wanted to highlight a case of why a "Never do This" feature is even allowed in the first place.

leohotfn 9y ago

Thank you. I have already solved this problem.

deleted 9y ago

[deleted]