468,512 Members | 1,448 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

new vs new[1]

Hello,

Why do i can't write "new [1]" instead of "new" everywhere in
applications? So, i will not need to track where i must call delete and
where delete[]. Therefore, it will simplify coding.

Or application performance will be significantly reduced?

Thanks,
Denis.

Jul 26 '06 #1
10 3204
"Denis Petronenko" <pe********@gmail.comschrieb im Newsbeitrag
news:11**********************@75g2000cwc.googlegro ups.com...
Hello,

Why do i can't write "new [1]" instead of "new" everywhere in
applications? So, i will not need to track where i must call delete and
where delete[]. Therefore, it will simplify coding.

Or application performance will be significantly reduced?
You can, but then you could also use the default constructor of such
objects. You'd have to replace simple code like

std::string* pstr = new std::string("Some string");

by something like

std::string* pstr = new std::string;
*pstr = "Some string";

and that might indeed reduce performance. Also, if you kow what you are
doing and the names of your variables are well chosen, you should easily
know when to use delete and when to use delete[].

And just in case that would be too difficult to handle, don't use new[] at
all. Use std::vector instead a C style array.

You should also consider using a RAII approach to handle memory allocation.
Write a wrapper class for pointers to single objects (or use std::auto_ptr)
and a similiar wrapper for pointers to arrays. Once you get used to it, you
don't have to worry about delete at all.

HTH
Heinz

Jul 26 '06 #2
In article <11**********************@75g2000cwc.googlegroups. com>,
"Denis Petronenko" <pe********@gmail.comwrote:
Why do i can't write "new [1]" instead of "new" everywhere in
applications? So, i will not need to track where i must call delete and
where delete[]. Therefore, it will simplify coding.
It would simplify coding more if you only called 'new' instead of
'new[]', and used std::vector wherever you used to use 'new[]'
Or application performance will be significantly reduced?
I doubt it.
Jul 26 '06 #3

Denis Petronenko wrote:
Why can't I write "new [1]" instead of "new" everywhere in
applications?
You can. Try it.
So, i will not need to track where i must call delete and
where delete[]. Therefore, it will simplify coding.

Or application performance will be significantly reduced?
Not significantly. However, new[1] will allocate extra space to save
the number 1. It's not uncommon to save 4 bytes. Also, delete[]
will be a bit slower because it uses a loop to call the dtor once.

The reason for the distinction is that these are low-level building
blocks, not intended for direct use. With smart pointers, you don't
need to call delete at all. (and with std::vector you don't call
delete[])

HTH,
Michiel Salters.

Jul 26 '06 #4
Denis Petronenko posted:
Hello,

Why do i can't write "new [1]" instead of "new" everywhere in
applications? So, i will not need to track where i must call delete and
where delete[]. Therefore, it will simplify coding.

Or application performance will be significantly reduced?

I actually used it once to *increase* performance one time:

#include <cstddef>

template<class T, std::size_t len>
struct DefInitArray {
T array[len];
DefInitArray() : array() {}
};

#include <cstring>
#include <ostream>
#include <cstdlib>
#include <iostream>

class StringStream {
protected:

enum { buflen = 1024U };
char *const pbuf;
char *pos;

public:

StringStream() :

/* LOOK AT THE FOLLOWING LINE */
pbuf( (new DefInitArray<char,buflen>[1])->array ),
pos( pbuf ) {}

StringStream(StringStream const &original) :
pbuf(new char[buflen]),
pos( pbuf + (original.pos - original.pbuf) )
{
std::memcpy(pbuf, original.pbuf, sizeof *pbuf * buflen);
}

StringStream &operator=(StringStream const &rhs)
{
std::memcpy(pbuf, rhs.pbuf, sizeof *pbuf * buflen);

pos = pbuf + (rhs.pos - rhs.pbuf);

return *this;
}

bool IsFull() const
{
return pos == pbuf + (buflen - 1);
}

StringStream &operator<<(char const c)
{
if( !IsFull() ) *pos++ = c;

return *this;
}

StringStream &operator<<(const char *p)
{
for( ; *p; ++p) *this << *p;

return *this;
}

void Print( std::ostream &out ) const
{
out << pbuf << '\n';
}

~StringStream()
{
delete [] pbuf;

/* Instead of this, I would have
needed something like.

normal_new ? delete pbuf : delete [] pbuf;

"normal_new" would have to be
a member object. Perhaps:

bool normal_new;

*/
}
};

