Posts by grumpier

i dont understand the memset thing

char* binary = new char[ElementAmount];
memset(binary, 0, sizeof(binary));

That code is a beginner's error, and tends to yield bugs that are hard to track down. The memset() call should, presumably, be "memset(binary, 0, ElementAmount);" to set all bytes in the dynamically allocated array binary to zero.

You're paraphrasing, based on where you think the problem is, and the end result is that you haven't provided enough information for people to help.

You haven't explained what you mean by "non-working". Does the code fail to compile? Or does it compile, but fail to link? Or does it compile and link, but run incorrectly?

The code you've shown does not use the iterators from your Array class: it uses iterators from the multimap class.

Making a stab in the dark, I'd guess your problem is that your Array class needs you to implement a copy constructor and/or assignment operator.

Normally I would do something like this for dynamic allocation:

Contestant* C = NULL;
C = new Contestant;
if(C)  // test valid allocation
{
// do whatever you want here


// Memory deallocation
delete C;
C = NULL;
}

Your approach will not work: operator new does not yield a NULL pointer on failure - it throws an exception. The "if (C)" test in your code therefore cannot yield false.

Maybe you can use your formula in an actual code example?

Well, I could. But that takes the challenge of problem solving away from you.

Look back in my previous posts in this thread for definition of T, n, etc.

VernonDozier has worked out what I'm saying which is evidence that, with a bit of effort, you will be able to as well.

RTFM is the rule, google is your friend that makes it easy to follow the rule. Results of searching for LNK2019 yielded this and of searching for LNK1129 yielded this as the first hits.

In short, you have code that is trying to call a function (or multiple functions) you have not included in the build.

Start with T(0) = 1.

In a loop use the fact that T(n+1) = x*T(n)/(n+1) to compute each term. Add the terms together.

Practically, when working with templates, it is necessary to have the template definitions (ie the implementation of template member functions) in the header file. It is not possible (with most compilers) to compile templates separately.

The reason is that, when using templates, the compiler needs to see the definition (ie implementation) of template functions at the point the functions are used rather than just a declaration (a prototype).

In other words, #include "bintree.cc" in "bintree.h", not the other way around. I normally would rename your bintree.cc to bintree.tem (or some other extension) to avoid the temptation to compile it separately.

There are some compilers that allow you to have separate definition and instantiation of templates, but the hoops you have to go through to achieve this are compiler dependent.

The next problem you will find is that you have no implementation of bintree<T>::insert(const T, bin_node<T>*) ;)

I have no idea how your teacher's program works -- you would have to post it. I can only suspect he used one of the huge integer libraries like I previously suggested. Its also possible he used strings instead of integers to avoid the limitations of integers.

Oh, please! Huge integer libraries or strings are needed for some things, but falling back on them for basic problems like this is crazy.

The program can go to much higher terms simply using the fact that e^x = 1 + x/1! + x^2/2! + ... and that the n-th term inthis is T(n) = x^n/n! It is trivial to show that T(n+1) = x*T(n)/(n+1).

The code to use this relationship to compute an approximation of e^x is easy. This avoids the possibility of overflow that is inherent in computing x^n or n! separately.

But if i make DB, DC as char its not possible to add 1024.

then how to add 1024 bytes to that

You need to make DB, etc pointers to char.

sizeof(char) is 1, by definition in the standard. So if DB is your base address, DB + 1024 is a pointer to a location 1024 bytes after DB.

Try describing to us what you think the code does, and we'll check if you're right (or how right you are).

You'll learn more if you think it through and describe what's happening so others can understand rather than simply getting others to do the work for you.

Well, I was right. The problem is in your createArray() function .... and in what it does with the arguments passed to it.

ABLast is 1 in main() so the various Bit... arrays in have one element. These are passed to developArray() and then to createArray() which passes them to run() (as the argument named i). run() - in a loop - increments i and sets the value of Bit. That therefore changes ABLast in main() and falls off the end of the Bit.... arrays.

