Monday, January 5, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

scott@slp53.sl.home (Scott Lurndal): Jan 05 03:17PM


>If you are still using a C++98 compiler at this point, you have noone
>to blame but yourself. C++11 compilers are widely and easily available
>and C++14 is mostly implemented by the major tool chains.
 
One doesn't always have the choice. Just because a compiler is available
doesn't mean that it has been qualified for use in a particular project.
legalize+jeeves@mail.xmission.com (Richard): Jan 05 04:54PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
>>and C++14 is mostly implemented by the major tool chains.
 
>One doesn't always have the choice. Just because a compiler is available
>doesn't mean that it has been qualified for use in a particular project.
 
I'm going to disagree and say that you always have a choice, but that
you have chosen to stick with a C++98 compiler. I know people who
have chosen to stick with VC6, for instance. For whatever reason they
hated the new IDE, but the consequence of that choice is being stuck
with a really ancient version of Microsoft's compiler at this point.
 
If you target enterprise linux, then the default compiler is an
ancient version of gcc. That doesn't mean you're stuck with that.
There are many ways to get around that problem. If quality of
implementation is the issue, then you're almost certainly going to get
a better implementation with a newer compiler than sticking with a
really ancient one.
--
"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>
scott@slp53.sl.home (Scott Lurndal): Jan 05 05:15PM

>>doesn't mean that it has been qualified for use in a particular project.
 
>I'm going to disagree and say that you always have a choice, but that
>you have chosen to stick with a C++98 compiler. I know people who
 
No, my "boss" requires that I stick with a C++98 compiler. Qualification
of a new compiler is expensive, in terms of man-hours for both testing
and updating the sources to compile correctly with the new compiler
(often because GCC changes the set of fatal warnings from one
release to the next and we compile with -Wall -Werror).
 
The third party libraries we link with aren't qualified by their
vendor for anything other than certain versions of GCC that don't
include any with full C++11 support, much less C++14.
 
The code works. The compilers compile. The programmers get paid.
Everyone is happy except for those who think C++14 is better than
sliced bread. pthreads work with any C++ compiler.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 05:35PM

On Mon, 2015-01-05, Richard wrote:
...
> If you target enterprise linux, then the default compiler is an
> ancient version of gcc. That doesn't mean you're stuck with that.
 
It's note even that bad. The stable distribution of Debian is
infamous for containing old software, but its gcc is 4.7 -- not the
best C++11 coverage you can get, but very decent subset.
 
> implementation is the issue, then you're almost certainly going to get
> a better implementation with a newer compiler than sticking with a
> really ancient one.
 
Yes, unless you're trying the very latest snapshot from the gcc people
or something.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Jan 05 05:51PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>No, my "boss" requires that I stick with a C++98 compiler. [...]
 
Again, choices that you (or your organization) have made. This is a
problem of your own making.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Jan 05 05:52PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
>> really ancient one.
 
>Yes, unless you're trying the very latest snapshot from the gcc people
>or something.
 
Yeah, snapshots are outside the scope of what I'm talking about here
-- I'm referring to released, stable, versions of tools, not nightly
builds from a development branch.
 
I find it ironic that although I work (at least until the end of
today) at a mostly linux shop that it's Visual Studio that has the
best C++ compiler between the different operating system. (Xcode's
clang might edge out VS, depending on the version we're using, I'm not
sure.)
--
"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>
scott@slp53.sl.home (Scott Lurndal): Jan 05 03:11PM

>spawn multiple processes. Most servers that use multiple processes
>simply clone an instance of themselves to do work. The parent handles
>incoming requests and manages its children.
 
With multiple processes, one has an address space per process
(that means page tables, folks). Whereas multiple threads
share a single address space (a single page table).
 
A page table can be quite large (for a 1TB virtual address space
using 4k pages, about 2GB). That's a fair amount of overhead
on a per-process basis. This can be reduced somewhat by using
larger pages (not particularly straightforward, unfortunately,
whether using transparent large pages or hugetlbfs).
 
There are use cases where multiple processes are better (no
shared data, pipelines, programmers who don't understand
concurrency) and cases where multiple threads
are better (shared data, large address spaces, skilled programmers).
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 05:22PM

On Mon, 2015-01-05, Scott Lurndal wrote:
...
> There are use cases where multiple processes are better (no
> shared data, pipelines, programmers who don't understand
> concurrency)
 
I.e. almost everyone of us ...
 
> and cases where multiple threads
> are better (shared data, large address spaces, skilled programmers).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Joseph Hesse <joeh@gmail.com>: Jan 05 09:57AM -0600

Hi,
 
Can someone provide me with an example of a function returning an &&.
Preferably something simple such as:
int && f(int);
 
