Sunday, April 29, 2018

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 29 06:23AM

On Sat, 2018-04-28, Jouko Koski wrote:
 
> Having to repeat the namespace name everywhere does not improve readability.
> It adds noise, induces boilerplate typing and it looks ugly, albeit it does
> make the identifiers more explicit.
 
Then I'm with Juha (I think it was): I think accepting the namespaces
is the best overall solution. So I refer to things as "std::foo" and
to "bar::foo" in my code (if that code isn't also in bar).
 
It no longer looks ugly to me, and it typically doesn't mean a lot of
repetition (especially nowadays with C++11 auto).
 
I've done some work with boost::asio, and there the long namespacing
/was/ annoying, because you had to mention it over and over again.
 
> };
 
> so that string would be std::string in this interface without leaking the
> same using or alias declaration to everywhere else, too. Any suggestions?
 
If we focus on the interface: to me, if that had appeared in a header
file, I'd worry about what 'string' meant, since it didn't say
'std::string'. It doesn't feel like an improvement to
 
struct thing {
void func(std::string s);
};
 
I can appreciate an abbreviation like this in an interface:
 
using ResolverMap = std::map<std::string, std::list<IpAddress>>;
 
but then I'm getting something more than removal of the std prefix.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: Apr 29 08:00AM -0700

On Sunday, April 29, 2018 at 1:23:46 AM UTC-5, Jorgen Grahn wrote:
> };
 
> I can appreciate an abbreviation like this in an interface:
 
> using ResolverMap = std::map<std::string, std::list<IpAddress>>;
 
I would write it like this:
 
using ResolverMap = ::std::map<::std::string,::std::list<IpAddress>>;
 
.
 
 
> but then I'm getting something more than removal of the std prefix.
 
You get both precise and flexible names this way.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 29 08:37PM +0300

"Alf P. Steinbach" wrote:
> using string = std::string;
> void func( string const& );
> };
 
Yes, and a typedef would do as well. Now, can this be scaled so that
other identifiers from or even the whole std:: would be available inside
the struct?
 
--
Jouko
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 29 08:45PM +0300

"James Kuyper" wrote:
>> same using or alias declaration to everywhere else, too. Any suggestions?
 
> Can you suggest an alternative, and define the details of how you think
> this alternative should work?
 
I thought I was asking the question. :-) Well, the ultimate goal is to
improve readability in a bit broader context than in an interface
consisting of one class with one member function. But these would be my
shots with this minimalistic example so far:
 
using namespace std; // considered bad
 
struct thing {
void func(string s);
};
 
This is the non-solution, because it leaks std to anybody using the thing.
 
struct thing {
typedef std::string string; // or using string = std::string;
void func(string s);
};
 
This is a solution. However, it does not scale, because a typedef is
necessary for each "beautified" type in the class scope. The solution
carries a lot of boilerplate: We have written "string" three times!
 
struct thing {
using namespace std; // not valid C++
void func(string s);
};
 
If this were allowed it would probably the best solution. But there
might be some implications...
 
namespace some_unique_boilerplate_namespace_name {
using namespace std;
struct thing {
void func(string s);
};
}
using some_unique_boilerplate_namespace_name::thing;
 
This is the best I have come up with. But shall we really conclude
that the general guideline is: Place all your code in a namespace
even when you are not supposed to use a namespace; and place all your
code in a nested namespace when you are using a namespace?
 
--
Jouko
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 29 09:13PM +0300

"Jorgen Grahn" wrote:
 