You won't have seen it in your test cases, but input() will also merrily fall off the end of your arrays if handling files with more than 10 words on a line.

Well, I'm not sure if that is the case because I ran tests throughout my developArray function, after each individual thing, and it only changes once it hits the red sections.

No .... you mean your tests did not detect a problem. Your tests will only check things you think to test. If you didn't anticipate the particular problem that is occurring, a fault will get past your testing and cause chaos later.

In practice, at least 95% of problems with "variables changing in unexplained ways" result from some code that the programmer has previously tested and insists is unrelated to the problem. I believe that is happening for you.

It's fine before the red, but changes after if goes through the each createBit() line. The odd this is that BitAB and BitB are changed, but BitA has no issue what so ever.

Yep. That's the way it goes. Symptoms caused by malfunctioning code tend to manifest in odd ways .....

Now, one thing I thought about is should I just get rid of createArray and put all those call functions back into the main() cause perhaps that would eliminate the issues but I don't see why that would change anything.

That's because you are assuming the cause of the problem is the code where you see the problem. Whereas, code that is run previously is also a candidate as the cause.

The cause of your problem is almost certainly code executed before your red lines are reached.

My guess - although you haven't shown them - is that the problems really occur in your input() function or, possibly in your createArray() or removeDup() functions.

I'd even guess further that - in writing those functions - you have assumed that an array size can magically change within those functions. If so, you are mistaken. So one of those functions is falling off the end of one of your arrays and corrupting random memory.

Also note that you are passing ALast - an uninitialised variable - to input(). If input() uses its original value you get undefined behaviour. If input() sets ALast to something more than 10, and then loops over the array (from 0 to ALast-1) it will fall off the end of the array. Similar comments for BLast.

A couple of general tips: when trying to find problems like this

1) Do not assume a problem occurs at the point it is detected. The cause is almost certainly code executed before the problem is detected.

2) Try to find a small but complete sample of code that illustrates your problem. In the process of getting to that small but complete sample you might identify the problem yourself. If not, you are not relying on people to work out what is happening in code you have not provided.

To grumpier:
full ordering and partial ordering - feel the difference. Look at the TOTAL word in my post before make the conclusion "That's not true".

My original comment stands. The word "total" does not make your post any more correct.

The last sentence in you post does explain nothing: "a pointer is not the same thing as an integer, so comparison between them is not allowed" but godlike111 asked why?..

You obviously can't understand simplified language. The "why" is that pointers and integers represent completely unrelated things (concepts, quantities, abstractions....), so there is no sense in comparing them.

Because of no total linear memory space concept in platform-independent C++ language.

That's not true. The memory model in C and C++ is linear. Or, at least, the memory available to a program consists of a series of one or more sequences of contiguous bytes.

However, a pointer is not the same thing as an integer, so comparison between them is not allowed.

Well, yeah, you can look at the first character, but that will not distinguish "Adam" from "Anthony". If the first characters are equal, then it's necessary to look at the second .... and then third, and so on - which is exactly what strcmp() does.

As a rough rule, in most character sets (at least, as far as English speakers are concerned);

- numbers are less than letters
- Uppercase letters are less than lower case ("Adam" comes before "adam", unless a case-insensitive comparison is performed with stricmp()).

The relative order of punctuation, whitespace, and graphical characters varies with character set, but normally the default character set makes sense to the locale (eg an English speaker will tend to use a character set that places whitespace less than common punctuation which is less than letters or numbers).

Thx, I'm going to do that. But just out of curiosity, let's say i write:

string *ptr = new string;
string *alt = ptr;
ptr->assign("Happy Day");

cout<<"On alt adress is: "<<*alt<<endl;
    
cout<<"deleting ptr"<<endl;
delete ptr;
cout<<"ptr adress: "<<ptr<<endl;
cout<<"alt points to: "<<*alt<<endl;

