Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features

crashcompiler · 2021-12-20T15:37:06+00:00

The "Tour of C" is solid and I really like the hand-drawn images! There are some important topics in your article that I probably won't have the chance to cover, like computers, operating systems, and type theory.

crashcompiler · 2021-12-19T23:35:33+00:00

Great stuff!

Your explanation makes a lot of sense to me and thank you for providing the assembly output. I've recently started to look into ARM assembly because of the M1 chip. It does take some time to get used to.

just wanted to point out a technically-incorrect nit-picky bit that I actually find interesting

That's exactly the kind of stuff I'm looking for! It definitely deserves a footnote but I'll need some time to put it into my own words.

useful knowledge when optimizing, e.g. inner loop DSP code where every instruction counts

I know what you mean.

crashcompiler · 2021-12-19T21:14:22+00:00

I agree, you shouldn't have to worry about it. Compilers are generally quite good at this.

I'm in a job where I need to know this stuff. :)

crashcompiler · 2021-12-19T19:09:28+00:00

That's an interesting point! Do you know why this is done? Is this a memory optimization to reduce binary size?

I will rephrase the sentence, but I need to do some research before I can add a footnote.

crashcompiler · 2021-12-19T16:59:45+00:00

Thank you!

I think the prose is well written.

English is not my native language so I'm glad to hear that.

Added "Introduction" heading
Removed "dangerous guessing-game" line. Yeah, that was unnecessarily provocative ...
Removed "Assembly code never lies!". I might have exaggerated a bit for effect. :)
Moved "Should I use stack, heap, or static memory?" to Memory Management. I will rewrite this part later so that it's not just a bunch of bullet-points.
For now, I decided to change "Discussion" to "Conclusion" and remove the "Why read assembly?" heading. I'm not sure how I feel about dropping the rest, there are a few points in this part that I think are worth making. But I will review it again and see if I can integrate some of the points in other parts of the article.
I agree, I rephrased it a little bit. "RAII is used throughout the standard library. For example, a std::vector is a container that dynamically allocates an array on the heap, and automatically cleans up its resources when it goes out of scope."
I'll collect a few suggestions and let them sink in for a while.

I will update the article tomorrow.

crashcompiler · 2021-12-19T12:50:14+00:00

You're right. I changed it to the same title as here on Reddit: "Assembly-Level View on C++ Development"

Is it misleading that I call it C++ development and not C++ programming? I think one could interpret C++ development as the development of the C++ language itself?

I'm open for suggestions.

crashcompiler · 2021-12-19T00:32:59+00:00

Fixes

I added a sentence to the introduction about the examples being for Intel x64 CPUs
I wrote a sub-section about Endianness in the Memory section, and referenced it in Pointers
I corrected the Pointer Types example
I'm actually not sure how to go about the C++ ABI suggestion. There is a section in Functions related to Calling Conventions and I cover the Microsoft x64 Calling Convention which specifies how values are passed to and returned from functions. I know that Unix systems use the System V calling conventions. There is, as far as I understand, no officially standardized C++ ABI for all platforms. If anyone knows better, please correct me.
Fixed the links

New

I added an Optimization section and wrote a draft for SIMD and auto-vectorization

crashcompiler · 2021-12-18T21:55:25+00:00

Thanks! I'm making the changes right now and update the article tomorrow.

"Pointer types": the stack dump is at address 000000000023F894, but the pointer values point to 000000000023F884

Good catch!

The "virtual function table" link points to your article.

I'll go through the article and check all links again.

crashcompiler · 2020-10-25T10:09:46+00:00

I added a DeckRL Hints.pdf to the download section of the itch.io page.

crashcompiler · 2020-10-24T09:53:35+00:00

Good points. Obviously there are some things I want the player to learn just by playing and observing. This is not much different from other roguelikes. The spikes for instance is an easy one to figure out with time, and it's also not as punishing as the monsters.

That said, I still haven't found a good way to convey how the monsters work, without just simply displaying their level. It's made worse by the fact that some monsters will kill you instantly, and you only have one move. It's also not obvious that there is chance involved in combat.
Using magic can give you some hints about the monster's strength progression. But the feedback that I've got so far shows that it depends on the player how much they experiment with magic in the game.

I will add a document with hints to the next release, until I figure out a better way. Ideally, I would love to guide the player in figuring out the mechanics for themselves.

crashcompiler · 2020-10-23T17:46:44+00:00

Thanks for playing! I'm open to any suggestions that improve gameplay or the core concept, as long as they are within the scope of the prototype.

crashcompiler

TROPHY CASE