I tried
int && f(int x) {
return x;
}
but it didn't work.
 
Thank you,
Joe
Luca Risolia <luca.risolia@linux-projects.org>: Jan 05 05:11PM +0100

On 05/01/2015 16:57, Joseph Hesse wrote:
> return x;
> }
> but it didn't work.
 
#include <utility>
 
int && f(int x) {
return std::move(x);
}
Bo Persson <bop@gmb.dk>: Jan 05 05:21PM +0100

On 2015-01-05 17:11, Luca Risolia wrote:
 
> int && f(int x) {
> return std::move(x);
> }
 
This seems to work, but returns a dangling reference to the parameter.
 
About the only use case I have seen is the std::move function itself
(which takes its parameter by reference, and not by value).
 
 
Bo Persson
Joseph Hesse <joeh@gmail.com>: Jan 05 10:22AM -0600

On 01/05/2015 10:11 AM, Luca Risolia wrote:
 
> int && f(int x) {
> return std::move(x);
> }
 
Why doesn't this work:
 
int && f()
{
int && x = 10;
return x;
}
 
In the above, x is clearly an int && and that is what the function
promises to return.
"Öö Tiib" <ootiib@hot.ee>: Jan 05 08:27AM -0800

On Monday, 5 January 2015 17:57:16 UTC+2, Joseph Hesse wrote:
> Hi,
 
> Can someone provide me with an example of a function returning an &&.
 
Who returns it must be make sure that the object does not go out of scope
before it is used by caller.
 
struct Thing
{
Resource r;
 
// return reference to member; caller can use it for copying
Resource const& resource() const
{
return r;
}
 
// return rvalue reference to caller; caller can use it for moving
Resource&& stealResource() &&
{
return std::move(r);
}
};
 
> return x;
> }
> but it didn't work.
 
This is trying to return dangling reference to function's by-value parameter.
Changing to 'return std::move(x);' will succeed in returning that dangling
reference. You don't want to return dangling references because it is undefined
behaviour.
Victor Bazarov <v.bazarov@comcast.invalid>: Jan 05 11:27AM -0500

On 1/5/2015 11:22 AM, Joseph Hesse wrote:
> }
 
> In the above, x is clearly an int && and that is what the function
> promises to return.
 
"Doesn't work" likely because you're returning a reference to a
non-existent object (a temporary whose lifetime ends when the function
body is exited).
 
V
--
I do not respond to top-posted replies, please don't ask
ram@zedat.fu-berlin.de (Stefan Ram): Jan 05 04:20PM

>Can someone provide me with an example of a function returning an &&.
 
»&&« is a token in C++. A function cannot return C++ tokens.
A function could return the string »"&&"«.
 
> return x;
>}
>but it didn't work.
 
I think functions already provide that without the »&&«
notation, because of RVO. A local variable or temporary
after »return« is at the end of its lifetime, so it always
can be moved from.
 
However, there seems to be an array helper function »get«
in C++ with the signature:
 
template<size_t index, typename T, siz e_t N>
T&& get(array<T,N>&& a) noexcept;
 
Another example from the literature:
 
template<typename T>
T&& forward(Remove_reference<T>& t) noexcept
{ return static_cast<T&&>(t); }
Geoff <geoff@invalid.invalid>: Jan 04 04:51PM -0800

>into your program.
 
>He created C++, so whom should I give more preference, Tour of C++ of the
>FAQs ? or I did not understand what he is trying to say ?
 
It's a crutch.
 
It's a habit acquired from reading or writing examples of code as a
teaching tool. In those contexts it's meant to help clarify the points
being taught in the example code but it's not meant to be used
routinely in "production code" unless you never bring in another
namespace. Small, trivial example programs or single-unit programs are
such cases.
 
Expect to be criticized for using it if you post a code example with a
question in the news groups as someone will always point out that you
should not use it. They can't refrain from doing so. But their intent
is to break the student of the habit of using the crutch as soon as
possible in their career and to acclimate that student to the proper
use of namespaces.
woodbrian77@gmail.com: Jan 04 09:45PM -0800

On Sunday, January 4, 2015 3:55:34 PM UTC-6, Mike Austin wrote:
> using std::endl;
> }
 
> using iostream;
 
I think you forgot the namespace keyword there.
And that looks like an interesting idea.
 
 
Brian
Ebenezer Enterprises - "Yeshua (aka Jesus) said to
him, "I am the way, and the truth, and the life;
no one comes to the Father but through Me." John 14:6
 
http://webEbenezer.net
woodbrian77@gmail.com: Jan 04 10:08PM -0800