Now program is terminated as it tries to read *alt (so delete really destroyed contents on that memory location).
If i replace string with my own Complex, it works fine, like it never was deleted.
How did string writers managed to do that?

ptr and alt point to the same dynamically allocated string. "delete ptr" deletes that string, so it no longer exists (as far as your program is concerned). Any dereferencing of ptr or alt (eg attempting to print *alt) therefore yields undefined behaviour.

Undefined behaviour means - according to the C++ standard - that anything is allowed to happen when the code is compiled/executed. This means that doing it with different types (eg string and your Complex) can exhibit different types of behaviour. Or the same type of behaviour. Or the behaviour can depend on phase of the moon.

As to the actual reason your code terminates with string and not with your Complex type: that depends on your compiler, operating system, etc. In rough terms, it will be because a string type dynamically manages memory (eg it contains a pointer, and allocates/releases memory to that memory) so the act of dereferencing a pointer to a non-existent string and printing it is more …

The standards specify that elements of declared arrays are contiguous. N-dimensional arrays are actually arrays of (N-1)-dimensional arrays. So ..... the compiler is required to do what you want (at least, in terms of storage).

In terms of mechanism of element access (eg accessing element_in_N_dimensions vs equivalent access of element_in_one_dimension) that's up to the compiler. But the math is pretty trivial so most self-respecting compiler writers will pick an efficient (hopefully optimal) approach.

There are some ways to force the compiler to do it particular ways (optimal or sub-optimal). For example;

int i, j;
   int ***array = malloc(sizeof(int **)*1000);

   for (i =0; i < 1000;++i)
   {
         array[i] = malloc(sizeof(int *)*1000);
         for (j =1000; j >= 0;--j)
         {
              array[i][j] = malloc(sizeof(int)*1000);
         }
   }

emulates a 3D array using a pointer-to-pointer-to-pointer. It also allocates elements of that pseudo-array in a manner that elements are unlikely to be contiguous. Since this happens at run-time, the compiler cannot behave as if the "array" is actually a contiguous one-dimensional array - because it might not be.

Stepping through a MS-DOS based program in an IDE trying to find the source of a bug. Next thing: the computer did a warm boot, but was unable to come up again because it couldn't find a system drive.

After restoring from backup (and being very thankful I had a backup) an examination of the offending code revealed an invalid pointer operation that, it happened, executed the DOS interrupt for reformatting disk tracks......

You miss the point, which is that it is better to avoid the self-assignment test in the first place. I mentioned the "create a temporary and swap" approach as an example of an approach to avoid doing a self-assignment, not as the only way. Apart from classes with an operator&(), the self-assignment test does not work well in class hierarchies either, even with use of boost::addressof().

You will also find that it somewhat difficult to implement an exception-safe assignment operator without creating a temporary copy - of either the object itself, or (at a minimum) of the data it contains. Doing a self-assignment test - even if it works - does not change that.

In addition, operator= sceleton should be:

ThreeD& operator=(const ThreeD& op2)
{
    if (this != &op2)
    {
         ....
    }
    return *this;
}

The above is common practice, but it is easily broken. Imagine, for example, a class that supports its own operator&() - it will not perform as you intend.

Generally, it is better to code in a manner that prevents self-assignment in the first place.

The most useful way I've found to do an assignment operator is;

void ThreeD::swap(ThreeD &op1, ThreeD &op2) 
{
     // do the swap in a way that is guaranteed not to throw exceptions
}

ThreeD& operator=(const ThreeD& op2)
{
    ThreeD temp(op2);
    swap(*this, temp);
    return *this;
}

This approach is exception safe (if an exception is thrown - a normal way of reporting a terminal error) the objects being acted on have no effect. No need to check for self-assignment: the only cost is associated with creating a temporary copy of *this.

This approach is recommended - as one of many practices to be used collectively - in some coding standards designed for using C++ in high criticality systems ie systems that will cause major real-world damage (eg people dying) if they behave incorrectly.

