Help me fix my mess!!!!

>No, no, no. That's horrible practice.
What utter tosh!!!

For newbies, compiling early and often is a good idea.
Which is better
1. Write a few lines, compile, get a couple of errors which can be fixed and move on.

2. Write pages and pages of code, compile and find way too many errors to deal with, then dump the whole mess on a message board asking for help.

You don't have to run the code every time you compile, and many compilers have a 'check syntax' mode which is very quick.

I don't see why newbies should be doing code that nets them a few errors every few lines. To me, what your saying sounds like "What's better for a skier, go down a double-diamond and stop every few feet so when you fall you go down real easy or go as far as you can so when you fall you break your leg." and my reply to your question would be, they're doing a program too advanced for their level if they're getting that many errors.

Learning something can be a painfully slow process for anyone, but I found from experience (and I don't mean programming) that it's better to learn at an appropriate pace and learn it well before you move on. And what that means is "no errors at all". So it seems impractical for me to see a guy running into so many errors when if he was learning properly he should only be having trouble with the current task he is learning.

You must know how people who go to these tutorials are. They start with lesson one and are on to lesson 10 within the hour. The next morning they're learning OpenGL and they don't even know how to properly make a loop. Programming, in theory, seems like a very simple thing, especially to intelligent people, which most of the people on this forum are. But it's completely different in practice and the reason we see so many errors in such a basic program is not because the OP was in over his head and didn't compile enough, it's because he may have rushed himself and got to his current program before he should have.

Anyway, that's just how I feel on the subject. Feel free to disagree and push your perspective, I'm willing to hear it. I've listened to all your points thus far, it's just I've heard it all before and thought about it. To me, it just doesn't seem like good practice.

Using the compiler as a substitute for knowing your language and being careful about spelling is WRONG WRONG WRONG.

Personally I hate every compiler error, they indicate a flaw in my knowledge of the language constructs I try to use which means my understanding of the language itself is incomplete.
While they can be helpful to point out things like honest typos, those too I should have caught.

And when you're working on large programs where a compilation cycle means claiming resources on a server for several hours or days you'd better make sure your code compiles first time or you're soon looking at some angry colleagues.
And no, that's not at all an exaggeration, I've worked on projects where there were millions of lines of code over hundreds of sources which would take 48-72 hours to do a full build on a dedicated machine. If you aren't sure of your code, you don't request it be built because basically there can be only a single build per week starting friday afternoon and hopefully complete sometime monday morning.

Originally Posted by Salem

>No, no, no. That's horrible practice.
What utter tosh!!!

For newbies, compiling early and often is a good idea.
Which is better
1. Write a few lines, compile, get a couple of errors which can be fixed and move on.

2. Write pages and pages of code, compile and find way too many errors to deal with, then dump the whole mess on a message board asking for help.

Neither.
Write a little bit of code you understand. And only add code you are reasonably comfortable with, don't just write and write and hope it may compile.
Write and understand and KNOW it will compile.
If you then get runtime errors there was something wrong with your logic and understanding, but you at least got syntactically correct code.

If you can't do that, you're not yet at the stage where you should write large programs anyway.

I usually compile after I finish a function or two. If I am doing something simple I usually don't compile until the end of the program.


I use this line of code but when I go to the C:\ drive the file is not there.
fstream a_file("C:\grades.txt");

>> fstream a_file("C:\grades.txt");

You didn't copy my suggestion correctly. You need to use \\ instead of \ because \ is an escape character.

Sly, to be honest, if the largest program you've ever written is 2000 lines, you're not really qualified to give advice on this topic.

Originally Posted by jwenting

I've worked on projects where there were millions of lines of code over hundreds of sources which would take 48-72 hours to do a full build on a dedicated machine. If you aren't sure of your code, you don't request it be built because basically there can be only a single build per week starting friday afternoon and hopefully complete sometime monday morning.

I've worked on similar projects (a 5 million line mainframe travel reservation system, to be precise) where a full build takes a day or two. In that situation, there are several solutions.

1) No program that big should produce a single monolithic executable. The project should be refactored to build several smaller dlls, or use some sort of component system (CORBA, COM, .NET, take your pick)

2) If that can't happen (and obviously it's a big project so it takes time), YOU ABSOLUTLEY MUST COMPILE OFTEN. Not build, compile. If you submit a change for the weekly build that you haven't compiled, you're in trouble.

3) All of your changes should also be built into a small unit-testable module, which can be built quickly.

Originally Posted by jwenting

Personally I hate every compiler error, they indicate a flaw in my knowledge of the language constructs I try to use which means my understanding of the language itself is incomplete.
While they can be helpful to point out things like honest typos, those too I should have caught.

Sorry, that is complete bull......... A good C++ programmer will design his classes in such a way that even a syntactically correct but incorrect use will generate a compile-time error.

