"C++11/14/17 Features In VS 2015 RTM"

[Lynn McGuire]

"C++11/14/17 Features In VS 2015 RTM"
http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx

I wonder what happens to us folks who already have our own tuple methods and have ::std as the global namespace?

i.e., "using namespace std;".

Lynn

[Ian Collins]

Valuable lesson learned!

--
Ian Collins

[Lynn McGuire]

Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.

Lynn

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <l...@winsim.com> spake the secret code
<mma75n$r02$1...@dont-email.me> thusly:

For some, the lesson is that 'using namespace std;' at file scope is a
bad idea. I could go either way depending on the coding standards of
whatever group I'm working in at the time.

I've done:
- 'using namespace fmeh;' at file scope
- 'using namespace fmeh;' at function scope
- 'using namespace bar = the::really::deeply::nested::fmeh;' at file scope

Of course, I also keep my functions and files small. The larger the
unit (function, file, etc.), the harder it is to see these global
settings.

In a header, I always refactor away when I see it:
- 'using namespace fmeh;' at global scope in a header file
- 'using namespace bar = the::really::deeply::nested::fmeh;' at global scope

These end up having non-local interactions that are best avoided.

For others, the lesson is to make sure that your own types are always
inside some namespace that you control. Then your own fmeh::shared_ptr<>
won't clash with std::shared_ptr<>. Namespaces have been around for a
really long time, yet I'm still surprised how few C++ developers use
them effectively, even when examples of good namespace usage abound in
the standard library and places like boost, cinder, etc.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
> For some, the lesson is that 'using namespace std;' at file scope is a
> bad idea. I could go either way depending on the coding standards of
> whatever group I'm working in at the time.

I really can't understand the obsession that people have with
(ab)using "using namespace std;"

It doesn't make the code easier to read and understand, but on the
contrary. Brevity does *not* increase readability and comprehensibility.
In fact, meticulously using the "std::" prefix everywhere increases
readability (you can more quikcly see with a quick scan where standard
library functions and types are being used, and even if you don't know
what something does, you know where to look.)

Perhaps the *only* exception is with some very particular generic code,
which needs to use it for functionality reasons (rather than saving you
typing five characters). For example like:

template<typename Value_t>
Value_t doSomeCalculation(Value_t value)
{
using std::sin; using std::cos;
return sin(value) * cos(value);
}

