Request for build feedback

[Jorgen Grahn]

It would be evil if it was done with the hope of confusing
others.

I think what he and Ike Naar are getting at is that the only possible
reason for such a pair of constructs (a subnamespace named "std" and a
using) is a deliberate attempt, from the library writer, to mess with
you. And it's a system built on trust anyway: for example you trust
an official version of libfoo not to contain something like

if(std::rand()==4711) system("rm -rf /");

/Jorgen

 

[Ike Naar]

namespace vv {
namespace std {

template <class T>
class vector
{
int a;
};

}
}

using namespace vv; // This could be in a header somewhere.

int main()
{
std::vector<int> nn;
}

With #include <vector>, the code above won't compile
(ambiguous reference to namespace std).
Lacking #include <vector>, replacing std with ::std would not compile.

 

[Öö Tiib]

I don't remember for sure, but I think that the namespace name "std"
is likewise reserved for the standard library and shouldn't be used
for a user-defined namespace anywhere.

It says that adding declarations or definitions to namespace std is UB.

 

[woodbrian77]

I think what he and Ike Naar are getting at is that the only possible
reason for such a pair of constructs (a subnamespace named "std" and a
using) is a deliberate attempt, from the library writer, to mess with
you.

I can imagine someone who doesn't know what they
are doing writing some code like that. Or how about
someone who was experimenting with it and forgot to
remove it. I just know that over time without the
scope someone will get confused needlessly. I can
take steps to prevent that so I do.

 

[woodbrian77]

With #include <vector>, the code above won't compile
(ambiguous reference to namespace std).

G++ says it is ambiguous with or without the include.

Lacking #include <vector>, replacing std with ::std would not compile.

Clang compiles it with or without the :: prefix.

 

[woodbrian77]

The C++ standard uses a few "soft rules" so to speak (iow. rules that
it doesn't want to make compilers to enforce, but are more like
conventions that programmers should follow to avoid problems.)
One example of such a rule is that names starting with an underscore
are reserved for the compiler and shouldn't be used in user code. The
compiler won't enforce that rule (mostly for practical reasons), but
it's still something that's a good idea to follow.

I don't remember for sure, but I think that the namespace name "std"
is likewise reserved for the standard library and shouldn't be used
for a user-defined namespace anywhere.

We are back to shouldn't. I agree with your statement,
but it doesn't help here.

 

[Ike Naar]

G++ says it is ambiguous with or without the include.


Clang compiles it with or without the :: prefix.

Now it gets interesting: I added a statement that mentions nn.a :

/* code */
namespace vv {
namespace std {
template <class T> class vector {int a;};
}
}

using namespace vv; // This could be in a header somewhere.

int main()
{
::std::vector<int> nn;
nn.a;
}
/* end of code */

and these are the messages generated by clang (version 3.2):
app.cpp:12:6: error: 'a' is a private member of 'vv::std::vector<int>'
nn.a;
^
app.cpp:3:42: note: implicitly declared private here
template <class T> class vector {int a;};
^
app.cpp:12:6: warning: expression result unused [-Wunused-value]
nn.a;
~~ ^
1 warning and 1 error generated.

Apparently (according to the first diagnostic)
nn is not a ::std::vector<int> after all, it's a vv::std::vector<int>.
I don't know if this is a compiler bug.
But it looks like using the :: prefix does not guarantee that the
global version of std::vector is used (which was your motivation
for writing it that way).

 

[Öö Tiib]

G++ says it is ambiguous with or without the include.


Clang compiles it with or without the :: prefix.

Now it gets interesting: I added a statement that mentions nn.a :

/* code */
namespace vv {
namespace std {
template <class T> class vector {int a;};
}
}

using namespace vv; // This could be in a header somewhere.

int main()
{
::std::vector<int> nn;
nn.a;
}
/* end of code */

and these are the messages generated by clang (version 3.2):
app.cpp:12:6: error: 'a' is a private member of 'vv::std::vector<int>'
nn.a;
^
app.cpp:3:42: note: implicitly declared private here
template <class T> class vector {int a;};
^
app.cpp:12:6: warning: expression result unused [-Wunused-value]
nn.a;
~~ ^
1 warning and 1 error generated.

I trust that was what Brian meant by saying "Clang compiles it with or
without the :: prefix." above.

Apparently (according to the first diagnostic)
nn is not a ::std::vector<int> after all, it's a vv::std::vector<int>.
I don't know if this is a compiler bug.

I think that clang is wrong and gcc correct but I generally don't care since
my viewpoint is same as in FAQ:
"The using-directive exists for legacy C++ code and to ease the transition
to namespaces, but you probably shouldn't use it on a regular basis, at
least not in your new C++ code."
http://www.parashift.com/c++-faq/using-namespace-std.html

IOW, erasing the feature from C++ language would improve the quality of
the language for people who do not deal with 15+ years old C++ code.

But it looks like using the :: prefix does not guarantee that the
global version of std::vector is used (which was your motivation
for writing it that way).

I can parse from standard that unqualified lookup of 'a::x' can
be ambiguous between '::n::a::x' and '::a::x' (thanks to that dreaded
using-directive that should be dumped anyway). On such case that
:: prefix then resolves that ambiguity ('::a::x' is '::a::x' on such
case).

I fail to find clear answer (and perhaps it matters less) if '::a::x'
may still mean '::n::a::x' on cases when 'a::x' non-ambiguously means
'::n::a::x'.

 

[woodbrian77]

I think that clang is wrong and gcc correct but I generally don't care since
my viewpoint is same as in FAQ:
"The using-directive exists for legacy C++ code and to ease the transition
to namespaces, but you probably shouldn't use it on a regular basis, at
least not in your new C++ code."
http://www.parashift.com/c++-faq/using-namespace-std.html