A fair amount of individuals stated that returning a reference of the actual object that represents the class is more preferable than returning a copy that has the reflected changes made on the object.

Yes it is.

Sure, for performance reasons, it might be better. But now you …

While tempted to suggest "draw and quarter", the fairest treatment would be forcing them to pay my internet bill. After all, if they consume my bandwidth and quota without my permission, they should pay me for the usage. The fact I pay for an internet connection does not bestow permission on anyone to send me spam.

As Narue said, the reason is that your class's operator delete() does not release the memory. If you do this;

void operator delete[] (void* ptr,size_t size){
		cout<<"in operator delete : ";
                ::operator delete[](ptr);
	}

it will release the memory.

The whole purpose of overloading an operator delete is to correctly manage deallocation. In other words, you have to do it.

Both ways compile so as long as this isn't just lucky I will just learn without the & sign as it makes more sense to me (though maybe it shouldn't lol).

Without the ampersand (&) the function creates and returns a temporary copy of the object it is acting on. This involves invoking a copy constructor and (when the caller has finished with the returned object) destroying it.

While a compiler is allowed to eliminate temporary objects in some circumstances, it is usually better to return a reference for performance reasons.

Since it is a dereferenced pointer it isn't returning an address but an actual ThreeD class. Thats my newb take on it.

Your "newb take" is wrong.

A dereferenced pointer technically yields a reference. The object that reference refers to can be copied, which is why your operator=() can be implemented as returning an object by value (without ampersand) rather than a reference.

Also, returning an object by reference does not return "an actual ThreeD class". It returns "an instance of ThreeD" or "an object of class ThreeD".

Functions can return objects. They do not return classes.

Ah. I forgot to take into account all the constraints to reduce overflow. You're probably using a 16 bit integer. n^2 needs to be representable in your integer type. 781^2 will not be representable in a 16 bit int, but will be with a 32 bit integer.

You can push to larger values of n by using the modulo relationship for addition (a + b) mod n = ((a mod n) + (b mod n)) mod n. If you use that, only 2*n needs to be representable in your integer type.

1) First, represent a polynomial (of the form c_0 + c_1*x + c_2*x^2 + .... c_n*x^n) is represented by an array with elements (c_0, c_1, c_2, c_3, .... c_n).

2) Work out how to multiply two arbitrary polynomials together. ie. given a polynomial A (a_0, a_1, a_2, a_3, .... a_n) and a polynomial B (b_0, b_1, b_2, b_3, .... b_m) work out how to obtain a polynomial A*B = C = (c_0, c_1, c_2, c_3, .... c_(m+n)). Hint: The process to produce C from A and B is called convolution.

3) For the first root on the command line, create a polynomial X = (root, 1).

4) For all other roots on the command line;
a) create a polynomial Y = (root, 1)
b) obtain a polynomial Z = X*Y using the approach worked out in Step 2.
c) set X = Z

5) Voila!!!

Look at a small example

(21^5) mod 13

Step 1: 21 mod 13 = 8 (i.e remainder on dividing 21 by 13 is 8).

Step 2: ((21 mod 13) * (21 mod 13)) mod 13 = (8 * 8) mod 13 = 64 mod 13 = 12. This means 21^2 mod 13 = 12

Step 3: Use fact (from step 2) that 21^2 mod 13 is 12 and (from step 1) 21 mod 13 is 8. So 21^3 mod 13 = ((21^2 mod 13)*(21 mod 13)) mod 13 = (12*8) mod 13 = 96 mod 13 = 5.

Step 4: Use fact (from step 3) that 21^3 mod 13 = 5 and (from step 1) that 21 mod 13 = 8. So 21^4 mod 13 = ((21^3 mod 13) * (21 mod 13)) mod 13 = (5*8) mod 13 = 40 mod 13 = 1.

