Add "C++ Extended Roadmap" to community roadmaps list

[Steindvart]

What is the title of the roadmap you are submitting?

C++ Extended Roadmap

Roadmap Link

Link: https://roadmap.sh/r/c-extended

Previous discussion:

• 7604

[fellalli]

Nice, just a few things that came to my mind:

1. The Junior/Medium/Senior/Optional evaluation is a bit inscrutable, in my opinion. Why is make Junior and cmake Medium? Why are Input validation and Formatting (there is also a typo in the roadmap) Medium? This could lead to misunderstandings, such as, "I don’t need to learn xy because I’m a Junior developer."
2. Why is only Static type cast mentioned?
3. Mentioning standards might be a good idea (as long as we keep them up to date).

[Steindvart]

@fellalli

Nice, just a few things that came to my mind:

1. The Junior/Medium/Senior/Optional evaluation is a bit inscrutable, in my opinion. Why is make Junior and cmake Medium? Why are Input validation and Formatting (there is also a typo in the roadmap) Medium? This could lead to misunderstandings, such as, "I don’t need to learn xy because I’m a Junior developer."
2. Why is only Static type cast mentioned?
3. Mentioning standards might be a good idea (as long as we keep them up to date).

Thanks for you feedback! ❤️

---

1. In general, all this division into "Junior, Middle, Senior, etc ..." is very conditional and ambiguous. I have never come across the fact that, for example, a Junior vacancy can have requirements as for a mature Middle/Middle+ and vice versa, for a Middle vacancy the requirements are as if for a Junior vacancy.

Therefore, in any case, there will be disputes about "This topic refers to Junior, not Middle."

The purpose of this division is to give an approximate estimate of the complexity of the topics combined with their importance and prevalence in C++ development (of course, regarding my opinion and experience as the author of the map.). I'm thinking about making some kind of disclaimer on this issue.

2. Because all other methods of type conversion will be considered after of the section on OOP. I consider it superfluous to mention them in the section about the "basic syntax".

3. Yes, there are plans to develop a section with a brief overview of the main innovations in a particular standard.

[dansholds]

This is a beautiful roadmap @Steindvart, good job.

I agree with the points that our wonderful community moderator @fellalli mentioned so once we come to an agreement on those, I'll look at getting it added 🤙🏻

[Steindvart]

@dansholds

Thank you for the kind words! ❤️

I answered above on these points. Of the changes that I have applied now, I have corrected a typo in the word "Formatting".

The map will develop further as soon as I have free time from work. All remaining points about templates, exceptions, STL, c++ standards, smart pointers and so on will be in the nearest future. I already have a draft of this in text form.

What has already been added - I don't have any ideas yet what else could be improved. But I think if we can make the map publicly available, it will give us a lot of good ideas for improvement.

So that this map can become an official roadmap of C++ on the site in the future. I hope :)

[fellalli]

@fellalli

Nice, just a few things that came to my mind:

1. The Junior/Medium/Senior/Optional evaluation is a bit inscrutable, in my opinion. Why is make Junior and cmake Medium? Why are Input validation and Formatting (there is also a typo in the roadmap) Medium? This could lead to misunderstandings, such as, "I don’t need to learn xy because I’m a Junior developer."
2. Why is only Static type cast mentioned?
3. Mentioning standards might be a good idea (as long as we keep them up to date).

Thanks for you feedback! ❤️

1. In general, all this division into "Junior, Middle, Senior, etc ..." is very conditional and ambiguous. I have never come across the fact that, for example, a Junior vacancy can have requirements as for a mature Middle/Middle+ and vice versa, for a Middle vacancy the requirements are as if for a Junior vacancy.

Therefore, in any case, there will be disputes about "This topic refers to Junior, not Middle."

The purpose of this division is to give an approximate estimate of the complexity of the topics combined with their importance and prevalence in C++ development (of course, regarding my opinion and experience as the author of the map.). I'm thinking about making some kind of disclaimer on this issue.

2. Because all other methods of type conversion will be considered after of the section on OOP. I consider it superfluous to mention them in the section about the "basic syntax".
3. Yes, there are plans to develop a section with a brief overview of the main innovations in a particular standard.

Thanks for the clarifications! I think it would be clearer to categorize the topics into Beginner/Intermediate/Advanced rather than Junior/Middle/Senior.

While I understand your point about moving dynamic_cast/reinterpret_cast/const_cast out of the basic syntax section, I still believe it would be clearer and less confusing if all type casting keywords were grouped together.

It’s great to hear that you already have plans for more topics! 🚀 Thanks^^

[Steindvart]

@fellalli

While I understand your point about moving dynamic_cast/reinterpret_cast/const_cast out of the basic syntax section, I still believe it would be clearer and less confusing if all type casting keywords were grouped together.

I agree that this is formally the "basic syntax" and these blocks can be placed in this section. But I see the logical connection and context as a much more important thing. dynamic_cast only makes sense when it comes to polymorphic classes. const_cast most often makes sense when working with constant class members in class methods. In general, they are more related to OOP than to the "basic syntax" as such.

I'm afraid if I specify these castes in the "basic syntax", then such a structure will not show the context of the application of these casts. But context - is the key to their understanding.

---

Little story of my study experience with this topics

Honestly, when I studied these topics for the first time and met the description of dynamic_cast, const_cast next to the description of static_cast, I did not understand at all what it was for and why. Because I only knew how to create ordinary functions, simple classes (without inheritance) and the like. Without knowledge of polymorphism and other things.

And when I started studying polymorphism, I already forgot about dynamic_cast, which was described "in the first chapters, along with the description of static_cast".

---

If you judge it that way, then any keyword, including class, mutable, volatilerefer to the "basic syntax". Which is kind of true, but it's better to put it all in a separate context. In the same way, I judge about the topic with casts.

static_castis simple and clear, it can be used almost everywhere. reinterpret_castis also quite simple and can be used everywhere (derived from c-cast). Here it can be specified in the same group as static_cast.

But dynamic_cast and const_cast only make sense in the cases that I described above. Therefore, I see more reasons to place them closer to the blocks with which they are directly related than the formal division into "basic"/"non-basic syntax" - because everything can be considered "basic syntax" :)

[fellalli]

Thank you for the further explanation! My suggestion wasn’t necessarily to place them in the basic syntax section because they’re basic syntax, but because grouping them together would make sense, as they’re all related to type casting.

You made a great point, though! So, const_cast would go near Constants and dynamic_cast near Polymorphism? I’d be happy with that too!