boolean argument in class

[ag12]

I wrote a member function:
MA::MA(int ID, int num, const char first[20], const char last[20], int* arr, bool r)
{
BA(ID, num, first, last, arr);
this->research = r;
}
r and research are boolean.
he threw me out while running and told me it's because of the second line in the function... why?

[Ganado]

What did he throw you out of? A plane?

Okay, on a more serious note... if BA is the parent class of MA, you're invoking the parent constructor incorrectly. It would look more like this:

MA::MA(int ID, int num, const char first[20], const char last[20], int* arr, bool r)
: BA(ID, num, first, last, arr),
  research(r)
{ }

[Niccolo]

From what you've posted we can see almost nothing.

We need to know what MA is.

We have no idea what BA is or does.

We can't see the context in which this apparent constructor was called.

We need to see something we can test, something we can compile without having to assume so much.

However, with the assumption that this compiled, none here could theorize why a bool would refuse assignment to a bool at runtime. If this compiled the problem would have to be something about "this" instead of something about the two bools involved.

Yet, we just can't tell.

Also, when posting code, place the code between code tags, like this:

[code]
//all your code goes here
[/code]

[ag12]

BA is a parent to MA, they both inherit from an abstract class.

this is the full function, it's a constructor, and he been called from the main.

when he throw me out he wrote me " Exception thrown: write access violation. **this** was 0x64."

[Niccolo]

That's why we need the calling context.

If "this" was 0x64, that is not likely a valid pointer on anything other than an odd embedded processor.

We still have nothing to help you. We need more context.

However, the information from your error (which you should usually include when asking a question about such an error) indicates my theory is correct, the calling context is invalid and somehow you don't actually have a valid instance running.

So, how is this being called?

[ag12]

int arr3[7] = { 90,100,90,100,90,100,90 };
MA s3(345, 7, "yaacov", "jacobson", arr3, 0);

this is how it's been called.

and research belong to MA(the child), not to BA(the parent)

[Ganado]

I don't see anything obviously wrong with those two lines of code. What does the BA constructor do?

[ag12]

BA::BA(int ID,int num,const char first[20],const char last[20] ,int* arr)
{
	Student(ID, num, first, last);
	setGrades(arr);
}
void BA::setGrades(int*arr)
{
	int i = 0;
	while (arr[i])
	{
		grades[i] = arr[i];
		i++;
	}
}
Student::Student(int ID, int num, const char first[50], const char last[50])
{
	this->ID = ID;
	numOfCourses = num;
	int i = 0;
	while (i <= strnlen_s(first,20))
	{
		this->firstName[i] = first[i];
		i++;
	}
	i = 0;
	while (i <= strnlen_s(last, 20))
	{
		this->lastName[i] = last[i];
		i++;
	}
}

student is the class that BA inherit from.
the constructor of BA sent info to the constructor of Student and to a set function (they both are shown)

[Niccolo]

@ag12, is this some super secret source code you can't post?

Seriously, you MUST be able to recognize just how little information this includes. I just don't get that part. What is so secret that you can't post the code impacting the execution of your application?

Ok, enough rant.

There's only one thing I can propose as a valid theory.

We have the likelihood that "this" is not valid. This bit of code in your post of 4:04 pm shows it is allocated on the stack. At least that's something to work with, though it's tiny.

Assuming the code is operating correctly up to this point, when MA is constructed, then we must assume that "this" inside the MA constructor would be valid.

We must test that theory. BEFORE the call to BA, use debugging tools to view the "this" pointer's value (it should not be 0x64).

Now, call BA.

Did "this" change? That's my theory.

Something in BA is writing over the stack's memory, corrupting "this", and making anything that otherwise simply can't fail to fail.

It is likely BA is processing "arr" in such a way that there's a buffer overrun. Since I can't see BA, I have no idea.

If we test "this" before BA is called and it is invalid even then, we have entirely different problems, likely nothing to do with this bit of code.

Not much else to propose while blind out here.

It just so happens that 0x64 is 100 decimal, and that happens to be one of the values (repeated) in your arr3 array.

Curious, but not much to go on.

[Ganado]

ag12, first, something that applies to both your original post and your latest one: You're calling the base class constructors wrong. To properly initialize the base class object, it has to be done the way I did it in my previous example. Currently, your call to Student on line 3 is just making a temporary student object. You're not actually modifying the base object of your current object.

Second, line 9: while (arr[i]). What do you expect this to do? Your original arr3 array contains no 0s! So this is going out of bounds, and is most likely where your crash originates.

[Niccolo]

@Ganado, that was quick. I'd go so far as to say it's more that just likely, or most likely, it's most certainly going to do something wrong, very wrong.

@ag12, Ganado has the goods, and I'm glad the theory I was pursuing was essentially on point, but as you can see there was no way we could see the problem without the BA constructor.

Now, it's clear.

[keskiverto]

What is the reason of using plain arrays and C-strings?
Could you use std::vector and std::string in their place?
That would simplify the code and avoid some errors "for free".


Syntax for contructors (as already shown by Ganado):
https://en.cppreference.com/w/cpp/language/initializer_list

[ag12]

it's working!!!!!
thank's!!