Step 5: Use fact (from step 4) that 21^4 mod 13 = 1 and (from step 1) that 21 mod 13 = 8. 21^5 mod 13 = ((21^4 mod 13) * (21 mod 13)) mod 13 = (1*8) mod 13 = 8 mod 13 = 8.

I've used a small values here (i.e. you can compute 21^5 by hand, and then find the remainder on dividing by 13). And you will find - if you do it that way - it is 8. The difference is that the method I've described will also work for 21^65 mod 30001 (albeit more iterations) without producing a value that can't be stored in a 32 bit integer along the way.

According the the C++ standard (Section 5.8 para 1 "Shift operators") "The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand."

In other words, assuming your unsigned type is 32 bits, you are not allowed to do a left shift of more than 31 bits. Anything is allowed to happen if you do. If you do a single left-shift 32 times (as opposed to a single 32-bit shift) the variable will be zero-filled.

I'm not an expert, but I was reading this article:
http://www.icce.rug.nl/docs/cplusplus/cplusplus09.html#l153

Apparently, if you overloaded the operator delete like this:
void operator delete[](void *p, size_t size);

the parameter "size" will tell you how long the array is.

However, if you want the normal delete[], you'll have to write "::delete[]"

Curiously, the C++ standard does not actually specify what value is passed as the size_t argument. In practice, it would be reasonable to expect (hope?) it would have the value passed to the corresponding invocation of operator new[](). If so, it would have to be divided by sizeof(the_type) to get the number of elements.

Since the destructors of all elements of the array will have been invoked before operator delete[]() is actually called, there is not much that can be done with the size_t argument other than pass it to a deallocation function (eg ::operator delete[]()) or print out the number of elements that were in the array being deallocated. The elements themselves will no longer exist, so no operation on them is allowed.

i figured out that i must use this kind calculations if i want to work with big nombers:
P = Cd % n
= 62^65 % 133
= 62 * 62^64 % 133
= 62 * (62^2)32 % 133
= 62 * 3844^32 % 133
= 62 * (3844 % 133)^32 % 133
= 62 * 120^32 % 133
.
.
.
= 62 * 36^16 % 133
= 62 * 99^8 % 133
= 62 * 92^4 % 133
= 62 * 85^2 % 133
= 62 * 43 % 133
= 2666 % 133
= 6

How can i write this in c++?
please help

Try to express it as a loop construct. Your logic here is, mathematically, equivalent to what I said in my previous post.

hi i'm new for c++, i tried to work with mouse pointer on my run window but i dont know how to make interrupt to do it.
thanks

Standard C++ does not allow you to work with the mouse (or interrupts). The techniques are operating system and compiler/library dependent (assuming your system has a mouse: not all do). You will need to read the documentation for your system and compiler/library to work out what you need to do.

Not even close.

You have declared myclass's length() method as taking one argument, and yourlen() calls it with two arguments.

Similarly, yourlen() is declared with no arguments, but when you call it you pass two to it. (I'll ignore the typo of calling a.youlen() rather than a.yourlen()).

If you declare a function taking n arguments, you have to pass exactly n arguments to it.

If you had tried to compile your code, your compiler would have complained bitterly.

Talking about using a sledgehammer to crack a nut. No need to use high precision integers at all.

(a^b) mod c can be evaluated using a loop, using modulo arithmetic.

The basic property you need to know is that (x*y) mod z is equal to ((x mod z)*(y mod z)) mod z). From that it is possible to compute (a^b) mod c. I'll leave the precise code as an exercise.

Firstly, your variables a, b, and c are uninitialised: their value before entering the loop could be anything.

As to your loop, it doesn't really make sense.

You only need two variables. An index, that gets a value of 1 first time through the loop, 2 the second time, 3 the third time, etc. And a sum, which initially has a value of zero, and each time through the loop has the value of index added to it.

