creating new class question

[rodriguez 269]

is my constructor and destructor ok here or do i need to initialize the arrays instructions, var_one, var_two aswell

program.h

#pragma once



class program
{
	static const int MAX_number_instructions = 1000;
	public:
		
		program(void);
		~program(void);

	char instructions[MAX_number_instructions][3];
	int var_one[MAX_number_instructions];
	int var_two[MAX_number_instructions];
	int program_next_slot;
	



};

program.cpp

#include "StdAfx.h"
#include "program.h"

program::program(void)
{
	this->program_next_slot = 0;
}

program::~program(void)
{
	int x;
	x = 0;
}

[S6k9GNh0]

1) Use initializer lists: program::program() : program_next_slot(0) {}
2) It's good to assign each variable _something_ to make sure that no one grabs a variable with junk in it.
3) What is the point of your deconstructor? Making a temp variable and setting it to 0 does nothing.

[imi]

You don't need to initialize the arrays as long as you remember that you shoudn't read from them before writing some value in there.


Oh, and the destructor is silly, right? ;-)


Ciao, Imi.

[rodriguez 269]

1)ya the destructor should be blank. I was using break points and just wrote some code to check if those lines were ever run.
2)

1) Use initializer lists: program::program() : program_next_slot(0) {}

does this have the same affect as what i did? also if i wanted to set some other part of the object foo to 1 would i write
program::program() : program_next_slot(0) : foo(1) {}

or
program::program() : program_next_slot(0) {}
program::program() : foo(0) {}

ps. I am not worried about grabing junk I have many checks for that in my main program, the question is would the exe get stuck in the constructor if i dont set values to the arrays?

all replies are very apreciated

[Onanymous]

You should not initialize arrays by default. There is nothing wrong with it from language point of view, it is a bad idea as far as efficiency is concern, and in the end it is better for debugging that you grab junk, then any reasonable but meaningless value.

and also no explicitly defined destructor is better then empty destructor. and as far as I remember the standard, destructors should be declared as ~classname(). without void. This may fail to work with another compiler.

[imi]

and in the end it is better for debugging that you grab junk, then any reasonable but meaningless value.

Reminds me that it can have a debug-ish advantage to leave them uninitalized if "access before write" is the wrong thing anyway: Some environments (e.g. VS2010) give you nice debug-asserts should you try to access uninitialized memory. Convinient!

and also no explicitly defined destructor is better then empty destructor.

Why that? (Not that I say it's better to define empty destructors all around, but I'd say it just does not make any difference in terms of generated machine code)

and as far as I remember the standard, destructors should be declared as ~classname(). without void. This may fail to work with another compiler.

Really? As far as I remember, both statements are syntactical equal.

[Onanymous]

2. Because no explicitly defined destructor leaves room for automatic one. :)
3. I checked that... you are right, sorry. But that is why I said `as far as I remember'. :)

[jsmith]

@rodriguez:

program::program() : 
    program_next_slot(0),   // <--- Note: it's a comma, not another colon
    foo(1) 
{
}

Initializer lists are the preferred way to initialize data members. One thing to keep in mind is that
data members are initialized in the order in which they are declared NOT the order in which
you initialize them. This is per the C++ standard. (A good compiler should give you a warning if
you attempt to initialize them in the wrong order).


@Onanymous:

I disagree with:

You should not initialize arrays by default. There is nothing wrong with it from language point
of view, it is a bad idea as far as efficiency is concern, and in the end it is better for debugging that you
grab junk, then any reasonable but meaningless value.

When debugging, you should *always* initialize everything, regardless of cost. By initializing things,
you guarantee reproducibility. There's nothing like tracking down a bug in a program where an
uninitialized variable gets used and just so happens to be a reasonable value 99% of the time.

I would even go so far as to argue that unless initialization is causing a noticeable performance hit,
you should initialize everything even in a release build for the same reason. Bugs happen in releases
too.

[imi]

When debugging, you should *always* initialize everything, regardless of cost. By initializing things,
you guarantee reproducibility. There's nothing like tracking down a bug in a program where an
uninitialized variable gets used and just so happens to be a reasonable value 99% of the time.

On the other hand, if you debug using Visual Studio 2010, you get a nice Assertion Popup as soon as you access any uninitalized memory location. (In debug settings, VS compiler initializes memory with some magic pattern like CDCDCDCD and checks before accessing).

If you don't have any semantically sane value you could use to initialize an memory location with and rather would be alarmed by your friendly debugger should you ever accidently access this memory location (including array out of bounds from other classes), then "not initalizing" make things so much easier.

Ciao, Imi.

[jsmith]

Point taken, for those who use VS.

[firedraco]

That reminds me of some compiler (or maybe it was someone who was saying what they would do), that supposedly in Debug builds set uninitialized variables to random values in an attempt to create errors, but in Release mode it set them to "nice" values (0 for ints, etc) in an attempt to reduce errors.

[jsmith]

reduce errors?

cover up bugs, maybe.