Wednesday, June 28, 2017

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

woodbrian77@gmail.com: Jun 27 08:06PM -0700

On Tuesday, June 27, 2017 at 5:12:01 PM UTC-5, Öö Tiib wrote:
 
> When you are not sure what is better then it can be that neither is
> better. For example it can be different per project what is better.
> On such cases it may make sense to add optional choice.
 
 
If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
and clang 4.0.0, that would be encouraging.
 
If someone who has clang 5 installed would try to build the example
programs :
 
git clone https://github.com/Ebenezer-group/onwards.git
cd onwards
make example
 
That will build two executables and it runs the size command on
them. Take note of the size of the text segment of the executable
called :send_example."
 
Now do the same thing for the variadic version:
 
git clone https://bitbucket.org/woodbrian/onwards.git
cd onwards
make example
 
Then post here what the two sizes are. Thanks.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Jun 27 11:10PM -0700


> If I could find a compiler that does better than g++ 7.1.1, g++ 8.0.0
> and clang 4.0.0, that would be encouraging.
 
You measure "better" with size of executable generated by compiler?
But that is not so important about software. Most important is that
it is doing correct things. Then it is important that it is easy to
use. Then it is important that it performs well. Size of executable
is later in list typically.
woodbrian77@gmail.com: Jun 28 08:17AM -0700

On Wednesday, June 28, 2017 at 1:10:35 AM UTC-5, Öö Tiib wrote:
> it is doing correct things. Then it is important that it is easy to
> use. Then it is important that it performs well. Size of executable
> is later in list typically.
 
C++ is known for its zero-overhead abstraction. I'm trying to figure
out if there's something I'm doing wrong or if the compilers I've tried
are not able to provide abstraction for free in this area.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Daniel <danielaparker@gmail.com>: Jun 28 09:14AM -0700


> C++ is known for its zero-overhead abstraction.
 
Hardly. Except in trivial cases, copying a value or a ref count is generally more expensive than copying a reference in a language with gc. Move isn't zero overhead either. The complexity of C++ presents a challenge to optimizers, in some cases the possibility of aliasing gives the edge to FORTRAN. And then there's streams ...
 
Daniel
David Brown <david.brown@hesbynett.no>: Jun 28 06:42PM +0200


> C++ is known for its zero-overhead abstraction. I'm trying to figure
> out if there's something I'm doing wrong or if the compilers I've tried
> are not able to provide abstraction for free in this area.
 
C++ is known for getting close to zero overhead from features you don't
use - but that is /speed/ overhead. There is plenty of overhead in code
size. For example, implementations strive to make exceptions free in
terms of speed when they are not thrown - but doing so means adding
quite a bit to the code size.
 
For most uses, code size is not a serious issue. Speed /might/ be an
issue, depending on the usage.
woodbrian77@gmail.com: Jun 28 09:47AM -0700

On Wednesday, June 28, 2017 at 11:14:39 AM UTC-5, Daniel wrote:
> On Wednesday, June 28, 2017 at 11:18:21 AM UTC-4, woodb...@gmail.com wrote:
 
> > C++ is known for its zero-overhead abstraction.
 
> Hardly. Except in trivial cases, copying a value or a ref count is generally more expensive than copying a reference in a language with gc. Move isn't zero overhead either. The complexity of C++ presents a challenge to optimizers, in some cases the possibility of aliasing gives the edge to FORTRAN. And then there's streams ...
 
The following quote is from this page:
http://blog.felipe.rs/2014/09/23/c-plus-plus-variadic-templates/
 
"C++'s strength mostly comes from the zero-cost abstractions it provides.
Stroustrup explains what it means in the C++ papers:
 
In general, C++ implementations obey the zero-overhead principle: What you
don't use, you don't pay for [Stroustrup, 1994]. And further: What you do use,
you couldn't hand code any better."
 
I'm having a problem with the last part of that statement.
 
I don't think anyone claims moving can/should be free.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 28 02:32PM

On Sun, 2017-06-11, Adam Badura wrote:
...
>> > PS 2 Why are you using "const" for non-reference function arguments?
 
[Alf]
> disadvantages objectively". So I would be grateful if you could
> direct me to some sources or explain them yourself (although maybe a
> separate thread would be better for this?).
 
He explained it briefly above: "constrains what can change ...".
 
One example:
 
void foo(const int n)
{
assert(n != 0);
... long and complicated logic
}
 
You can read the rest of foo() knowing that n!=0. That becomes an
invariant. And if you accidentally try to change it, you get a
compilation error.
 
And if you use that idiom consistently, it means when you see
 
void foo(int n) { ... }
 
you can conclude that you probably modify n somewhere in the function,
or it would have been const.
 
/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)