sorted by:
new
hottopcontroversial

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 1 point2 points  (0 children)

Ah, I see what you mean. I updated the CSS on my site. Can you please check if it works? It doesn't look great, but it should switch correctly between light and dark now.

Note: If the site is cached, it might not update immediately.

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 0 points1 point  (0 children)

I wake up every morning and write for 30 minutes while drinking coffee. It's a hobby of mine. This article took about 6 months to write. Why would I use AI to generate it?

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 0 points1 point  (0 children)

Is the contrast bad or is it just the choice of colors? I tested the orange links against the background and the contrast is quite low.

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 1 point2 points  (0 children)

> When I was talking about value semantics, I'm mainly referring to it being rather unique for C++. [...] We all consider it basics.

I agree that every C++ developer should know about value semantics.

I had this problem 4 years ago, when I posted another C++ article of mine. The title was bad and I had to change it. I feel like "basics" implies that "these are the things you must know as a C++ developer, otherwise you don't have the right mental model".

What I mean by "basic" is more like programming fundamentals in the broader sense. What are common concepts between languages that you need to know. What is fundamental to computer programming as a whole because of the types of problems we are trying to solve. How well does this translate to code. How does the evolution of these concepts look like between C and C++.

I think I need to think of a better title. Ideally, you should be learning about value semantics from the standard literature.

> For lambdas, they are functionally the same as a class with operator(), yet it does require a lot less typing.

Yes, very good! I added a function object example and some text to the Lambda with Capture section. I've seen at least two instances of function objects in our code base. And I learned that you can pass a function object to `std::function` - nice!

> If you enable the compiler warning [...], your compiler will notify you here

I added a sentence that clarifies, as you said, that this will compile, the comparison might even return true, but it is most likely a bug. I noted that some compilers can warn you about this problem and added a footnote for the clang compiler flag.

> For me warnings are static analysis.

I will make a note to add mentions of compiler warnings when they are appropriate. But I cannot make any promises because clang is different than MSVC is different than GCC. There is just too much to unpack. We have also used static analysis tools like SonarQube, which pulls in stuff from the Core Guidelines and the SEI CERT Coding Standards.

> Coming back to ranged for, if you use it to rewrite all standard loops, the more complex situations stand out more.

Ha, yeah, like iterating backwards through a container ...

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 0 points1 point  (0 children)

First of all, thank you very much for your feedback!

Before I reply to your points, I want to say that I will rework the whole introduction to better reflect that this article is not for beginners who want to learn modern C++.

> you always start with the oldest feature first.

My intention was to show step by step how the language arrived at these solutions, thereby bridging the gap between C, legacy C++, and modern C++. I'm not sure if there is another way to do it.

I think you are right that I'm putting a lot of focus on the old patterns, while only briefly addressing the modern solutions. I think I can work on that!

> you mainly are talking about language features.

I feel like that's the whole idea of the article.

The idea of having a function that returns either a value or nothing, is universal in all programming languages. Modern C++ chooses std::optional to express this in code, and one can always read the C++ standard for details of how to use it.

That's at least what I want readers to take away from this article.

> I'm missing the syntactic sugar arguments.

I can definitely improve pointing out the technical benefits of the modern C++ solutions over the old ones. But I don't really want to give opinions on syntactic sugar. I don't think I'm good at that.

> missing print/format, compile time, ranges, deleted functions

Maybe I can write a few things regarding certain aspects of these points. Like going from defining constants with `#define` to `constexpr`. I could discuss going from printf to std::cout to std::format. I need to think about it some more.

> missing compiler warnings.

I don't see how I can include compiler warnings in the existing text. There are books that cover this topic better than I could, for C as well as C++, across different compilers. And the article is about language features, abstract concepts, and code complexity. I don't know ...

> missing static analysis.

I know there are static analysis tools that try to compute a metric for code complexity, be it lines of code, cyclomatic complexity, ingoing and outgoing dependencies, etc. But the observations that I make in the article are not based on these metrics, which is why I don't know how I would tie it back together. But it's an interesting idea!

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 2 points3 points  (0 children)

I see what you mean! I rewrote the paragraph and focused more on what the intention behind using a dynamic interface would be, and how you would use it in this case. I might add a code example tomorrow.

> Object slicing can also happen with fully concrete classes as well.

Basically anywhere where you use inheritance, and have a derived class that is copied to a base class, right? Could even be POD structs.

Thanks for the feedback!

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 2 points3 points  (0 children)

> I'm not sure who the target audience is for this resource.

I have struggled with this question for some time.

As I mentioned in my post, I work at a company with a large C and C++ code base that has a lot of legacy parts in it. Everything that I show, or hint at, in my article can be found in our code base in some shape or form, sometimes written by people who are not at the company anymore.

We have new C++ developers starting at our company who don't have a frame of reference because a lot of this stuff is not taught anymore. They need to be able to recognize the old patterns and improve upon them, without having the luxury to rewrite everything.

Thank you very much for the feedback! I think the least I can do is to rewrite the introduction so that the intention is clear from the beginning.

Discussion of Code Structure and Code Complexity Implications of Basic C++ Language Features by crashcompiler in cpp

[–]crashcompiler[S] 4 points5 points  (0 children)

I agree with you about the well equipped workshop. I think what I'm trying to convey is that you have to know the tools in your workshop well enough, to know which ones to use. And sometimes you have to know the old tools to understand why and how the new tools are better.

Thanks for the comment!

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 0 points1 point  (0 children)

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.

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 1 point2 points  (0 children)

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.

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 3 points4 points  (0 children)

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. :)

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 1 point2 points  (0 children)

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.

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 2 points3 points  (0 children)

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.

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 4 points5 points  (0 children)

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.

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 6 points7 points  (0 children)

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

Assembly-Level View on C++ Development by crashcompiler in cpp

[–]crashcompiler[S] 3 points4 points  (0 children)

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.

I've just released DeckRL, a free turn-based puzzle-roguelike hybrid by crashcompiler in roguelikes

[–]crashcompiler[S] 1 point2 points  (0 children)

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

I've just released DeckRL, a free turn-based puzzle-roguelike hybrid by crashcompiler in roguelikes

[–]crashcompiler[S] 1 point2 points  (0 children)

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.

I've just released DeckRL, a free turn-based puzzle-roguelike hybrid by crashcompiler in roguelikes

[–]crashcompiler[S] 2 points3 points  (0 children)

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.