Thread: Help me fix my mess!!!!

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.

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");

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.

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.