Try using descriptive variable names, and get rid of the "#define p printf" line. If you want to use printf, then type its name in full. Brevity is all well and good, but you've gone too far and have code which is not that easy for a mere mortal to understand, and therefore difficult to get right. You're lucky the code is small.

Oh: learn how to use code tags, so you code is laid out in a readable manner in your posts.

function pointer is different from member function pointer; the one is an address, while the other is an offset. I know the WHY.. now I need the HOW :D

If you read previous posts carefully, you will realise you've been given information on HOW.

errors I get : "'mouse' : undeclared identifier" and "'mouse' : redefinition; previous definition was 'formerly unknown identifier'"

You need to place a declaration of the function in code that the compiler sees before you attempt to pass it as an argument.

Now, I moved global function before the class. It compiles, but the linker give me: "stdafx.obj : error LNK2005: "void __cdecl mouse(int,int,int,int)" (?mouse@@YAXHHHH@Z) already defined in ABC.obj"

That just means you have two source files that define (ie implement) the mouse() function. Remove one of those implementations.

Your basic problem is that you need to ensure two bits of information come together: the object to be acted on (eg a pointer to that object) and the function to act on it (eg the member function).

glutMouseFunc(MouseButton) only passes information about the function to be called. That function somehow needs to find an object to act on, and then invoke a member function on that object.

Somewhere your MouseButton() function needs to do this;

some_object->some_member_function(some_arguments);

The problem is, you're doing nothing to pass information about "some_object" (eg a pointer to an object) to that function.

The reason the compiler complains when you try to pass a non-static member function is that a member function declared with 4 arguments is (to the compiler) a function with five arguments. The fifth (hidden) argument is a pointer or reference to the object being acted on. The callback point (the code where the function passed to glutMouseFunc() is called) does not have any information about what object to act on, so can do nothing with a non-static member function.

Narue's suggestion of using a global is one option: essentially your global callback needs to access an object from somewhere so it can call a member function on that object.

- avoids dangerous recursive call of main()

In C++, recursive call of main is not allowed at all.

To answer the original question, if you must be able to execute a program that reads from standard input and writes to standard output, you need to investigate input and output redirection (ie. redirecting of stdout to a file, redirecting stdin so input is taken from a file).

Try closing outputfile before attempting to open it as an input file.

In that case, I suggest you let the "CS whiz" worry about the design and implementation of the framework. Stick to what you know: the end user (you) is critically important for defining requirements, but the end-user lacking knowledge of design and implementation is better off avoiding the temptation to make specialised design and implementation decisions (such as if/how to use inheritance).

It's say the chance of messing up due to inheritance is the least of your problems. Attempting to avoid problems due to X without even a basic understanding of how X works is a recipe for disaster.

And trying to design a framework on that basis is asking for trouble. Framework designers normally need experience in the domain (in your case DSP) in order to understand the benefits and pitfalls the framework seeks to address, design experience, and experience in programming language(s) that might be be used to implement it. As a starting point.

Look up the specification of localtime(). My recollection is that systime->tm_year would be the number of years since 1900. 2008-1900, last I checked, yielded a value of 108.

You're asking the wrong question. The compiler will attempt to invoke a copy constructor (assuming one exists) upon any attempt to create a copy of an object.

The real practical concern is whether you need to write the copy constructor yourself or let the compiler do it for you.

If you don't supply a copy constructor, the compiler will generate one by default. The compiler generated default invokes copy constructors of any base classes (in defined order) and then does a memberwise copy of any members of the class.

The general rule is that, if the compiler-generated default differs from the behaviour you need (eg managing a global resource) then you need to roll your own copy constructor.

The most common case is when a class contains a pointer, and the class uses dynamic memory allocation. The default-generated copy constructor copies the value of the pointer, so that two objects end up containing a pointer to the same thing. That makes things problematical for the destructor: when both objects are destroyed, the pointer is released twice, causing undefined behaviour. So you need to implement a copy constructor in this case to do a "deep copy".