> Then I'm with Juha (I think it was): I think accepting the namespaces
> is the best overall solution. So I refer to things as "std::foo" and
> to "bar::foo" in my code (if that code isn't also in bar).
 
Making a virtue of necessity! Yes, it is more explicit, but it cripples
readability.
 
> It no longer looks ugly to me, and it typically doesn't mean a lot of
> repetition (especially nowadays with C++11 auto).
 
Well, it is ugly and there is still a lot of repetition.
 
 
> If we focus on the interface: to me, if that had appeared in a header
> file, I'd worry about what 'string' meant, since it didn't say
> 'std::string'.
 
I trust you not being that inept in real life! People using some other
languages that have packages or modules mechanism seem to do quite ok
with this issue.
 
If there were "string", "buffer" or "socket" in some declaration and
there is "std" or "boost::asio" in the same cognitive scope, one should
be able to assume that string, buffer or socket cannot be just anything.
They are supposed to be coming from std or boost::asio without the need
of repeating the full namespace path on every single occurrence.
 
When it comes to this particular toy example, string is probably the
most used type in the standard library. I would expect that if there
were any other kind of string in the same context simultaneously, it
is that string that should be addressed as the other::string without
having to drag the std:: prefix to everywhere else. Having "using
namespace std;" in the global scope might not be that bad idea after
all but that is another story.
 
> I can appreciate an abbreviation like this in an interface:
 
> using ResolverMap = std::map<std::string, std::list<IpAddress>>;
 
> but then I'm getting something more than removal of the std prefix.
 
Yes. When it comes to code readability, this declaration is over 60
characters long. It is a bit challenging to try to limit the max line
length to 80 when this kind of stuff tends to be the norm. About 10 %
of it is colons and the "std::" is repeated three times. That resembles
noise.
 
--
Jouko
"Jouko Koski" <joukokoskispam101@netti.fi>: Apr 29 09:23PM +0300

wrote:
 
> I would write it like this:
 
> using ResolverMap = ::std::map<::std::string,::std::list<IpAddress>>;
 
Now, this is plain unbeliavable madness! This may solve some problem,
but that problem has very little to do with programming. A code review
with professional programmers or other professional help might give
guidance realizing that this kind of a convention results in just a
pile of personal read-only code.
 
--
Jouko
Ian Collins <ian-news@hotmail.com>: Apr 30 07:17AM +1200

On 04/30/2018 06:23 AM, Jouko Koski wrote:
> with professional programmers or other professional help might give
> guidance realizing that this kind of a convention results in just a
> pile of personal read-only code.
 
All of the superfluous colons do make it had to read, take them away and
it isn't as bad....
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 29 07:58PM

On Sun, 2018-04-29, Jouko Koski wrote:
 
>> It no longer looks ugly to me, and it typically doesn't mean a lot of
>> repetition (especially nowadays with C++11 auto).
 
> Well, it is ugly and there is still a lot of repetition.
 
I note that I wrote "looks ugly to me", and that you still pretend
your preferences are universal.
 
>> file, I'd worry about what 'string' meant, since it didn't say
>> 'std::string'.
 
> I trust you not being that inept in real life!
 
Ad hominem this soon? I have better things to do.
 
*plonk*
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Vir Campestris <vir.campestris@invalid.invalid>: Apr 29 09:53PM +0100

On 29/04/2018 19:13, Jouko Koski wrote:
> length to 80 when this kind of stuff tends to be the norm. About 10 %
> of it is colons and the "std::" is repeated three times. That resembles
> noise.
 
Two things:
 
Why would I want to limit the line to 80 chars? My screen is bigger than
that, and has been for 20 years at least.
 
And
 
using ResolverMap
= std::map<
std::string,
std::list<
IpAddress
 
>;
 
Andy.
--
Apparently the Linux kernel standard is to stop excessive nesting. so
why doesn't it limit nesting instead?
Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 11:12PM +0300

On 27.04.2018 13:22, Andrea Venturoli wrote:
 
>> Nevertheless, comparing with std::numeric_limits<double>::max() seems
>> pretty fragile
 
> Why then?
 
Comparing floating-point numbers for exact equality is always fragile,
there is always a chance that somebody adds some computation like divide
by 10, multiply by 10, ruining the results. A deeply "floating-point"
value like std::numeric_limits<double>::max() is doubly suspect just
because it is far away from normal and well-tested range of values.
 
I just checked how it is defined in MSVC. It appears the value is
defined by the macro
 
#define DBL_MAX 1.7976931348623158e+308
 
From here you can clearly see there might be problems. This constant is
specified in decimal and I believe there is a fair chance this number
does not have an exact representation in binary. It will probably yield
different results when loaded into either a 64-bit or a 80-bit register.
Add some minor optimizer bugs and one can easily imagine that there
might be problems when comparing this number with itself, even if it
should work by the letter of the standard.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)