Does XCODE .... or is there any way to force or verify this

[gilesgoat]

Strange thing ..

Suppose a simple thing as that :

class Pappine {
int a,b;
};

.. somewhere ..

pb = new Pappine;

at this point the value of pb->a or pb->b are completely undefined and could be "any shit".

THEORY : in XCODE they would be both 0
THEORY 2 : in Visual Studio NO

PROBLEM : is any way to "force clear all that mem to 0 at any new ?" by some magic compilation flag ?

OK of course "better way" would be to do in

Pappine::Pappine { a = b = 0; }

But I am chasing "a few things" and I already found a few little thingies like "oh this is used but in SOME weird cases it could be uninitialised".

Thing is VS is "normally good" in telling you this but in that case it seems it can't see that actually that pb->a never been initialised to anything.

I also "semi suspect" that XCODE has "the bad habit" someway ( or is it's "a sheer case of mega luck of the iPad ?" ) to initialise to 0 anything even when created on stack i.e.

void Banana()
{
int a;
}

that 'a' is 0 without initialisation.

I just spent 1 hour to find out a thing like :

if(rots.x!=0)
{

.. and it was not, it was a shit of number with no meaning, someway it was always 0 on the iPad and I have no fucking clue about WHY/HOW ..

Yet there was absolutely NO warning of the kind "look you are using an uninitialised var" or such.

[_TinOmen_]

This page recommends a few tools that will report uninitialized class members: http://stackoverflow.com/questions/2099 ... -variables

[Dio]

You can overrride global new and memset the allocated memory to 0, but that won't help with the stack.

If you want a more efficient alternative, only in debug builds, fill the entire thing with some known junk value and scan the class for the junk value at the end of the constructor and assert on the result. The junk value probably needs to be 32-bits to avoid false positives so it won't detect any errors smaller than that. Again, I'm not sure I can see how to make this work on the stack and still allow initializer lists, and it won't catch everything, but it should cover the majority of cases.

Alternatively, to avoid the need to muck with the class definition at all, you can probably write a test function that does the same thing (instantiates each class object once and checks for the absence of the junk value). That would then catch stack cases as well.

[gravy]

That\'s the way

Code: Select all

#include <cstdlib>
#include <exception>
#include <new>

void* operator new (size_t _size)
{
	 void * mem=malloc(_size); 

	 if (!mem)
	 	throw std::bad_alloc();
	
	// Fill the memory with the stuff you want here 	

	return mem;
}

That'll override every new in your program. And as Dio points out this doesn't work for stack variables or ones you'd allocate with placement new

To be clear, this has nothing to with Xcode.

[gilesgoat]

Ah ok, so it's possible to redefine the operator "new".

About the stack thing I think in that case VS is actually clever enough to, in case this happens, throw an exception like "used uninitialized var xxx" or sorta, I've seen it happening in a few cases.

[tufty]

Redefining new() to cover bad programming practice is about the most stupid thing you can do. It puts an extra overhead on most of your allocations, and will still only cover you in certain, specific circumstances.

There's a few things you can do to pick it up.

Firstly, under GCC, there's -Weffc++. Most people won't like that, as it will point out, loudly and pedantically, exactly how bad they really are at C++.

Next, there's valgrind. Use it, listen to it. You can add a valgrind step to XCode's builds.

The best plan, though, is to add default initialisers to your classes. Y'know, so that your memory is always initialised properly. You presumably need to do it anyway in order to actually use your objects, so why not do it the way you're supposed to?

[gravy]

Redefining new() to cover bad programming practice is about the most stupid thing you can do. It puts an extra overhead on most of your allocations, and will still only cover you in certain, specific circumstances.

[Dio]

Redefining new() to cover bad programming practice is about the most stupid thing you can do. It puts an extra overhead on most of your allocations, and will still only cover you in certain, specific circumstances.

Actually it significantly reduces overhead if, as in most cases, the initialisations are mostly to 0, because the compiler makes a right mess of it compared to an SSE memset (if the class inherits, the compiler can't possibly do it as efficiently). The number of non-NULL initialisers can usually be counted on the fingers of one hand.

[gravy]

If you're memsetting a class to zero to solve bugs then somethings really not right. Especially as that approach means stack allocated classes will act differently. Or if they're included as a member in another class

Just say no.

[BillyT]

The thing about C++ is you have constructers and de-constructer functions. What I normally do is set all the variables that need setting in the constructer - that's what it's there for. Then allocate and resources. In the de-constructer I get rid of the allocated resources.

This is how c++ was designed. If you follow this practice you will have no weird unintialised data and no memory leaks.

[gilesgoat]

Obiviously "you have to know what you are doing in any moment", however believe me or not we do have quite a number of cases where :

class something {
<list_of_many_vars>
};

Then would have really a thing like :

something::something {
ptr1 = NULL;
ptr2 = NULL;
ptr3 = NULL;
ptr4 = NULL;
ptr5 = NULL;
ptr6 = NULL;
var1 = 0;
var1 = 0;
var2 = 0;
var3 = 0;
var4 = 0;
.. etc..
}

Because that would be EXACTLY the "default value" we want for anything that has not to be <>0, so a "bulk 0 initialisation" would really be not that bad ..

Anyway yes those missing intialisations were true bugs ( cause some not-properly-seen-yet-very-unlikely-to-happen-state-transitions ) and actaully a "default fillup to some shit<>0 value" would have actually sped up to find them.

That rot.x I found for example was a "strange case" of a spinning angle of a rotating thing, it really did not matter at all what default value was in BUT maybe a "weird value" did cause an overflow ( or maybe a NAN ? ) somewhere else.

[edit] that class that was using that rot of course did had a class initialisator, but it was never initialising that rot because "it was assuming something else using it had to do it".

[Dio]

If you're memsetting a class to zero to solve bugs then somethings really not right. Especially as that approach means stack allocated classes will act differently. Or if they're included as a member in another class

Just say no.

I wouldn't add it after the fact to fix bugs, but designing it in from the start may be the lesser of two evils in performance critical cases.

[gravy]

If you're memsetting a class to zero in operator new for efficiencies sake something is still going horribly wrong.

The malloc is going to be chewing up your time. If you do placement new or put in your own memory manager there'd be a marginal argument for it. The benefits would have to outweigh your class not having the same behaviour when it's instantiated in different ways.

Honestly, it's a dog's dinner.

[tufty]

As gravy says, malloc is going to take up vastly more time than initialisation. If you're worried about the time member initialisation is taking, you're probably using the wrong language (or, alternatively, you should be replacing new() to allocate from a preallocated block of memory rather than doing a malloc every time you want to allocate an object)

As a test, I had a look at what gcc does for C++ static initialisers:

#include <iostream>

Code: Select all

class foo {
public:
  foo() : x(0), y(0), z(0) {};
  ~foo() {};
  int x;
  int y;
  int z;
};

int main(int argc, char ** argv) {
  foo * f = new foo();
  std::cout << f << std::endl;
  return 0;
}

With no optimisation, the initialiser for foo (using g++ for arm, which is not overly mature) looks like this:

Code: Select all

	movl	-4(%ebp), %eax
	movl	$0, (%eax)
	movl	-4(%ebp), %eax
	movl	$0, 4(%eax)
	movl	-4(%ebp), %eax
	movl	$0, 8(%eax)

With -Os, we get this:

Code: Select all

	movl	$0, (%eax)
	movl	$0, 4(%eax)
	movl	$0, 8(%eax)

You aren't gonna get much faster than that.

[gilesgoat]

Just a curious question then, what kind of mem allocation NEW uses ? IIRC it should use some sort of 'heap alloc' stuff, according to what you say "whatever it does it should be faster than malloc()" but what does it really ?