One other rule of thumb is that any class that requires the programmer to write a copy constructor also requires the programmer to write an assignment operator.

Three possibilities I can think of offhand.

1) The way you have created the individual objects (which you haven't shown) is inconsistent with the way you're destroying them.

2) Some operation of the Text type is invalid (eg it mangles a pointer to data internally).

3) Some other code is doing an invalid pointer operation, and that is not being detected until you reach the code you've given.

When a crash occurs, any previously executed code is a potential culprit. In practice, you actually have to be very lucky to have a crash occur at the offending line.

Dragon's approach will work .... the only other obstacle is the fact that most systems allow a process to have only a small number of files open simultaneously. If you exceed that number, .....

void functijon(int **array)
{
  array[0][1] = 123;
}

The above is a 2 dimensional array of integers.

Not really. array is a (misnamed) pointer to a pointer. It is not a 2D array. However, in some circumstances (eg the code example you gave, although I won't quote that again) a pointer to pointer can be treated as if it is a 2D array.

A class declaration is anything, essentially, that tells the compiler a name is for a class. For example;

class  ClassName;

is known as a "forward declaration".

A class definition is a type of declaration that provides enough information that a compiler can create instances of the class, compute sizeof() for the class, call member functions, and access data members of the class.

A class with "prototypes of member functions" is one type of class definition.

A class "with member functions defined in the class" is another type of class definition - the only difference is that it is a class definition with inline definitions of member functions.

That's the way it is. The compiler adds a padding byte.

The reason is that each element of an array is required to have a distinct address, and the size of an array with n elements is computed as n*sizeof(element). This would not work if sizeof(element) could yield a zero value ....

The double quotes have to be around the full path names, not around the filename.

The command string you need to build is probably "del \"C:\users\robocop\desktop\a b c.txt\""

In a word, I don't understand why valarray is an outcast of STL classes (see storm in a teacup - sorry, in this thread). I don't understand why to write a program without std::vector is the same as to go out for a walk without trousers...

It's not outcast. There are arguments for and against its usage.

You were the one who started with "Please, let's stop an impetuous publicity of std::vector class as universal panacea" and then proceeded to advocate valarray.

std::vector is not perfect, but it is worthwhile for most C++ programmers to be familiar with it. It is generally applicable to a wide range of problems and, in practice, is often a suitable (as opposed to optimal) solution to many problems. When a question is asked about how to implement an array with a variable size, it is more helpful to provide a pointer to a widely applicable and commonly used approach or solution (eg std::vector) rather than a specialised one (eg std::valarray). Why? Because the person learning will be able to use std::vector for more things, and learn for themselves. Whereas that person will probably run into limitations of valarray (eg types it cannot hold) early, and then have to learn a more general solution.

A basic approach to helping people learn is to encourage building knowledge and experience that is widely applicable and, once the person has learnt those things, moving to more specialised approaches. In the case of C++ containers, that …

My "Makefile" contains this:

EngineMain : EngineMain.o Engine.o
                   (tab)gcc -o EngineMain.o Engine.o
         EngineMain.o : EngineMain.cpp Engine.h
                   (tab)gcc -c -g EngineMain.cpp
         Engine.o : Engine.cpp Engine.h
                   (tab)gcc -c -g Engine.cpp

The rule above for EngineMain will not function as intended. It should probably be;

EngineMain : EngineMain.o Engine.o
                   (tab)gcc -o EngineMain EngineMain.o Engine.o

oh and one small point makefiles don't end in mk or mak. They usaullyhave no ending and are almost exclusively called Makefile.

Several make utilities accept .mk or .mak extensions (eg Microsoft's nmake, Borland's make utility).

The GNU make utility looks for only these file names in order "GNUmakefile" ,"makefile","Makefile"...... but for the most part never use the first one.... there are other make utilities and they only look for the latter two.

Most "make" programs support a means of specifying the filename (eg most unix variants of make, including gnu make, also accept a "-f <filename>" option).