So I decided to write a c++ parser, lots of string manipulation, plenty of substr's and find_first_of \n \t \f et al.

I was up to about 500 lines of code, with quite a few functions such as trim and various splitting functions, tailored for certain situations such as if you are parsing pre-processor directives you can have whitespace after the # to the directives keyword, such as '#323232include', all this has to be taken care of, so many little situations like this that the code just bloats up and this is just for comments and macro and only just checking that a PP directive is found and is valid never mind actually checking if the statement itself is valid.

Then I decide to load up all the gcc source and look at the lexical and parser sections and apart from the horrendous notation in gcc, you can see right away that it is in a different ballpark, the code and comments show this, making my code look like script kiddies JavaScript.

I also load up the NASM source, which is nicely written code, but, and even though it is a full compiler/assembler and the parser parts are only a fraction overall, it's obvious that I am a long way away from the understanding and coding efficiency that these guys have. I also see that Boost has a lexical analyzer and parser, part of their Spirit library, which again, after reading through a bit of it seems so far from what I am doing, they have a complete academic understanding and design of parsing, tokenizing and validation of source code.

Quite demoralizing I must say, I would make a good scripter I think, but I do wonder if I am cut out for this, and if I will ever progress to the levels of this compiler source I am talking about. Is it mainly practise and hard work or are some people just born to code at these high levels?

The way you become 'good' is by:

1. Coming up with a 'good design' you think will work.
2. implement the code.
3. Ship the result
4. Spend the next 6 months fixing all the terrible flaws in your 'good design'

No one is born a software engineer, it's just something you get better at with experience....

If you want to go into language parsers in a big way, the "dragon" book will be a great asset.

http://dragonbook.stanford.edu/lecture-notes.html

Also, perhaps you might want to have a look at a slightly simpler implementation of a C (not C++) parser.

http://code.google.com/p/picoc/source/browse/trunk/parse.c

More than likely not as robust but since you are probably a games developer and want to make games rather than language parsers, it might be a better starting reference.

It's also a good idea to NOT compare the code you've worked on for a few days/weeks as your first attempt at a solution, with code worked on by dozens of experts for many man-years, not counting the hours they spend on similar problems, and writing scientific papers about it.

It's like you would compare yourself with olympic runners after your first lap on the track.

Getting really good takes lots of time and effort in any field (worth getting really good at)

So I decided to write a c++ parser, lots of string manipulation, plenty of substr's and find_first_of \n \t \f et al.

How long have you been coding for? I've been at it for over 15 years and I am still improving to this day. Generally speaking, and based only on my limited observations, it takes 5 years to become reasonably competent and 10 years to get past your desire (and failed attempts) to overarchitect things and reinvent wheels, and start to feel really competent. And even at 15 years you'll feel a lot more competent than you did at ten years of experience. Best advice is to not lose heart, keep coding, do the best you can and accept that you'll have to go through all of the failures, mistakes, different types of development processes, and so forth, in order to truly understand what you're doing and what the implications of any of your decisions will truly mean. Learn by doing and improve with each attempt.

It's also a good idea to NOT compare the code you've worked on for a few days/weeks as your first attempt at a solution, with code worked on by dozens of experts for many man-years, not counting the hours they spend on similar problems, and writing scientific papers about it.

This. Seriously this.

You're comparing yourself, to one of the oldest and most prominent codebases in Unix world that compiles most of the software out there. Their parser must have been tweaked by hundreds of different coders.

Hell, if your code remotely resembled that, you'd probably be a friggin programmer genius.

It's also a good idea to NOT compare the code you've worked on for a few days/weeks as your first attempt at a solution, with code worked on by dozens of experts for many man-years, not counting the hours they spend on similar problems, and writing scientific papers about it.

This. Seriously this.

You're comparing yourself, to one of the oldest and most prominent codebases in Unix world that compiles most of the software out there. Their parser must have been tweaked by hundreds of different coders.

Hell, if your code remotely resembled that, you'd probably be a friggin programmer genius.

Good point, I knew plenty of people were working on it and also as it's open source people can post in suggestions/fixes, so in that case it's got a head start, however, I do think you should be able to reproduce similar code of the top of your head. My code works, string manipulation is easy enough, as I said you could do it in java-script, however there was no overall architecture to my design, only to start with the pre-processor directives and work it out from there, start building more and more generic functions. It will be interesting to try and validate a class with multiple inheritance,

I will soldier on.

You're mistaken. As soon as you try bigger applications you realize that, in software development, there are things that just can't be done by a single person. No matter how good you are.

Its just the reality of it. Could John Carmack code all of IdTech 5 himself? Could Tim Sweeney code all of UnrealEngine 4 himself? I doubt it.

I do recommend one thing, do the things you like, for the rest, there is always a library made by someone who liked to do that particular thing.

The only people that aren't cut out for programming are the ones that don't enjoy programming. It takes years, dare I say decades, to become an expert programmer. Even then, you'll look at your code and think you could do better. In the end, the best code is code that works.

Are some people not cut out for programming?

I always catch flak for this, but I truly believe what I'm about to say.

There are some who are naturally good at problem solving, but that is a skill that can be learned over time. That said, I don't believe there is such thing as a naturally gifted programmer or being cut out to be a programmer or not. Every programmer has busted their butts to be where they are and it is extremely bad form to compare your individual projects and tinkerings to that of a large group of programmers working together for hours a day over the course of months and years. It just takes time and dedication to become a programmer and anything you run into that is difficult just requires the drive to learn it and move forward.