-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup: remove using namespace std; #3016
Conversation
Thanks for the quick reaction. This fixes my problem. |
Yes, I saw a couple of those, too. Might fix it later. |
Not too sure about this one ab82c4f I am ready to revert it. |
Eh, what is the specific error we are talking about @ChristopheDumeunier ? Because doing Was there any of that in dlib? There shouldn't be. I don't really want to go mass changing code that isn't breaking. That's invariably how we find out later on some platform something is now broken. |
@davisking Doing Here is a code that reproduce the problem: https://godbolt.org/z/r7T5nqMr5 |
So, in that example, you declare your namespace in a CPP file and include dlib after that? If you just move the code that simulates including dlib to the top of the C++ (where the I am just curious, why would you do that? |
It's a reduced example. In our application, some parts of the unit tests of the code are generated by scripts and macro, the the order of includes can be strange and vary depending on (de)activated dependencies. We use dlib from a long time, without this error. The error appeared when we added a struct named "numeric_limits" somewhere else in our namespace. |
The That's why they say you shouldn't use them globally in header files: so that you don't clash with other people's code. But what you're doing amounts to that: I am closing this PR. |
Well, it's not exactly the same @arrufat Since name lookup is preferred for names in your own namespace. Like if you did Which is generally a thing you shouldn't be doing. But that's fine, dlib is all about being convenient for users, so making these changes is fine with me. I get that people get pushed into doing stuff that is sub-optimal in software and we should make those cases not a pain when we can :) That is to say, I just wanted to know if this was a real problem from real code and work or a "if I break it on purpose it's broken" example. It's with real code, so let's make that real code work since it's probably not going to mess up anything in dlib anyway :) |
I see. Actually, that's why I hurried to make this PR so that I could solve @ChristopheDumeunier's issue. However, you scared me that I might have just broken some quirky compilers/setups by doing that stuff (I saw workarounds for GCC 4.9 while doing this PR). And I wouldn't want to take more of your time with more people opening issues because of me... |
Yeah, maybe just leave that one. IDK. It's an old compiler so I doubt anyone cares. And in general, the easy thing to do is often to replace any |
I think it's safe to remove, as dlib now uses C++14, it doesn't look like GCC 4.9 fully supports C++14: https://en.cppreference.com/w/cpp/compiler_support/14 |
Thanks, looks good :) |
* remove using namespace std from headers * more std:: * more std:: * more std:: on windows stuff * remove uses of using namespace std::chrono * do not use C++17 features * Add Davis suggestion * revert some more stuff * revert removing include * more std::chrono stuff
…PU & CUDA) (#3012) * Fix Stride Indexing Bugs in `reorg` and `reorg_gradient` Functions (CPU & CUDA) and Add `add_to` Parameter * 'add_to' parameter missing in cuda call reorg_gradient.launch_kernel() * Cleanup: remove using namespace std; (#3016) * remove using namespace std from headers * more std:: * more std:: * more std:: on windows stuff * remove uses of using namespace std::chrono * do not use C++17 features * Add Davis suggestion * revert some more stuff * revert removing include * more std::chrono stuff * fix build error * Adjust comment formatting to be like other dlib comments --------- Co-authored-by: Adrià <[email protected]> Co-authored-by: Davis King <[email protected]>
* Fix Stride Indexing Bugs in `reorg` and `reorg_gradient` Functions (CPU & CUDA) and Add `add_to` Parameter * 'add_to' parameter missing in cuda call reorg_gradient.launch_kernel() * Cleanup: remove using namespace std; (#3016) * remove using namespace std from headers * more std:: * more std:: * more std:: on windows stuff * remove uses of using namespace std::chrono * do not use C++17 features * Add Davis suggestion * revert some more stuff * revert removing include * more std::chrono stuff * fix build error * Adjust comment formatting to be like other dlib comments * Add positional encodings layer to Dlib * Implement embeddings_ layer and add supporting utility functions to tensor_tools.h * Updates * Updates * Updates * Updates * Update * Update dlib/cuda/tensor_tools.h --------- Co-authored-by: Adrià <[email protected]> Co-authored-by: Davis King <[email protected]> Co-authored-by: Davis E. King <[email protected]>
Fixes #3015