Sunday, November 26, 2017

Digest for comp.lang.c++@googlegroups.com - 21 updates in 14 topics

Gareth Owen <gwowen@gmail.com>: Nov 26 06:50AM

>> If you are passing pointers around, in my view it is
>> better explicitly to declare its type.
 
> My view too. Use auto only when you must (eg lambdas).
 
How do you feel about using it for loop variables:
 
for(auto it = foo.begin(); it foo.end(); ++i) {}
 
or
 
for(const auto& x : xvec) {}
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 26 08:26AM

On Sat, 2017-11-25, Vir Campestris wrote:
>> If you are passing pointers around, in my view it is
>> better explicitly to declare its type.
 
> My view too.
 
Note that your view is more radical, since you then add:
 
> Use auto only when you must (eg lambdas).
 
> In my old company that was a coding standard.
 
At the other extreme, I think it was Herb Sutter who claimed we should
use auto as much as possible -- and get special tools which can tell
us what types our variables /really/ have.
 
Personally, I use auto, but only where I think it makes the code
clearer. That ends up as maybe 20--50% of the places where I /could/
have squeezed in an auto.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Nov 26 03:10PM

On 26 Nov 2017 08:26:13 GMT
 
> At the other extreme, I think it was Herb Sutter who claimed we should
> use auto as much as possible -- and get special tools which can
> tell us what types our variables /really/ have.
 
New features seem to get overhyped like this. While type inference
with the auto keyword is nifty in shortening code, its downside (apart
from making things less obvious for the reader) is that it can separate
the location of a type error from the place in the code where the error
is likely to be first detected. Extending the circumstances in which
you get incomprehensible template-like error messages is not an
advantage in my view. The auto keyword is I think best used in small
local block scopes where the possibility for error reporting
displacement of this kind doesn't really arise.
 
For that reason, even languages that use, say, the more complete
Hindley-Milner type inference system tend to recommend that, where a
function does not employ parametric polymorphism (aka templates in C++)
then its arguments should be explicitly typed except where the function
is a very simple one. That makes type errors much easier to deal with.
 
> Personally, I use auto, but only where I think it makes the code
> clearer. That ends up as maybe 20--50% of the places where I /could/
> have squeezed in an auto.
 
Ditto.
Vir Campestris <vir.campestris@invalid.invalid>: Nov 26 09:28PM

On 26/11/2017 06:50, Gareth Owen wrote:
> How do you feel about using it for loop variables:
 
> for(auto it = foo.begin(); it foo.end(); ++i) {}
 
Is that an iterator or a const_iterator?
 
> or
 
> for(const auto& x : xvec) {}
 
There's no need to do it here either.
 
The problem in the absence of really clever tools (1)(2) is that the
casual reader can't tell at a glance what x really is. And even when the
tools are working you usually have to "hover" on the variable, then
wait, to see. Which is slower.
 
Andy
 
1)I used to use MSVC, and that was clever enough; I haven't found one
for Linux
2) I don't always agree with Herb. Nearly always, but not every time!
Gareth Owen <gwowen@gmail.com>: Nov 26 10:32PM

>> How do you feel about using it for loop variables:
 
>> for(auto it = foo.begin(); it foo.end(); ++i) {}
 
> Is that an iterator or a const_iterator?
 
If you know what the type of foo, that will tell you that whether you
can mutate its elements. If know the const-ness of the container,
there's no benefit to knowing the (name of the) type of the iterator,
 
And if you don't know the constness of the container, you can't even
write the non-auto version.
 
 
>> or
 
>> for(const auto& x : xvec) {}
 
> There's no need to do it here either.
 
There's almost never a need to do it at all. As proven by every C++
prior to C++11
 
> The problem in the absence of really clever tools (1)(2) is that the
> casual reader can't tell at a glance what x really is.
 
It's "an iterator to the type of the container" or "a reference to an
item in the container."
 
> And even when the tools are working you usually have to "hover" on the
> variable, then wait, to see. Which is slower.
 
Mostly, though, you simply never need to know the exact type of an
iterator - just that you can iterate with it. That's why they're a good
abstraction[0].
 
"Something I can use to iterate" is all the programmer needs to know.
 
[0] And any way, mostly they're opaque anyway. We know
std::vector<T>::iterator is probably a T*, but everything else is
implementation defined.
Vir Campestris <vir.campestris@invalid.invalid>: Nov 26 10:43PM

