Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
So, just for my peace of mind, isn't it a logical error to assign a value to a static member variable within a class constructor?
Edit : I mean using the = operator
Won't the value keep changing with every object declared?
Suppose I send in a value to the constructor which I then use to set the value of a static variable. With each object declared the value of the static variable would keep changing.
It is only a logical error if you consider it to be one.
If however the change of the value of the static variable with each constructor is exactly what you WANT it to do, then it is not a logical error.
As in the comments already mentioned, one example is to count all constructors. This is often accompanied by also counting all DEstructors and in the end yields a count of existing instances.
The example could be implemented by using the = operator on the static variable,
count_of_ctors = count_of_ctors +1;;
though it probably would usually use ++,
count_of_ctors++;.
In the special case outlined in the question, setting a variable to a value given as parameter to the ctor, it could achieve the same, i.e. by giving the current value of the static variable, increased by one.
But you probably meant a value which is not derived from the current value of the static variable.
That still could be intended behaviour. I imagine that recording the last date+time of an instantiation could be such a value, which could serve debugging or logging purposes. That would be used by instantiating always with the current time.
Since the current time would probably better be read by the ctor (for convenience and for tampering protection), here is another idea. For each instantiation, the ID of the user (and maybe a matching passwort) has to be given, so that the static variable always has the last user ID which created an instance.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
But by using what variable as a parameter, a function may change a variable that is defined in another function?
The phrasing of this question suggests it is from a test. Most likely, the intended answer is that declaring a parameter as a reference provides access to the passed object.
Access to an object can also be obtained by any means that provides its address. For things passed through parameters, this includes:
Pass a pointer.
Pass (the address of) some helper function that returns a pointer or reference.
Pass a pointer or reference to an object with a known relation to the object (for example, pass a pointer to the first element of the array and the index of the array element to be accessed).
Pass an integer or string properly converted from a pointer, so that it may be converted back.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Suppose we declare A to be of type Type:
Type A;
Question: is the Type constructor for A called at this point? Or is it only after we initialize A that a constructor is called?
is the Type constructor for A called at this point? Or is it only after we initialize A that a constructor is called?
You are initializing A here, whether you explicitly provided a value for that process or not.
There is no opportunity to initialise A "later"; you can only assign to it later. (Early C texts talk about "initialising" numeric values long after declaration, but that's a different language, a different century, and a different set of descriptive idioms.)
So, yes, the constructor is called as soon as the object's lifetime begins. That's either right there and then, on that line, or if a class member then of course it's when the encapsulating class is being initialised and it's this member's turn.
Of course you could have proven this with a simple std::cout pair.
Yes, it is called immediately. When you assign it a value, the assignment operator is called instead.
The only exception is this:
Type a = value;
Here some compiler with some settings may relax it and call constructor directly with the value as parameter. But it still needs to be part of declaration.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
int val1 = 0;
int val2 = 0;
int val3 = 0;
I don't understand why I have to put these = 0, is there any meaning behind it?
Initialisation of values to 0 or anything else is optional. If you don't though, the variable could contain anything...
This actually depends on where you declare the variables.
If you declare them as local variables (e.g. inside a function) then the compiler and runtime system will not initialize them, their values will be indeterminate. Using such variables except to initialize them will lead to undefined behavior.
If you declare them as global variables, then the compiler and runtime system will make sure that they are zero-initialized.
If you declare the variables as member variables inside a class or structure, then their initialization depends on if you have a constructor or not. If you don't have a constructor, or or a defaulted constructor, then the compiler will automatically generate a constructor which will default-construct the (non-static) members, which for int variables is the same as zero-initialization. If you have a constructor, the (non-static) member variables will be uninitialized just like local variables.
when declaring a new variable, it is stored on your current stack. it MIGHT have garbage in it from previous uses, so the only way to make sure you're new variable initial value is indeed 0 is setting it to zero when declaring
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Are static variables in C++ internal variables or external variables? Or can be both?
PS: It seems to me that (not sure it's correct):
Internal variables are assigned their values at compile time.
External variables are assigned their values at link time.
Initialization depends on the type of the static variable.
With fundamental types and initial values that can be computed at compile time, the variables initial value should be layed down in a section of the executable that is mapped into memory with copy on write semantics.
However, the compiler can also decide to initialize static variables at runtime, typically before main() gets executed. But afaik, the only constraint is that initialization is finished when the variable is first used, and that static variables within a compilation unit are initialized in the order they are written (in case their initializers depend on one another).
The point is, that static variables are initialized before they are used by code called from main(), but it is not specified when this initialization happens. The compiler can do what it deems most efficient.
In any case, static variables live at least until main() exits or exit() is called. I am pretty sure that C++ will also call the destructors before terminating the process, but I don't know about that.
According to the C++ Standard
3 A name having namespace scope (3.3.6) has internal linkage if it is
the name of — a variable, function or function template that is
explicitly declared static; or,
As for your statement that
PS: I learned that • Internal variables are assigned their values at
compile time.
• External variables are assigned their values at link time.
then it is wrong.
In my opinion you are trying to mix up two notions: static storage duration and program linkage.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I've noticed this weird behaviour/bug where a class method is called before the actual object is initialized. I have a wrapper object, which has operator->() method. Now, when I'm passing the object to another object as constructor parameter in a constructor using the operator->() method, the actual wrapper object doesn't get constructed, but rather just runs the operator->() method.
As the actual code sample is pretty complicated and depends on many other things, I'll just show C++ code snippet which may not compile properly:
template<typename T>
class wrapper_object_type
{
public:
wrapper_object_type() {/*does not run*/}
T* operator->() {/*does run*/}
};
class bad_behaviour
{
public:
bad_behaviour() : another_object(wrapper_object->t_object)
{/*crashes(0xccc access violation*/}
};
So is there something defined in the standard that may allow such behaviour? Or more accurately, are there some implicit constructions etc. which could bypass the default construction?
Probably you use wrapper_object before it gets initialized. Member variables are constructed in the same order in which they are declared in the class, so make sure wrapper_object is declared before another_object.
(Assuming wrapper_object and another_object are members variables of bad_behaviour, but without a more reasonable code sample it's hard to say.)
Well I did it the hardway; I switched the objects from stack to heap and initialized them explicitly via new keyword rather than in initializer list. As I thought, that didn't reproduce the weird behaviour, so it worked as intended. What I'm thinking now, is that it may be actually a compiler bug, since the way I did it via initializer list is analog to how I fixed the problem. Only thing that changed was the fact that I didn't allocate them in heap before.
I also tried to provide working code which reproduces the bug, but the bug wasn't shown there. It may be because the actual code where the bug was noticed, relies quite heavily to template types and wrapper objects. As it works now when the objects are allocated in heap, the bug isn't in the code but rather in the compiler.