for example, to borrow from Scott Meyers (effective C++ 3rd ed item 18) you could design a Date class like this

Code:

class Date
{
    int day, month;
public:
    Date(int d, int m);
};

but then an american comes along and goes

Code:

// hmm need a date for christmas
Date xmasDay(12, 25); // oh crap

whereas you can instead use something like

Code:

class Date
{
public:
    enum Month
    {
        jan, feb,mar // etc
    };
    Date(int d, Month m);
private:
    int  day;
    Month month;
};

// hmm need a date for christmas
// Date xmasDay(12, 25); // hmm compiler error 
Date xmasDay(25, Date::dec); // fixed before runtime!! woohoo

obviously this is a trivial example (and that is bordeline pseudo-code, so don't bother criticizing the style), but it illustrates the concept of using the compiler to enforce design constraints

I agree with whoever said "only write a few lines and then compile". But I would modify it to: "Only write as many lines as you are absolutely certain are correct, and when you write a line that you aren't sure about, compile to check it." I've heard professors give this advice before, and I generally agree. As you get more experienced, you naturally will go longer and longer without compiling, and then, even when you screw up and get 103 compile errors, it's still pretty easy to clean up in less than 5 minutes.

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

Originally Posted by SlyMaelstrom

You must know how people who go to these tutorials are. They start with lesson one and are on to lesson 10 within the hour. The next morning they're learning OpenGL and they don't even know how to properly make a loop.

If they were smart, they bookmarked the tutorials, and can referance them to help fix their code. Yes, some people are impatient and want to jump into game making right away (I assume that is why you chose OpenGL as an example) but sometimes, starting with the complicated stuff makes things easier for people in the long run. There is a sequence one CAN go through to learn a language, but no one agrees on the exacts. Almost all will agree, start in console and move from there. Depending on your background (*nix vs windows) the console is the important one and GUIs are just extra.

But most people come from a M$ enviorment and believe that GUI is the most important part so they rush to it. I don't think shooting them down for the style is a good idea, let them learn the lesson, and maybe, they will dedicate enough and learn that stuff first (probably not though) I learned a lot from trying to do things beyond my ability, and compiling every 100 or so lines. Now I can go 1000 lines and not need to compile very often (of course I still have some minor syntax errors especially when I am learning new APIs and or a new language) My largest program is a 15k line program, while that is small compared to the 5mil (OOP was made for a reason) line programs you guys have worked with, I don't think it makes me any less qualified to comment on early programming learning.

Sticking to the VERY basics one is likely to get bored when learning, I prefer to challenge myself, which makes me a little more likely to make mistakes, making compilinig more often useful. In the workplace, on huge applications, people are no longer writing programs with the near sole purpose of learning, they are writting them because they are being paid and are professionals. So please don't try and compare that to the learning process. That is like saying one should be completely professional and adultlike while still a child.

Originally Posted by Starr

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

Never used VS, but building compiles all the linked files each time, compile will just rebuild the partst that have changed. Atleast that is my understanding. Just try the difference between compile and rebuild.

Originally Posted by Starr

You said compile every few lines and not build. What is the difference because I build after each function or two I write, so what is the difference between building and compileing in VS C++ 2005?

'compiling' means compiling an individual .cpp to an object file.
'building' refers to the process of compiling every .cpp that needs it (i.e. if it or a header it includes has changed) and then linking all the object files to produce an exe (or a dll or a lib)

obviously building takes a lot longer then compiling, especially once you get past more then one or two source files. In fact the term building can often encompass building several projects (libraries and exes) at once.

Wraithan, I never said you weren't qualified to comment on 'early programming learning'. However, if your experience is limited to a 2k line program in C++, you shouldn't go around making authorative statements about best practice for building in C++, as Sly was.

Chaos, you've gotten so far off the inital subject matter it baffles me. Here we are looking at a situation where a guy has a program under 100 lines and someone said "compile often" to it. 100 lines, not 1,000,000 or more. I in no way made any statement that says how often you compile that size of a program as I have no way of making that judgement. If you were to tell me that you should compile everytime you make a minor change on a system that's currently running and being updated, I'd agree with you. That's not what we're discussing though. So, if you want to say I have no say on this matter and I was making conclusions on things I have no experience in then you better know what I and everyone else here is talking about.

What is the point of typing in 100+ lines and then compiling to get 100+ errors, when the average noob can't even write "hello world" without generating syntax errors.

As IfYouSaySo summarised, you program within your ability of making mistakes and being able to fix the result.

Sure, the pros can type all day and generate only a few errors, most of which will be obvious typos.

Whilst the average pro could probably write a module off the bat and make it compile first time, there is little chance that it would run perfectly each time, nor for example pass lint first time.