On 26/11/2017 22:32, Gareth Owen wrote:
> Mostly, though, you simply never need to know the exact type of an
> iterator - just that you can iterate with it. That's why they're a good
> abstraction[0].
 
I bet you put your curly brackets in the wrong place too... :)
 
Andy
mcheung63@gmail.com: Nov 25 10:23PM -0800

read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
Vir Campestris <vir.campestris@invalid.invalid>: Nov 26 09:28PM

Just ignore him. He only wants attention.
"Öö Tiib" <ootiib@hot.ee>: Nov 26 11:15AM -0800

On Sunday, 26 November 2017 01:09:40 UTC+2, Ian Collins wrote:
 
> Just ask yourself whether it makes sense for a to know how to clone its
> self or represent its self as a string. For external entity to clone an
> object, the object would have to expose too many of its private parts...
 
The interface design decisions are usually made long ago by authors
of classes and such decisions seemingly don't depend on answers to the
questions but only on how the authors did perceive what is better
for them to read. That is somewhat understandable. Consider for example
those:
 
std::ostream& operator<<(std::ostream&, OurType const& val);
std::istream& operator>>(std::istream&, OurType& val);
 
Now lets ask from ourselves does it make sense for OurType to know how
to stream itself and would not those operators need access to too many
of OurType's private parts? Answers to those questions just can not
matter at all.
ram@zedat.fu-berlin.de (Stefan Ram): Nov 26 05:35AM

I compile with gcc, but then also ask clang to have a look
at my source code. Today, I saw this:
 
main.cpp
 
#include <iostream>
#include <ostream>
#include <string>
 
using namespace ::std::literals;
 
int main()
{ ::std::string const b[ 3 ]{ "a"s, "b"s, "c"s };
::std::string const a[ 3 ]= b;
 
::std::cout << R"(")" <<
a[ 0 ]<< R"(", ")" <<
a[ 1 ]<< R"(", ")" <<
a[ 2 ]<< "\".\n"s; }
 
transcript
 
"a", "b", "c".
main.cpp:9:23: error: array initializer must be an initializer list [clang-diagnostic-error]
::std::string const a[ 3 ]= b;
^
 
What is this? gcc compiled and executed the program without
a diagnostic message, and then clang says there is an error?
ram@zedat.fu-berlin.de (Stefan Ram): Nov 26 12:32PM

>It you had run gcc with the appropriate options, it would have warned
>you that you were using an extension (gcc does not default to being a
>conforming compiler).
 
I thought that the options »-std=c++17« and »pedantic« used
by me already made gcc become conforming. What do I have to
change to make gcc conforming? I used:
 
c++ -std=c++17 -msse2 -march=native -Ofast -O3 -fgcse
-fgcse-las -pedantic -pedantic-errors -Werror=narrowing -Wall
-W -Wconversion -Wextra -Weffc++ -Wno-parentheses
-D__USE_MINGW_ANSI_STDIO -Wno-unused-parameter
-Wno-unused-variable -Wno-empty-body
-Wno-unused-but-set-variable -Wstrict-overflow=5
-Wsuggest-attribute=pure -Wsuggest-attribute=const
-Wsuggest-attribute=noreturn -Wsuggest-attribute=format
-Wmissing-format-attribute -Wsuggest-final-types
-Wsuggest-final-methods -Wsuggest-override -Warray-bounds=2
-Wwrite-strings
Richard Damon <Richard@Damon-Family.org>: Nov 26 07:21AM -0500

On 11/26/17 12:35 AM, Stefan Ram wrote:
> ^
 
> What is this? gcc compiled and executed the program without
> a diagnostic message, and then clang says there is an error?
 
a is a raw array of string.
 
By the standard, you can initialize an array, but not with another array
value, only with a list of values (like you did with b);
 
gcc has an extension that allows array assignment, which also covers
this case.
 
It you had run gcc with the appropriate options, it would have warned
you that you were using an extension (gcc does not default to being a
conforming compiler).
mcheung63@gmail.com: Nov 26 01:44AM -0800

We should sue Rick C Hodgin, lets discuss it here
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:28PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:27PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:27PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:26PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:26PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:26PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:25PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
mcheung63@gmail.com: Nov 25 10:25PM -0800

We should sue Rick C Hodgin
 
read this post https://groups.google.com/forum/m/?fromgroups#!topic/alt.os.development/ReiCmUesObU
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)