(This is so that the function can be used with custom types with its
own sin() and cos() functions defined.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[gwowen]

On Tuesday, June 23, 2015 at 12:54:59 AM UTC+1, Lynn McGuire wrote:

> > Valuable lesson learned!
>
> Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.

Don't include <tuple>

[Lynn McGuire]

I do not disagree. It is just with 650K lines of C++ code, it is difficult to add.

At the time, we probably had 500K lines of C++ code. We had to switch compilers and that was an unforeseen problem. Someday, we
will remove the using and add the std:: all over the place, we have been actually doing so for all new code in the last ten years.

Lynn

[Rosario19]

On Tue, 23 Jun 2015 01:29:42 +0000 (UTC),
legaliz...@mail.xmission.com (Richard) wrote:

>[Please do not mail me a copy of your followup]
>
>Lynn McGuire <l...@winsim.com> spake the secret code
><mma75n$r02$1...@dont-email.me> thusly:
>
>>On 6/22/2015 5:19 PM, Ian Collins wrote:
>>> Lynn McGuire wrote:
>>>> "C++11/14/17 Features In VS 2015 RTM"
>>>>
>>http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx
>>>>
>>>> I wonder what happens to us folks who already have our own tuple
>>>> methods and have ::std as the global namespace?
>>>>
>>>> i.e., "using namespace std;".
>>>
>>> Valuable lesson learned!
>>
>>Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.
>
>For some, the lesson is that 'using namespace std;' at file scope is a
>bad idea. I could go either way depending on the coding standards of
>whatever group I'm working in at the time.
>
>I've done:
>- 'using namespace fmeh;' at file scope

as someone said, namespace should be the name of file where there is
the function in cpu instructions... each function has to be identify
1-1 in .executables that call it, by its name and the file where it
is... as
this.dll.namefunctionOrNameOperatorWhathevarMaingligYouWhant

so the way each functions should be called in a file for minimize
space in the code vew would be in each file as:

#define printf namedll.printf
or
#define P namedll.printf

[Öö Tiib]

With somewhat larger codebase it took one day of one person
to get rid of any 'using namespace' in it. It was fast and skilled
person but even man-week is usually insignificant percent from
planned effort with such code-bases.

> At the time, we probably had 500K lines of C++ code.
> We had to switch compilers and that was an unforeseen problem.
> Someday, we will remove the using and add the std:: all over
> the place, we have been actually doing so for all new code in
> the last ten years.

Why someday? Just do it right away when you have any name
clashes. Namespaces *are* meant as tool for avoiding name
clashes.

[Richard]

[Please do not mail me a copy of your followup]

Rosario19 <R...@invalid.invalid> spake the secret code
<7g4noa93b8d33evd5...@4ax.com> thusly:

>On Tue, 23 Jun 2015 01:29:42 +0000 (UTC),
>legaliz...@mail.xmission.com (Richard) wrote:
>>I've done:
>>- 'using namespace fmeh;' at file scope
>
>as someone said, namespace should be the name of file where there is
>the function in cpu instructions.

I don't think you quite understood what I was saying, so I'll elaborate.

I agree it is good advice to define all of your own code inside a
namespace. What you name that namespace is up to you; it is a subjective
decision to say that it "should" be the name of the file containing the
source code. There are other naming policies that are just as good.
So while I say you should put your code in a namespace, I refrain from
telling you what your namespace should be named.

When I say that I've done 'using namespace fmeh;' at file scope, I am
not referring to the namespace enclosing the definitions for that file.
I am using it similarly to an import statement in Java: a way to get
names from some other namespace visible in my source file without
having to be fully qualified.

When you put all your own code inside a namespace, you should never do
a file-scope using directive for the namespace where your code resides.
This makes the compiler do more work to resolve the names you're
attempting to define. Instead your code should be explicitly
surrounded by a named namespace definition.

>#define printf namedll.printf
>or
>#define P namedll.printf

I don't know what you're trying to propose with this, but such abuse of
the preprocessor is a really bad idea IMO.

[Lynn McGuire]

No bugs?

Amazing.

Lynn

[Rosario19]

On Thu, 25 Jun 2015 17:06:54 +0000 (UTC), Richard wrote:
>[Please do not mail me a copy of your followup]
>Rosario19 <R...@invalid.invalid> spake the secret code
><7g4noa93b8d33evd5...@4ax.com> thusly:
>
>>On Tue, 23 Jun 2015 01:29:42 +0000 (UTC),
>>Richard wrote:
>>>I've done:
>>>- 'using namespace fmeh;' at file scope
>>
>>as someone said, namespace should be the name of file where there is
>>the function in cpu instructions.
>
>I don't think you quite understood what I was saying, so I'll elaborate.
>
>I agree it is good advice to define all of your own code inside a
>namespace.

there is no need of C++ namespaces or other namespaces...
namespaces are just the file names where functions are stored
where file names are path+namefile where is the function

for example: directorya\directoryb\namefile.dll.namefunction
give access to one and only one function

because in a file can not be the same name for something
have the same type [or function type]

and in 2 files even if there is the same name and same type it has a
different global name consider the file name that has to be different

>What you name that namespace is up to you; it is a subjective
>decision to say that it "should" be the name of the file containing the
>source code. There are other naming policies that are just as good.
>So while I say you should put your code in a namespace, I refrain from
>telling you what your namespace should be named.
>
>When I say that I've done 'using namespace fmeh;' at file scope, I am
>not referring to the namespace enclosing the definitions for that file.
>I am using it similarly to an import statement in Java: a way to get
>names from some other namespace visible in my source file without
>having to be fully qualified.
>
>When you put all your own code inside a namespace, you should never do
>a file-scope using directive for the namespace where your code resides.
>This makes the compiler do more work to resolve the names you're
>attempting to define. Instead your code should be explicitly
>surrounded by a named namespace definition.

a computer has files
in files there are .dll library and executable
so the only good namespace is file name [+ path]

>>#define printf namedll.printf
>>or
>>#define P namedll.printf
>
>I don't know what you're trying to propose with this, but such abuse of
>the preprocessor is a really bad idea IMO.

but with that i can call functions that are in .dll using assembly and
pheraps in C or C++ too

so one can call all function [and C++ operator too] computer has
without problem
the info is only path+file name and name function

[Öö Tiib]

May be he broke some unit test in process but fixed right away
so his push was clear. Such refactorings should be anyway done
when new version or new library is introduced that causes the
clashes. That can happen at start of maintenance cycle. Clashes
can't suddenly start with release candidate in feature freeze?

[Richard]

[Please do not mail me a copy of your followup]

Rosario19 <R...@invalid.invalid> spake the secret code

<7vfooal3mk0rog9kh...@4ax.com> thusly:

>there is no need of C++ namespaces or other namespaces...
>namespaces are just the file names where functions are stored
>where file names are path+namefile where is the function

I disagree completely.

[Robert Wessel]

On Thu, 25 Jun 2015 13:06:55 -0500, Lynn McGuire <l...@winsim.com>
wrote:

What cases would exist where removing the "using namespace std;" isn't
just going to result in obvious compilation errors for any references
to things in std?

[Richard]

[Please do not mail me a copy of your followup]

Robert Wessel <robert...@yahoo.com> spake the secret code
<hspooapdevhf3k36s...@4ax.com> thusly:

>What cases would exist where removing the "using namespace std;" isn't
>just going to result in obvious compilation errors for any references
>to things in std?

User defined swap?

[Öö Tiib]

There are plenty of cases possible with big enough code written by
people who tend to maximize terseness. They like 'using namespace'
that may cause clashes. They like implicit conversions that sometimes
convert things in unintended ways. They also like short names that
are more likely to cause unexpected name clashes, name hiding or
function overloading.

After removal of "using namespace std;" it may happen that something
is converted to unintended thing or unintended overload is chosen or
any combination of those and there is a defect that does not manifest
itself compile time.

However the real problem is not some individual defect that was
caused by someone wrongly navigating in that fragile puzzle.
Why to waste man-years of maintenance works in context of minefield?
Just invest a week and remove the minefield. Even if some detonate
it is later lot cheaper to do the maintenance works.