[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2)
From: |
nine . fierce . ballads |
Subject: |
Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden) |
Date: |
Thu, 23 Jan 2020 04:55:35 -0800 |
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh
File flower/include/file-name.hh (right):
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-name.hh#newcode47
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, lemzwerg wrote:
> This is very ugly.
I sympathize, but it is unambiguous.
> What about using the `std` namespace within a group instead?
It is possible to define a type alias File_name::string that can be used
as "string" in the body of the class definition, in the parameter lists
of File_name member functions (but not in the return values), and in the
bodies of File_name member functions. It would look like this:
class File_name
{
using string = std::string; // C++11
// or in the old style: typedef std::string string;
...
Of course, you would need to do the same for each type or function that
you wanted to avoid qualifying, and you would still have a bad time if
you tried to use it in particular cases where it creates ambiguity.
In a professional setting, I wouldn't advocate using this technique in
such a simple case, but if I had colleagues who loved it, I would put up
with it to keep the peace. I'd ask them not to demand that I follow
their example in subsystems that were my responsibility.
I expect that switching to this style consistently in LilyPond would
require an amount of labor that I am not currently willing to devote.
Thankfully, it seems the consensus on this patch is starting to point
toward "take it" rather than "leave it."
https://codereview.appspot.com/579240043/
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), lemzwerg, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), dak, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), jonas . hahnfeld, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), lemzwerg, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden),
nine . fierce . ballads <=
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), dak, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), dak, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), lemzwerg, 2020/01/23
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), nine . fierce . ballads, 2020/01/24
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), jonas . hahnfeld, 2020/01/24
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), dak, 2020/01/24
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), nine . fierce . ballads, 2020/01/24
- Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by address@hidden), dak, 2020/01/24