Le 25.10.2013 15:30, Joel Rees a écrit :
On Fri, Oct 25, 2013 at 7:26 PM, <berenger.mo...@neutralite.org>
wrote:
Le 23.10.2013 14:22, Joel Rees a écrit :
On Wed, Oct 23, 2013 at 9:47 AM, <berenger.mo...@neutralite.org>
wrote:
Le 22.10.2013 23:01, Jerry Stuckle a écrit :
On 10/21/2013 5:26 PM, berenger.mo...@neutralite.org wrote:
Le 18.10.2013 19:36, Jerry Stuckle a écrit :
[...]
Even inlined code requires resources to execute. It is NOT as
fast
as regular C pointers.
I did some testing, to be sure. With -O3, the code is exactly
the same.
Did not tried with -O1 and -O2. Without optimization, the 5
lines with
pointers were half sized of those using unique_ptr. But I never
ship
softwares not optimized (the level depends on my needs, and
usually I
do
not use -O3, though).
First of all, with the -O1 and -O2 optimization you got extra
code.
Did you try it? It just did, with a code doing simply a new and a
delete
with raw against unique_ptr. In short, the simplest usage
possible.
Numbers are optimization level, p means pointer and u means
unique_ptr.
It seems that it is the 2nd level of optimization which removes
the
difference.
7244 oct. 23 01:57 p0.out
6845 oct. 23 01:58 p1.out
6845 oct. 23 01:58 p2.out
6845 oct. 23 01:58 p3.out
11690 oct. 23 01:59 u0.out
10343 oct. 23 01:59 u1.out
6845 oct. 23 01:59 u2.out
6845 oct. 23 01:59 u3.out
Just out of curiosity, how does the assembler output compare?
I did some diff on same size files, there was no difference.
No, you may or may not see any difference in the file sizes, and
smaller files may not be desirable anyway. I'm not talking about the
volume of code generated, I'm talking about the quality.
What sort of assembly language output does "g++ -S" show you for the
pointer accesses, references, arithmetic? Indirecting through a bare
pointer should be basically one MOV instruction, if you aren't using
the funky segmented pointers left over from the previous versions of
x86 processors.
You are completely right.
The codes could have the same size, but could differ slightly
differently. I did not took a look at the asm codes generated, so I can
not tell.
To be honest, I could redo the code, which was 5-6 lines long, but...
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/7d08b790b9d23870de1ba661fc02e...@neutralite.org
