T *foo = new T;

Pages: 12
Basically, I can agree up to the point that new is mostly useful for dynamic array sizes.
Or when creating shared object. Or if there is valid possibility to have no object here. Or some other case.
Either way stuff from <memory> is your best bet if you not have to deal with some speed-critical parts.
^ Sometimes I think the opposite.
Using more memory in the right way can allow for speed-critical parts, as long as you allocate enough memory first.
Using less memory will require you to compress the data, or slow down the code in general because you needed more memory and didn't allocate enough, requiring re-allocation and speed loss.
Err... I was talking about speed of managed unique_ptr/shared_ptr vs raw pointers in last part. Not about moment or size of memory allocation or packed data vs unpacked.
But you do agree that true C++ code should (at least as a general rule) never use a naked new?

- that you should always use std::vector<> for dynamic arrays?

- that a shared pointer -- std::shared_ptr<>, unique_ptr<> -- should be used for objects created on the heap? (in pre-C++11 days, boost::shared_ptr, ...)

Edit: or possibly an equivalent class, in particular circumstances (thinking about CAtlArray, etc.)

Andy
Last edited on
andywestken wrote:
But you do agree that true C++ code should (at least as a general rule) never use a naked new?
That was a whole point of
Either way stuff from <memory> is your best bet if you not have to deal with some speed-critical parts.
Also you will still use new when creating unique_ptr (At least until C++14 with make_unique())
andywestken wrote:
But you do agree that true C++ code should (at least as a general rule) never use a naked new?

So... what's the purpose of adding the 'new' keyword to C++?
Do you support its usage when creating a container class, like a custom std::vector?

MiiNiPaa wrote:
Err... I was talking about speed of managed unique_ptr/shared_ptr vs raw pointers in last part. Not about moment or size of memory allocation or packed data vs unpacked.

Ah, misinterpreted.
> what's the purpose of adding the 'new' keyword to C++?
> Do you support its usage when creating a container class, like a custom std::vector?

"except rarely when implementing low-level data structures".

In C++11 we already could teach to never use owning raw pointers and explicit delete again, except in rare cases that are hidden inside a class in order to do something like implement a low-level data structure. However, we could not teach to never write new because although make_shared was provided to create a shared_ptr, new was still needed to create a unique_ptr. Now, instead of “new”, write make_unique or make_shared.

With draft C++14, we can say simply: Don't use owning raw pointers, new, and delete, except rarely when implementing low-level data structures. Allocate with make_unique or make_shared, use weak_ptr where appropriate to break cycles, and don't worry about dangling pointers in C++ again.
- Sutter http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting


> Either way stuff from <memory> is your best bet if you not have to deal with some speed-critical parts.

The performance of raw pointers are not comparable with that of std::shared_ptr<>; the functionality is different.

The difference in performance between raw pointers and std::unique_ptr<> is close to zero; typically one extra pointer dereference at the beginning. It is hard to justify the use of raw pointers over std::unique_ptr<> even in performance-critical code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#include <memory>

// compiled with -fomit-frame-pointer -O2

struct A { int a = 8 ; int b = 2 ; int c = 8 ; } ;

int foo( A* pa )
{
    return ++pa->a + --pa->b + pa->c ;
    /*
        movl	4(%esp), %edx

        movl	(%edx), %eax
        leal	1(%eax), %ecx
        movl	%ecx, (%edx)
        movl	4(%edx), %eax
        subl	$1, %eax
        movl	%eax, 4(%edx)
        addl	%ecx, %eax
        addl	8(%edx), %eax
        ret
    */
}

int bar( const std::unique_ptr<A>& pa )
{
    return ++pa->a + --pa->b + pa->c ;
    /*
        movl	4(%esp), %eax // extra pointer dereference
        movl	(%eax), %edx

        movl	(%edx), %eax
        leal	1(%eax), %ecx
        movl	%ecx, (%edx)
        movl	4(%edx), %eax
        subl	$1, %eax
        movl	%eax, 4(%edx)
        addl	%ecx, %eax
        addl	8(%edx), %eax
        ret
    */
}

int foobar( std::unique_ptr<A> pa )
{
    return ++pa->a + --pa->b + pa->c ;
    /*
        movl	4(%esp), %eax // extra pointer dereference
        movl	(%eax), %edx

        movl	(%edx), %eax
        leal	1(%eax), %ecx
        movl	%ecx, (%edx)
        movl	4(%edx), %eax
        subl	$1, %eax
        movl	%eax, 4(%edx)
        addl	%ecx, %eax
        addl	8(%edx), %eax
        ret
    */
}
Ikaron wrote:
@ne555 I believe Duoas is referencing the 2010 A-Team film (There is no Plan B) in which Baracus (one of the characters) isn't played by Mr.T (as he originally was in the tv show).

Wow, I'm smarter than I thought.

At least, I wish I could claim I meant all that cool stuff when I wrote it...
Topic archived. No new replies allowed.
Pages: 12