Really stupid C++ questions


#1

There’s no doubt I need to do craploads of C++ RTFMing, but…

the tutorial broke down just about the point I was going to learn how to create a subclass. Dang.

My questions do not relate to the nature of subclasses (I was once a moderately accomplished Swing developer, before backsliding into the seedy underworld of the musician) but rather where to put them and how to refer to them and how to get VC to see them.

I notice the tutorial puts several tree-oriented classes in the TreeViewDemo file. Is this a recommended technique? I’m used to one class per file, unless it’s an inner class. (Do we have these in C++?? I haven’t run into one yet.) Anyway, I don’t want to do it just because it’s the only way I can figure to get VC to see a new class…

Also I’m not clear about the distinction between header and cpp files. Seems like I’m putting all my code into header files so far. Which is all fine and good, since it’s working… but doesn’t seem to fit the idea of a ‘header’. I also recall Jules saying somewhere that creating separate files was ‘overkill’ for some class or other. Can I get by with just one of these files, if I’m just doing some simple subclassing?

Now I’d like to grab that nice demo code for converting an XMLDoc into a tree, and work it into my project, but I’m not sure how to go about doing it. Can I just put those subclasses in my mainComponent file? For now?

As usual, I’ feel comfortable when I’m working inside classes, and like I’m swimming underwater when it comes to linking, makefiles, paths, environments, etc.

One thing I discovered–if I add another ‘project’ to my ‘solution’ it breaks the ‘intellisense’. Not sure I understand the difference between a project and a solution. I wish I could just keep a bunch of projects open, but I guess that’s not how it works.

Anyway… Quick tips, links to helpful tutorials and explanations, creative expletives vis-a-vis the sheer scope of my ignorance: all welcome. in the meantime, I’ll be searching for some more basic C++ intros.

Thanks,
-eric


#2

I hate to do this, but you really do need to RTFM. You can learn some really bad practices by just looking at few demos and trying to use them as a template for everything you do henceforth.

I principle, if you’re going to learn a bad ‘one size fits all[1]’ rule, then make it “There is never a time when it is inappropriate to place code in a cpp file.”[2]

Throwing all of your code in header files is untidy, will increase compilation times, and will often creating linking problems.

As for Visual C++, projects should be treated as individual parts of a whole. A single application will typically be both project and solution. Sometimes libraries can be part of the solution that also contains an application. Sometimes, as in the case of toolkits, many individual applications may go to make up a solution, but this is a pretty specialized case. By and large, if your project produces one executable or dill, then you probably should consider solutions and projects to be one and the same.

[1] never trust anyone who tries to tell you there are any “one size fits all” rules. :wink:

[2] This rule is a great example of why rules are bad. It isn’t true. However, by the time you run into cases where this rule doesn’t hold, you’ll be past the stage of needing to think about these kinds of things.