Custom error message for stack overflow in C++

[HappySkeptic]

I've looked at your code, and you are making heavy use of the stack.  The default stack size is 1 MB on Visual Studio, but you can change that with a compiler flag.

It is possible you have simply run out of stack.

Experienced programmers learn to use very little stack space, and use the heap instead.  That requires making use of things like shared_ptr<> rather than copying large objects into new variables (it also helps with performance).

I notice that every TreeNode generates some data which looks like it is the same for all instances.  That is wasteful - it should be static and initialized statically.  That also causes much less data to be copied.

If you increase the stack, still get the error, and get an even deeper stacktrace on the same lines of code, then you know you have an infinite loop.  Just walk the stacktrace and look at the lines and data, and fix it.  You think you don't have an infinite loop (something I haven't verified), so just use the larger stack.  But, you really shouldn't be using so much stack space.

Set Stack Size

I don't know how to change the compile parameters directly from CMake, but it is easy to temporarily make a change in the generated VS project file.

[zebo-the-fat]

Try hitting it with a hammer.

To hit what with a hammer? The problem occurs on whatever computer my program, if compiled using CLANG without optimization or Visual Studio C++, is run on.

---

Out of cheese error?

I am not sure what you mean.

I's a Diskworld thing

[FlatAssembler]

That requires making use of things like shared_ptr<> rather than copying large objects into new variables (it also helps with performance).

I notice that every TreeNode generates some data which looks like it is the same for all instances.  That is wasteful - it should be static and initialized statically.  That also causes much less data to be copied.

Damned pointers, I was never good with them.

I have tried using static fields, but the linker keeps complaining then. I do not know enough C++ to figure out why.

Maybe you can fork me on GitHub to fix those things?

[HappySkeptic]

That requires making use of things like shared_ptr<> rather than copying large objects into new variables (it also helps with performance).

I notice that every TreeNode generates some data which looks like it is the same for all instances.  That is wasteful - it should be static and initialized statically.  That also causes much less data to be copied.

Damned pointers, I was never good with them.

I have tried using static fields, but the linker keeps complaining then. I do not know enough C++ to figure out why.

Maybe you can fork me on GitHub to fix those things?

I don't know if I have the time to do a fork and fix them.  I might, but, increasing the stack size is probably your solution.

The heap is literally 1000 times the size of the default stack (or more).  Using bare pointers is just a bad idea in C++ 11 or higher.  Always use shared_ptr<> to hold the pointer, and new the object from the heap.

The shared_ptr<> can be thought of as a reference object - don't think of it as a pointer any more (although you dereference it with a "->" post-fix symbol or "*" prefix symbol just like a pointer).  When the last shared_ptr<> reference to an object disappears, the object gets deleted.

Code:

shared_ptr<TreeNode> node = new TreeNode();

Now, node is just an object that get copied into methods, returned from methods, or held in other objects - but the copies of it copy the reference, not the TreeNode data.  The data is on the heap, not the stack.  Only the shared_ptr<> reference object is on the stack.

Here is an example of a performance (and stack) problem.

Code:

AssemblyCode convertToInteger32(const TreeNode node, const CompilationContext context)

A correct method would be

Code:

AssemblyCode convertToInteger32(const TreeNode & node, const CompilationContext & context)

The difference is that the node and context are now passed as C++ references.  Basically, a C++ reference is a hidden pointer.  You still treat node and context just like before, no "->" needs to be added, but under the hood, the objects are being passed by an internal pointer.

Your way, the entire context and node are copied, and the copies reside on the stack until the method returns.  That is extremely wasteful. Doing this one change everywhere may be enough to fix your blow-up, though you should increase your stack size as well.

The other stack and performance issue, is that AssemblyCode is being returned as a copy.  That isn't terrible, but it is wasteful, and the variable it is being assigned to in your compile() code is on the stack.

Instead, a better method would be

Code:

shared_ptr<AssemblyCode> convertToInteger32(const TreeNode & node, const CompilationContext & context)

Of course, to use this, you would have to "new" the AssemblyCode from within the method, and use it with "->" dereference operators instead of "." .  shared_ptr<> is just another std:: class (i.e. from the standard template library).

Now, if you went all the way with shared_ptr<>, you would always have context and node be shared_ptr<> as well, throughout your code.  Then, you would pass those in:

Code:

shared_ptr<AssemblyCode> convertToInteger32(const shared_ptr<TreeNode> & node, const shared_ptr<CompilationContext> & context)

Here, I wouldn't get much performance penalty by changing "& node" to just "node", as copying a shared_ptr<> is relatively fast (a few bytes, plus incrementing an atomic_int in a thread-safe way).  However, once you get into using shared_ptr<> everywhere, a lot of code will need changing.

[FlatAssembler]

I don't know if I have the time to do a fork and fix them.