IOW, erasing the feature from C++ language would improve the quality of
the language for people who do not deal with 15+ years old C++ code.

Maybe using directives could be banned from include files, but
still available in source files? I know some books recommend
banning using directives in headers, but it would help if the
standard banned it.


Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net

 

[Öö Tiib]

Maybe using directives could be banned from include files, but
still available in source files?

Why? We have myriad of ways to have aliases for names like namespace
alias, using declaration, type alias, typedef and so on. Using-directive
is unneeded since it is too loose.

I know some books recommend banning using directives in headers, but
it would help if the standard banned it.

I can live with such trivial-to detect bad feature in language. It takes
few minutes to make a script that warns about using-directive in code or
refuses changeset with it into repository.

However it is most often used for moving all names from huge namespaces
(like 'boost' or 'std') into global namespace. Most often used so by
people who will usually guess incorrectly if to ask if a random name that
makes sense (say 'signal') is present in 'boost' in 'std' in both or
in neither. Those people would benefit most if it was banned whatsoever
because they are later stuck most long with resulting name clashes and
funny error messages.

 

[woodbrian77]

Why? We have myriad of ways to have aliases for names like namespace
alias, using declaration, type alias, typedef and so on. Using-directive
is unneeded since it is too loose.

It would be a bigger hit to existing code that way, but it
would be OK with me.

I can live with such trivial-to detect bad feature in language. It takes
few minutes to make a script that warns about using-directive in code or
refuses changeset with it into repository.

It is difficult to get everyone to use a script like that though.
Are you backing away from getting rid of using-directives?
I hope not.

 

[Öö Tiib]

It is difficult to get everyone to use a script like that though.

Yes. Better first step is perhaps to propose a patch to the open
source C++ compilers that makes those to warn about using-directive.
The compilers are quite popular. I have noticed that tool warnings are
often enough to reduce usage of loose constructs. Usage style of C
language for example has improved a lot over years only thanks to such
warnings about technically valid code.

Are you backing away from getting rid of using-directives?
I hope not.

No, I seriously think that it is worthless feature. Another thing
that is maybe bit radical about it ... removing it would make about
95% of C++ code examples published all around to be illegal.

 

[woodbrian77]

Yes. Better first step is perhaps to propose a patch to the open
source C++ compilers that makes those to warn about using-directive.
The compilers are quite popular. I have noticed that tool warnings are
often enough to reduce usage of loose constructs. Usage style of C
language for example has improved a lot over years only thanks to such
warnings about technically valid code.

I changed the CMW to throw an exception now if it finds
a using directive in a header file. Kind of harsh, but
also noticed that John Lakos in his talk at C++ Now
agrees with us.

 

[woodbrian77]

I guess it's more like 7 seconds here.

I'm happy to report that the software builds consistently
now in under 6 seconds. This is on the same hardware and
with the same compiler as I used in July. I've made a number
of changes to the software since July that have improved the
build time.

http://webEbenezer.net/build_integration.html


I beleive the software is well written, but there is
probably room for some improvement.

 

[woodbrian77]

On Saturday, October 26, 2013 4:26:14 PM UTC-5, Leigh Johnston wrote:


Please don't swear here.

I gave this thread an update in part because there are
new people rolling through here from time to time.

If you have some technical criticism of the software I'd
be happy to hear it.

 

[woodbrian77]

Do you seriously believe that asking nicely will stop people swearing

Yes, and please don't use sexual slurs here.

But your posts about it are usually random and inane like "my
compilation time changed by a second".

The software was good in July and is better now.

Usenet is not your own personal
diary.

Remember this part of Psalm 23.

5 You prepare a table before me in the presence of my enemies;
You have anointed my head with oil;
My cup overflows.
6 Surely goodness and lovingkindness will follow me all
the days of my life,
And I will dwell in the house of the L-rd forever.


And then bring in "One man's trash is another man's treasure."
My software may be trash to you, but to poverty stricken
people from India, China, Russia, Nepal. Egypt, Greece, Spain,
Mexico etc., it's a lifesaver. Why? Because it's free and
of increasingly high quality. G-d's will is to help His people
and they are all over the globe.

 

[woodbrian77]

On Sunday, October 27, 2013 11:49:53 AM UTC-5, Leigh Johnston wrote:


Too much swearing, Leigh.

 

[Öö Tiib]

Too much swearing, Leigh.

Leigh has likely nothing to do and feels alone and so he specially
tries to insult you and to swear and get some reaction ... some
feed back ... anything. He does not believe that most things are
possible to get just by asking nicely from others.

 

[woodbrian77]

Leigh has likely nothing to do and feels alone and so he specially
tries to insult you and to swear and get some reaction ... some
feed back ... anything. He does not believe that most things are
possible to get just by asking nicely from others.

That's OK. I have only gotten one response to my posts
where the person took me up on it and downloaded and
built it. So it probably looks like it isn't very
successful. However scores of people downloaded it so
that's a little better.

The asking nicely according to a Bible story is
sometimes being persistent until someone says,
"I'm tired of them asking so will help them."

If I didn't believe I have a portability advantage
over competitors because of my approach/architecture,
I probably wouldn't be so bold. My library, front
tier, and the generated code are the parts that
have to be portable. The middle tier has to be
somewhat portable, but not as much as the front tier.
The back tier doesn't have to be very portable.
The back tier is bigger than the middle tier and the
middle tier is bigger than the front tier. The front
tier is less than 100 lines (not counting generated
code) so it's expected to be easy to port to other
platforms.

 

[Ian Collins]

The only reaction I want ....

Invest in a kill-file.