and I noticed that almost everyone's stuff is different than this, is there something wrong with my methodology?
And can anyone provide good links for tutorials on working with graphics?
And can anyone provide good links for tutorials on working with graphics?
Google SDL or OpenGL.
Regardless, your graphic work is not the issue. Variable names like "aa" and "bb" are useless and not readable, the maintainability of this code is very low.
Some thing's I'd suggest you implement in this code before going forward so you have a better understanding of good C++ practices.
The gotos can be changed to while and for loops. You should consider splitting the code into functions to make the program easier to read and easier to reuse code.
@Peter87 care to elaborate on what bad things you have heard about it? I know numerous organisations that use it and have their software installed in high risk environments like hospitals.
Most common complaint I have heard is that they ban the use of exceptions. Because of that they have a rule that says "avoid doing complex initialization in constructors" because "there is no easy way for constructors to signal errors, short of using exceptions (which are forbidden).".
I also read "Use streams only for logging". The motivation for this and for many other things do not make sense to most people. Streams are a very useful and easy to use. I don't see why people should not use them.
This guide probably works good for what Google is doing but it's not a general guide that makes the best use of C++ and everyone should use.
Their rationale for not using exceptions is quite sound. But you can always take their guide as a "guide" and make your own exceptions (no pun intended).
The same is with their streams. Reading their style guide they give rationale for pretty much every decision they make.
In my original response I'm provided the OP with an example style guide they can use to improve their C++ readability. Whether they choose to use Google or another is up to them.
Their rationale for not using exceptions is quite sound.
Can you explain it? That linked page doesn't really get into the rationale behind it.
EDIT: nm just saw that you can expand each item.
EDIT 2:
I agree with their standpoint here:
Google wrote:
On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code.
So yeah, working exceptions in as an afterthought is not a smart move. But working them in from the start is.
Therefore the general guideline of "don't use exceptions" is bogus. What they're really saying is "don't use exceptions in a program which doesn't already use exceptions".
EDIT 3:
Peter87 wrote:
This guide probably works good for what Google is doing but it's not a general guide that makes the best use of C++ and everyone should use.
I agree completely.
Arbitrarily constraining yourself to <insert random company here>'s guidelines is pointless.
> Their rationale for not using exceptions is quite sound.
Yeah, badly written legacy code does provide a sound rationale.
Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. .... Things would probably be different if we had to do it all over again from scratch.
tbh I think arguing 1 companies coding style is a waste of time. As I said, I provided it as an example coding standard.
Coding standards are like religions, everyone has their own opinion and thinks theirs is the holy one.
I also do not consider the lack of exceptions to be bad written legacy code. There are many languages that do not provide exceptions that have written very successful large projects with very nice clean code. It's really a horses for courses scenario.
> tbh I think arguing 1 companies coding style is a waste of time.
Particularly when they themselves do not adhere to it strictly.
Not using exceptions implies that one has to use new( std::nothrow ) or malloc() followed by placement new to create objects with dynamic storage duration, standard containers or strings can't be used without first writing a custom (non-throwing) allocator, std::function<> can never be used without a preceding check for the existence of a target, any use of regular expressions (std::regex) and other portions of the standard library is forbidden and so on.
While "We do not throw exceptions from our code." would have been merely questionable, "We do not use C++ exceptions." is asinine.
> I also do not consider the lack of exceptions to be bad written legacy code.
Legacy or not, C++ code lacking exception awareness is abominable.
While C code lacking it is not. There is a not so subtle distinction between the two.
I'm tired right now, so I'll quickly slap together a list of some things you should consider, and maybe I'll edit this later on and actually be helpful :
•Use classes.
•Do not use goto. Use loops instead.
•Do not use calls to system().
•Do not use usingnamespace std;. Especially in global scope.
If it's absolutely necessary for you to use it (which it never is), use it in the most localized scope.
•Avoid mixing std::cout with the '\n' character. For the sake of flushing and consistency you should be using std::endl;.
Avoid mixing std::cout with the '\n' character. For the sake of flushing and consistency you should be using std::endl;.
Ehhhhh.
You only have to flush when you have to flush. Flushing all the time isn't necessarily benefitial... especially if the stream is a file (fstream). Needless flushing can really hurt performance.
Though for small console programs that don't require high speeds and/or don't have much output... using endl all the time is fine.