--

Frederick Gotham
Jul 26 '06 #5
Frederick Gotham posted:
I actually used it once to *increase* performance one time:
I should have mentioned that that wasn't "real" code of mine -- there are
plenty of places where I would have taken the efficiency wrench to it.

--

Frederick Gotham
Jul 26 '06 #6

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:6K*******************@news.indigo.ie...
Frederick Gotham posted:
>I actually used it once to *increase* performance one time:

I should have mentioned that that wasn't "real" code of mine -- there are
plenty of places where I would have taken the efficiency wrench to it.
pbuf( (new DefInitArray<char,buflen>[1])->array ),
What's "buflen>[1]" supposed to signify?

-Howard

Jul 26 '06 #7

"Howard" <al*****@hotmail.comwrote in message
news:nR********************@bgtnsc04-news.ops.worldnet.att.net...
>
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:6K*******************@news.indigo.ie...
>Frederick Gotham posted:
>>I actually used it once to *increase* performance one time:

I should have mentioned that that wasn't "real" code of mine -- there are
plenty of places where I would have taken the efficiency wrench to it.

>pbuf( (new DefInitArray<char,buflen>[1])->array ),

What's "buflen>[1]" supposed to signify?
D'oh!!! I missed the matching < before that, sorry. (What's the smiley for
a shameful face?)

-H


Jul 26 '06 #8
Howard wrote:
D'oh!!! I missed the matching < before that, sorry. (What's the smiley
for a shameful face?)
http://en.wikipedia.org/wiki/Emoticon#Basic_examples
Jul 26 '06 #9
Frederick Gotham wrote:
...
I actually used it once to *increase* performance one time:
...
template<class T, std::size_t len>
struct DefInitArray {
T array[len];
DefInitArray() : array() {}
};
...
class StringStream {
protected:

enum { buflen = 1024U };
char *const pbuf;
char *pos;

public:

StringStream() :

/* LOOK AT THE FOLLOWING LINE */
pbuf( (new DefInitArray<char,buflen>[1])->array ),
pos( pbuf ) {}
...
~StringStream()
{
delete [] pbuf;

/* Instead of this, I would have
needed something like.

normal_new ? delete pbuf : delete [] pbuf;

"normal_new" would have to be
a member object. Perhaps:

bool normal_new;

*/
}
Firstly, this looks like a workaround for a compiler non-compliance
issue. Normally, there wouldn't be any need for that 'DefInitArray'
dealie, because in C++ 'new[]' does naturally accept the '()'
initializer. So, you could've just said

StringStream() :
pbuf( new char[buflen]() ),
pos( pbuf ) {}

Secondly, formally this is a hack that leads to undefined behavior in
the destructor. The type used in your 'new[]' was
'DefInitArray<char,buflen>'. That means that the argument of the
'delete[]'s shall have 'DefInitArray<char,buflen>*' type, not 'char*'
type. I.e. formally you still need some kind of branching in the destructor.

--
Best regards,
Andrey Tarasevich
Jul 26 '06 #10
Andrey Tarasevich posted:
Firstly, this looks like a workaround for a compiler non-compliance
issue. Normally, there wouldn't be any need for that 'DefInitArray'
dealie, because in C++ 'new[]' does naturally accept the '()'
initializer. So, you could've just said

StringStream() :
pbuf( new char[buflen]() ),
pos( pbuf ) {}

I wasn't aware you could do that. I'll use it in my future code :).

Secondly, formally this is a hack that leads to undefined behavior in
the destructor. The type used in your 'new[]' was
'DefInitArray<char,buflen>'. That means that the argument of the
'delete[]'s shall have 'DefInitArray<char,buflen>*' type, not 'char*'
type. I.e. formally you still need some kind of branching in the
destructor.

Damn it I hadn't considered that.

--

Frederick Gotham
Jul 26 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Nimmi Srivastav | last post: by
3 posts views Thread by Nimmi Srivastav | last post: by
5 posts views Thread by | last post: by
2 posts views Thread by Dave | last post: by
3 posts views Thread by Grizlyk | last post: by
4 posts views Thread by rgparkins | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.