Nevertheless, thank you for writing all that information, it will probably help.
And what do you think about my project in general? Is it interesting?

I might, but, increasing the stack size is probably your solution.

So, you think I should add in the README that CLANG on Windows and Visual Studio C++, but not GCC, provide a too small stack by default to compile the Analog Clock program?

Of course, to use this, you would have to "new" the AssemblyCode from within the method, and use it with "->" dereference operators instead of "." .

Is it important whether I create the

Code:

shared_ptr<AssemblyCode> assemblyCode=new AssemblyCode();

inside the method, or can I write

Code:

AssemblyCode *assemblyCode=new AssemblyCode();

and only later

Code:

return assemblyCode

for the raw pointer to be automatically converted to the smart pointer upon returning? I have no idea how it works.

[HappySkeptic]

Is it important whether I create the

Code:

shared_ptr<AssemblyCode> assemblyCode=new AssemblyCode();

inside the method, or can I write

Code:

AssemblyCode *assemblyCode=new AssemblyCode();

and only later

Code:

return assemblyCode

for the raw pointer to be automatically converted to the smart pointer upon returning? I have no idea how it works.

Yes, this will work (if the calling code assigns the function return value to a smart pointer), but it is bad form to mix smart pointers and raw pointers to the same object in a program.  What if one piece of code holds onto the raw pointer, and another the smart pointer?  The raw pointer will point to a dead object at some point, once the last smart pointer to the object disappears.  By enforcing the return object to be a shared_ptr<>, you are making the contract that everyone should use the smart pointer only (yes, they can still pull out the raw pointer, but the user would know that is bad).

Using a smart pointer is just as easy as using a real pointer.  The * (prefix) and -> (postfix) dereference operators are the same.

Part of your problem may be solved by using the C++ references in parameter passing, as I posted earlier.  It is almost always a performance mistake to pass class objects (as opposed to simple numeric types or pointers) by copy instead of by C++ reference.

---

To further expand on the idea to "not mix smart pointers and regular pointers to the same object", consider this scenario:

Code:

shared_ptr<AssemblyCode> convertToInteger32(const TreeNode & node, const CompilationContext & context);

// assign the return code to the smart pointer.  There is now only one smart-pointer "myCode" that is keeping the returned data alive.
shared_ptr<AssemblyCode> myCode = convertToInteger32(node, context);
// We can use the underlying object using normal de-reference.
cout << *myCode;

This is perfectly fine, but this should blow up (it may not, but this dereferences deleted memory).

Code:

shared_ptr<AssemblyCode> convertToInteger32(const TreeNode & node, const CompilationContext & context);

// I don't like smart pointers, so just grab the raw pointer.
AssemblyCode * myCode = &(*convertToInteger32(node, context));
// Oops, because my smart pointer return-code just got deleted from the stack, myCode points to a deleted object (as there are no more smart pointers pointing to it)
cout << *myCode;

[Abaddon_ire]

Flat is seeking those gullible to do his homework again.

Nope.

[FlatAssembler]

Flat is seeking those gullible to do his homework again.

Nope.

That is not my homework, it is my hobby project. We have not yet learned anything about compiler theory at the university. And, actually, I will probably drop out from the university. I feel like I can learn more useful stuff about computers on Internet forums than at the university.

[HappySkeptic]

Flat is seeking those gullible to do his homework again.

Nope.

That is not my homework, it is my hobby project. We have not yet learned anything about compiler theory at the university. And, actually, I will probably drop out from the university. I feel like I can learn more useful stuff about computers on Internet forums than at the university.

But will anyone hire you?

Most successful graduates "also" do hobby projects.

You have talent, but you need more knowledge (and you need to be able to prove you have knowledge).  Right now you are "almost" at a junior programmer level.

If you quit because you just prefer to do your own hobby stuff, why would anyone hire you? You aren't going to be doing your own hobby work in a company. They will tell you what they want done, and you have to figure out the design and solution (or work as part of the solution, if you are working under a senior developer)

[FlatAssembler]

That is not my homework, it is my hobby project. We have not yet learned anything about compiler theory at the university. And, actually, I will probably drop out from the university. I feel like I can learn more useful stuff about computers on Internet forums than at the university.

But will anyone hire you?

Most successful graduates "also" do hobby projects.

You have talent, but you need more knowledge (and you need to be able to prove you have knowledge).  Right now you are "almost" at a junior programmer level.

If you quit because you just prefer to do your own hobby stuff, why would anyone hire you?  You aren't going to be doing your own hobby work in a company.  They will tell you what they want done, and you have to figure out the design and solution (or work as part of the solution, if you are working under a senior developer)

Well, I think I am competent enough to have a job. And even if I am not, I don't think university will make me competent. They did not teach me how to change a lightbulb in our electrical engineering classes, so they also will not teach me useful things in our programming classes.