On Sunday, January 4, 2015 3:21:04 PM UTC-6, Stefan Ram wrote:
> maintainability is not important, one can use it.
 
> For code that has a large expected lifetime and needs to be
> robust, one should not use it. I call that »library-grade code«.
 
That doesn't seem like a good name to me because there
are executables that are hoped to be enduring. I don't
have another suggestion, but think it would be confusing
to use that term with regard to executables.

 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
Paavo Helde <myfirstname@osa.pri.ee>: Jan 05 12:15AM -0600

Mike Austin <spam@null.net> wrote in
 
> Using boost more lately, I agree that importing whole namespaces is
> not a good idea.
 
With boost, the namespace names are really too long. Fortunately these can
be shortened:
 
namespace bnu = boost::numeric::ublas;
namespace bfs = boost::filesystem;
 
bfs::path x;
bnu::matrix<double> y;
JiiPee <no@notvalid.com>: Jan 05 07:25AM

On 04/01/2015 21:55, Mike Austin wrote:
> such as:
 
> using std { cout, endl };
> using boost { tuple, variant };
 
you should suggest this to the commitea !
 
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 08:05AM

On Mon, 2015-01-05, Paavo Helde wrote:
> namespace bfs = boost::filesystem;
 
> bfs::path x;
> bnu::matrix<double> y;
 
I think I would have preferred to shorten them to "ublas" and
"filesystem" (or "fs"). For someone studying your program, it's soon
obvious that you're using Boost, and then the boost prefix becomes
redundant. And even I know "ublas" deals with linear algebra, so
"numeric" becomes redundant too.
 
But yeah, this is one of those areas where people have different
preferences.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Jan 05 01:29AM -0800

On Sunday, January 4, 2015 11:55:34 PM UTC+2, Mike Austin wrote:
> }
 
> using iostream;
 
> Actually, I might just start using that :)
 
When I use some particular library name so lot that code feels too full
of 'std::' (or 'boost::') then I find myself more often replacing names
with more fitting to context (and style) alias or thin wrapper instead
of importing the names exactly. It seems to be bit more maintainable,
extendable, portable, unit-testable and easier to debug that way.
Compilers tend to optimize aliasing and thin wrappers out so no hit to performance.
 
Maintainability/extendability: What if I want to replace that
'std::vector<std::string>' with 'std::deque<std::string>' or class 'Names'
later? Lot of things to search and to change later if it was used like
that explicitly. 'vector<string>' is only half way. typedef it as 'Names'
right away. Lot less to type also more readable (than 'auto') immediately
but YMMV.
 
Portability: There are always little differences between most mundane
things per platform. Be it 'snprintf' or 'isnan' ... not exactly same
everywhere.
 
unit-testability: It is usually easier to inject special mocks if there
are mine own names.
 
easier to debug: It is easier to insert break-points or debug-time
checks to thin wrappers.
Vincenzo Mercuri <nomail@yahoo.it>: Jan 05 03:09PM +0100

Il 04/01/2015 06:29, arnuld ha scritto:
> into your program.
 
> He created C++, so whom should I give more preference, Tour of C++ of the
> FAQs ? or I did not understand what he is trying to say ?
..
 
He doesn't really encourage using "using namespace std;".
 
First, in the section you are referring to he illustrates the
advantage of declaring the "My_code" namespace to "make sure
that my names do not conflict with the standard-library names
in namespace std" and then he says: "we can use a using-directive".
 
That sounds like an option, not a suggestion.
 
Second, in section 6.3, page 73, he says: "It is generally in
poor taste to dump every name from a namespace into the global
namespace. However, in this book, I use the standard library
exclusively and it is good to know what it offers."
 
Sorry for quoting directly from the book, but I find these
parts relevant to answer to the OP.
 
--
Vincenzo Mercuri
Vincenzo Mercuri <nomail@yahoo.it>: Jan 05 03:16PM +0100

Il 04/01/2015 22:49, Jorgen Grahn ha scritto:
..
> It's just a tour of the language: I think you're just supposed to
> learn there is something called namespaces, so you know there's such a
> tool in the language.
 
Oops, I quoted that part from the book as well,
I didn't notice you already did :) Pardon.
 
--
Vincenzo Mercuri
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 02:35PM

On Mon, 2015-01-05, Vincenzo Mercuri wrote:
>> tool in the language.
 
> Oops, I quoted that part from the book as well,
> I didn't notice you already did :) Pardon.
 
No problem: you did it better. And after all this "OMG Stroustrup
says we should all be 'using namespace std'!" it doesn't hurt to
explain twice that he doesn't, really.
 
BTW, I don't think anyone minds us quoting the book from a copyright
perspective. "Fair use" was invented for exactly this scenario.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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)