Resetting pointer using new

Just wondering how you reset a pointer returned from a 'new' command to the first element in an array (currently I'm just using another pointer).

In the code example below the pointer returned gets moved using pointer arithmetic to clear the array. So what would reset the pointer to the first element in the array of characters?

Size = 100;
char *data = new char [Size];

// clear array
for( int l = 0; l < Size; l++ )
*(data++) = ' ';

delete[] data
A pointer is a variable containing a value, just like any other. If you want to change it, and you later want to reset it to its original value, you'll need to store the original value in another variable.

Think how you'd do it with ints:

1
2
3
4
5
6
7
8
9
10
Size = 100;
int myInt = 1234;

int originalValue = myInt;
for( int l = 0; l < Size; l++ )
{
  std::cout << myInt++;
}

myInt = originalValue;  // Reset myInt to its original value 


You'd do it exactly the same way for a pointer.
Last edited on
Instead of incrementing the pointer, use the pointer plus an offset.
1
2
3
4
5
6
7
8
9
10
11
const int Size = 100;
char *data = new char [Size];

// clear array
for( int l = 0; l < Size; l++ )
{
    //*(data++) = ' ';
    data[l] = ' ';
}

delete[] data;
lol simple when you think about it MikeyBoy - works well, thanks. Twas a late night coding session.

booradley60, I prefer pointer arithmetic because it's more efficient - rather than using 'data' AND 'l' variables. Although it could be argued the compiler would convert it to pointer arithmetic, I don't make these assumptions. :)
Last edited on
booradley60, I prefer pointer arithmetic because it's more efficient - rather than using 'data' AND 'l' variables.

Um, you're already using the l variable, as your loop counter. There's nothing less efficient about using it as an array index (instead of incrementing the pointer).

If you're going to be obsessive about efficiency, I'd argue that booradley60's way is more efficient than mine, because mine requires the instantiation of an extra variable, originalValue.

In fact, if you're going to be obsessive about efficiency, why are you bothering to set every element of the array to a space before freeing the memory?

In any case, being this obsessive about efficiency is usually counter-productive.
I prefer pointer arithmetic because it's more efficient

That's debatable. With an optimizing compiler, there is no difference. Your choice of which to code generally should be clarity of what you're doing.
Whoah calm down guys lol. :) You don't know what the application is, yet pour scorn on my need for optimization. Some applications *do* require ultimate optimization.

I do like to tread carefully when I'm at the debug stage, incase there's a bug in my code. Ofcourse I've now taken out the clearing of the array using the loop and the routine works fine - maybe I should have mentioned that. And the loop is *not* the only manipulation I do to the array - like I said it was just an example. It's all pointer arithmetic after that.

I already admitted it was up to the compiler AbstractionAnon, but I come from an era when you didn't require Gigabytes for an operating system to run acceptably lol.

Optimization seems to be a dirty word these days, and I can understand some that is said about productivity; but when you're writing system software it's a whole new ball game. :)
Last edited on
Doing pointer arithmetic instead of index access is *not* an optimization. This is this kind of "optimization" that at best produces exactly identical code, and sometimes even worse.

If you really cared about performance, you'd use memset to clear the array.
Last edited on
No it will not produce worse code, and you are clearly not listening to my comments about my mindset for optimizations - and what compilers can do. Probably in this case the compiler would be smart enough to spot this. But I think you really need to approach a task like mine with full focus on efficiency - rather than give the compiler 'the benefit of the doubt'.

Again you're not listening to what I've said rapidcoder, the array is not being cleared - that was for debugging purposes and to demonstrate the concept!
By using pointer arithmetic you're only making it *harder* for the compiler to optimize, because it has to revert it first to the index access to see the accesses are independent and the loop can be vectorised. Using pointer arithmetic is less readable and yields debatable perfomance gains, therefore I consider this premature optimization.
Last edited on
> If you really cared about performance, you'd use memset to clear the array.

It does not make a difference. The code can be written any which way; the compiler knows what is going on; in every case, it will generate a 'call' to memset (intrinsic: the call would be vectorized by the backend).

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
#include <cstring>
#include <memory>

void foo( char* begin, std::size_t n )
{
    for( std::size_t i = 0 ; i < n ; ++i ) begin[i] = ' ' ; 
    // 'calls' std::memset
}

void bar( char* begin, std::size_t n )
{
    for( auto end = begin+n ; begin != end ; ++begin ) *begin = ' '  ;
    // 'calls' std::memset
}

void baz( char* begin, std::size_t n )
{
    std::uninitialized_fill( begin, begin+n, ' ' ) ;
    // 'calls' std::memset
}

void foobar( char* begin, std::size_t n )
{
    std::memset( begin, ' ', n ) ;
    // 'calls' std::memset
}

http://coliru.stacked-crooked.com/a/ddab1940961e9839
Well pointer arithmetic is not less readable to me, I've always worked this way. Secondly that code I posted is not exactly the code that is in my program - merely to demonstrate a point, and a problem I couldn't see the solution too because I was up later than I perhaps should have - coding.

Seriously, I'm not going to debate my code after a solution to bleary eyes was answered - thanks MikeyBoy. And especially when you've not seen my routines in context - in context is the point in any problem. What seems like a bad idea on the surface, is the the most efficient in the particular situation.

Clearly problem solved doesn't mean the topic is closed - it should be.

This is getting silly, JLBorges, the array is not getting cleared in my real code!!!!!!

lol lesson learnt, ask question, thank solution, leave before you get patronized to death haha.
Last edited on
> This is getting silly, JLBorges, the array is not getting cleared in my real code!!!!!!

My response was clearly marked as a response to this assertion:
'If you really cared about performance, you'd use memset to clear the array.'

Yes, this has got really silly now.
Particularly after gratuitous concerns about efficiency were being rather freely bandied about.
Haha :)
Topic archived. No new replies allowed.