How to not become overwhelmed....

Started by
26 comments, last by Matt-D 11 years, 9 months ago

Alright, you knew about the advice and are beginning to realize the reasoning behind.
Then it's clear what to do now...
A beginner shouldn't need 5 books about a f...... language - they should be about general software development, architecture, best practices, algorithms, patterns, etc.
Languages are interchangable - basic knowledge is not. And you will hardly have enough time to get it all.
There is absolutely no reason to start with C++ , beyond "it's cool, it's what the pros use".
You can still come back to it in a few years.


I was going to say something similar. Starting with C++ if you are even a little bit worried you will become overwhelmed is pretty backwards. C++ starts overwhelming and plateaus at a slightly higher level than most languages recommended for beginners.

Languages are generally easier to learn than theory, so it's generally easier to learn the theory with an easy language and then use your established theory to understand harder languages.

I also never understood starting with C++ as it's not that beneficial for a beginner in any metric. You could probably write more performant code in a managed language for quite a while before you start seeing the advantages of C++. C++ isn't that fun to learn comparatively either. It takes a lot longer to program in C++ (just actual typing time/compiling time) compared to a lot of other languages. In order to start seeing interesting results you probably need to learn another API on top of C++.

In C# or Java for example, you can write Hello World, change a few lines and have Hello World in a window instead of on the console, change a few lines and have Hello World with a functioning button, change a few lines and have that with a triggered animation, and then you can pretty much jump into your first game. You could probably reasonably do that inside a day, and even with that relatively low starting point you'd probably have a lot more fun learning C++ after just one day of investment in not-C++.
Advertisement
Thanks for the comments, advice and anecdotes so far guys. I really appreciate you taking your time.

Regarding the few posts focusing on the language choice, this decision did not come lightly and was primarily based on the fact i had used Javascript a little previously, and C++ felt very similar when i was looking at the syntax.

I really dont want to drag this thread into a "switch to X its easier, then you wouldnt be so overwhelmed ffs" thread. So please, as correct as the statement may be, can we work with these parameters.

Please dont mistake my stubborness/ignorance as arrogance, im enjoying c++ and starting to understand the basics so will be sticking with that learning path unless i hit something beyond me.

My plea for people to share their experiences is not restricted to people following the path i have chosen. Im mearly looking for some advice on the steps others took to go from the level i am, to the level they are, so that i can glean some encouragement and gage the amount of work.

Thanks again. >.<
There is something that I call bad features in C++. They provide traps for newcomers and complicate everything. Many workshops provide a list of banned features but not all follow them (they're more like guidelines anyway).

I'll throw my very opinionated suggestions, which I think might steer you around some common pitfalls:

- Learn to use the debugger, and put plenty of asserts for it to break to.
- Use the C++ variants of C functions where possible.
- Avoid unnesessary inheritance. Learn early to use composition for code sharing.
- Avoid using multiple inheritance. Avoid even learning about it until you really have to.
- Avoid virtual inheritance.
- Free functions are part of the public interface (and are in many cases superior alternative than member function) for a class. Not everything needs to go in a class. Avoid static member functions. Avoid static data members.


- Avoid virtual inheritance.


I was with you until this one.

[quote name='Codarki' timestamp='1342017608' post='4958040']
- Avoid virtual inheritance.


I was with you until this one.
[/quote]

This however is a good example of where C++ kinda sucks. If you are going to make sure class inheritable, make it virtual and MAKE SURE you mark the destructor as virtual.

I almost think C++ should have made inheriting a class with a non virtual destructor illegal, I can think of absolutely no reason not to.

For example ( this is a pop quiz with a big hint above ;) ).


Why is this so dangerous?

class SpecialString: public std::string {}

Looks prety innocent and logical doesn't it? If you have no idea why the above code is bad ( and it is bad! ), read Exceptional C++, as that is where the example was lifted from.
For what it's worth, I agree with Codarki on virtual inheritance. Seraph: Why would you need it if you don't use multiple inheritance?

A base class that doesn't have a virtual destructor is a problem only if you inherit publicly from it, I think. I am not sure, because non-public inheritance is another one of the things I stay away from in my C++ code.

For what it's worth, I agree with Codarki on virtual inheritance. Seraph: Why would you need it if you don't use multiple inheritance?


Interfaces.

[quote name='alvaro' timestamp='1342021842' post='4958072']
For what it's worth, I agree with Codarki on virtual inheritance. Seraph: Why would you need it if you don't use multiple inheritance?


Interfaces.
[/quote]

[table][tr][td]officeassistant-clipit.gif[/td][td]It looks like you're trying to use OOP for (dynamic/run-time) polymorphism.
However, there might be other ways...[/td][/tr][/table]


Sure, you can, nothing wrong with that, sometimes it's even the best or the only solution (esp. in more OOP-focused languages, like C# or Java).
At the same time, however, it's not always the case -- I have several projects with plenty of genericity, reusability and (static/compile-time) polymorphism without using the "virtual" keyword even once (neither for virtual member functions nor for virtual inheritance). Hints: templates, CRTP.*

* -- restrictions may apply :-) // so, no, I'm not claiming they're perfect either, just an alternative solution to consider that may work better in some cases;

This topic is closed to new replies.

Advertisement