Live data from Hacker News

Reuzel – A tiny C++ thread pool

github.com

11–20 of 29 posts

Re: Reuzel – A tiny C++ thread pool

#11

PSA: Please don't do stuff like this in header files: using std::string; It's not cool to impose that decision on clients of the library.

Note that this is not the same as "using namespace std;" since you are only exporting the namespace std::string. This should almost always be ok since no sane programmer should ever name their class string in the namespace of std. As a developer, I wouldn't feel too bad about causing namespace conflicts in this manner because hopefully it will suggest to the maintainer that their class name is a poor choice.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible.

He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no good reason to do it globally.

Re: Reuzel – A tiny C++ thread pool

#12

Earlier quoted context omitted.

Note that this is not the same as "using namespace std;" since you are only exporting the namespace std::string. This should almost always be ok since no sane programmer should ever name their class string in the namespace of std. As a developer, I wouldn't feel too bad about causing namespace conflicts in this manner because hopefully it will suggest to the maintainer that their class name is a poor choice.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible. He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no…

[deleted]

Re: Reuzel – A tiny C++ thread pool

#13

Earlier quoted context omitted.

Note that this is not the same as "using namespace std;" since you are only exporting the namespace std::string. This should almost always be ok since no sane programmer should ever name their class string in the namespace of std. As a developer, I wouldn't feel too bad about causing namespace conflicts in this manner because hopefully it will suggest to the maintainer that their class name is a poor choice.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible. He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no…

But that begs the question why do you have two classes named string to begin with? The ambiguous name choice of string for an alternative to the standard is a terrible idea and all the problems associated with it should be the responsibility of the person making that decision. Putting using std::string in the header would at the very least make whoever is using your class strongly consider the necessity of 2 classes named string. They would be forced to use the fully qualified name for their type instead of ambiguously referring to their alternative string class as string. This prevents future maintainers from getting confused as to why there are 2 versions of the class string.

Re: Reuzel – A tiny C++ thread pool

#14

Earlier quoted context omitted.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible. He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no…

But that begs the question why do you have two classes named string to begin with? The ambiguous name choice of string for an alternative to the standard is a terrible idea and all the problems associated with it should be the responsibility of the person making that decision. Putting using std::string in the header would at the very least make whoever is using your class strongly consider the necessity of 2 classes…

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.)

Re: Reuzel – A tiny C++ thread pool

#15
post #14

Earlier quoted context omitted.

But that begs the question why do you have two classes named string to begin with? The ambiguous name choice of string for an alternative to the standard is a terrible idea and all the problems associated with it should be the responsibility of the person making that decision. Putting using std::string in the header would at the very least make whoever is using your class strongly consider the necessity of 2 classes…

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…

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.

Re: Reuzel – A tiny C++ thread pool

#17

PSA: Please don't do stuff like this in header files: using std::string; It's not cool to impose that decision on clients of the library.

Note that this is not the same as "using namespace std;" since you are only exporting the namespace std::string. This should almost always be ok since no sane programmer should ever name their class string in the namespace of std. As a developer, I wouldn't feel too bad about causing namespace conflicts in this manner because hopefully it will suggest to the maintainer that their class name is a poor choice.

[deleted]

Re: Reuzel – A tiny C++ thread pool

#18
post #14

Earlier quoted context omitted.

But that begs the question why do you have two classes named string to begin with? The ambiguous name choice of string for an alternative to the standard is a terrible idea and all the problems associated with it should be the responsibility of the person making that decision. Putting using std::string in the header would at the very least make whoever is using your class strongly consider the necessity of 2 classes…

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…

Thank you. I have already solved this problem.

Re: Reuzel – A tiny C++ thread pool

#19

Earlier quoted context omitted.

Note that this is not the same as "using namespace std;" since you are only exporting the namespace std::string. This should almost always be ok since no sane programmer should ever name their class string in the namespace of std. As a developer, I wouldn't feel too bad about causing namespace conflicts in this manner because hopefully it will suggest to the maintainer that their class name is a poor choice.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible. He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no…

Thank you. I have already solved this problem.

Re: Reuzel – A tiny C++ thread pool

#20
post #14

Earlier quoted context omitted.

But that begs the question why do you have two classes named string to begin with? The ambiguous name choice of string for an alternative to the standard is a terrible idea and all the problems associated with it should be the responsibility of the person making that decision. Putting using std::string in the header would at the very least make whoever is using your class strongly consider the necessity of 2 classes…

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…

[deleted]
Post reply on HN