Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[Blank Expression]

There's a difference between a discussion and a full fledged angry argument (yes, presenting your argument is part of a discussion, but you know what I mean, don't try to out pun me man!),  and this thread definitely has a foot in angry.

While consciously attempting to avoid treading on any toes: some people in this thread clearly have been to the rodeo before and have a grasp of the topic of software development, with enough of a practical, theoretical, and empirical background to make statements like some of the ones I've made in this thread. Some people in this thread operate on hobbyist logic, which is long (well, medium) on the empirical aspects and short on practice and theory. Which is fine when that's all you've got, but it should--almost "has to," really--give way when somebody with demonstrable bona fides points out something that invalidates the hobbyist logic. The resistance between hobbyist logic and new information often causes cognitive dissonance and butthurt (especially when delivered, as I am fond of, as declarative statements that look presumptuous when one doesn't realize that the speaker's already done his homework--when I say something in a declarative way, it's because I [probably] have done that homework).

Currently, I've split my project into multiple files each containing a certain thing, such as one set for item implementations and another for rooms. I'm finding this easier to maintain because of the length of files involved, but at the same time I sometimes run into strange errors to do with it, and I'm worried the web'll just start tangling up into a mess after a while.

Should I keep on with the multi-file style, or should I start merging everything into fewer, longer files? What advantages/disadvantages lie in each?

Needs way more information to be a coherent question. What language? Are these code files object-based or procedural? What are you attempting to do that is causing these errors?

[lordnincompoop]

Currently, I've split my project into multiple files each containing a certain thing, such as one set for item implementations and another for rooms. I'm finding this easier to maintain because of the length of files involved, but at the same time I sometimes run into strange errors to do with it, and I'm worried the web'll just start tangling up into a mess after a while.

Should I keep on with the multi-file style, or should I start merging everything into fewer, longer files? What advantages/disadvantages lie in each?

Needs way more information to be a coherent question. What language? Are these code files object-based or procedural? What are you attempting to do that is causing these errors?

C++. Files are mostly object-based, I have some procedures in there too. I'm tying them together via #include "bluh" (I don't #include .cpp files though, as apparently that's bad and I don't think I need to do that) as I'm supposed to do. I got an LNK2005 error from that once, which fixed itself somehow.

[Derekristow]

There can't be "no good reason" if so many people do it. Your inability to give a balanced or nuanced answer makes your point unbelievable. Thank you for your time, your arguments are noted, but please don't bother.

According to my programming teacher, who has worked in the video game industry for ~10 years, Visual Studio has been the standard for any company he's ever worked for or heard of that worked in C++/C#.  Basically, you can't beat VS in an IDE-off.  It's simply the best there is.

I'm fairly new to programming, so unfortunately I can't really say what about Visual Studio makes it better.  It's been very nice to work in so far though.

[Siquo]

Ahh, now I know what (y)our problem is, BE  (And Derek who just ninja'd me)

I come here for my hobby stuff. If I would need any advice for my work stuff from a forum like this, I'd be "doin it wrong". That is why most people here have a hobby attitude: it's supposed to be fun and games. So yeah, hobbyist logic, because I'm here for Fun, not the absolute truth in programming. Also, I got a genuine Toady warning the last time I talked to someone like you, so I'm going to stop doing that.

Currently, I've split my project into multiple files each containing a certain thing, such as one set for item implementations and another for rooms. I'm finding this easier to maintain because of the length of files involved, but at the same time I sometimes run into strange errors to do with it, and I'm worried the web'll just start tangling up into a mess after a while.

Well, you only ever need to include .h files. You hardly ever have to include files from .h files, if you use pointers as members. Then you can suffice with a "class B;" statement in the top.

For instance, room.h does not need to include door.h:

Code: [Select]

class Door;

class Room {
  public:
  std::list<Door*> doors;
};
In order to use any functions on the real Door object, you do need to include Door.h from the Room.cpp file, but that's okay. Keep in mind that all #include does, is make One Big Text File of your code, in a certain order. Circular references are bad.

[eerr]

While consciously attempting to avoid treading on any toes: some people in this thread clearly have been to the rodeo before and have a grasp of the topic of software development, with enough of a practical, theoretical, and empirical background to make statements like some of the ones I've made in this thread. Some people in this thread operate on hobbyist logic, which is long (well, medium) on the empirical aspects and short on practice and theory. Which is fine when that's all you've got, but it should--almost "has to," really--give way when somebody with demonstrable bona fides points out something that invalidates the hobbyist logic. The resistance between hobbyist logic and new information often causes cognitive dissonance and butthurt (especially when delivered, as I am fond of, as declarative statements that look presumptuous when one doesn't realize that the speaker's already done his homework--when I say something in a declarative way, it's because I [probably] have done that homework).

Ehhh, why so serious?

What are you, some sort of professional programmer?

[Normandy]

@eerr:
And so my face met my desk.

Eh. I don't see what's the problem. Person A has viewpoint A. Person B has viewpoint B. They argue about their viewpoints, Person C now sees the relative merits of both viewpoint A and viewpoint B. It's a learning process.

[lordnincompoop]

While consciously attempting to avoid treading on any toes: some people in this thread clearly have been to the rodeo before and have a grasp of the topic of software development, with enough of a practical, theoretical, and empirical background to make statements like some of the ones I've made in this thread. Some people in this thread operate on hobbyist logic, which is long (well, medium) on the empirical aspects and short on practice and theory. Which is fine when that's all you've got, but it should--almost "has to," really--give way when somebody with demonstrable bona fides points out something that invalidates the hobbyist logic. The resistance between hobbyist logic and new information often causes cognitive dissonance and butthurt (especially when delivered, as I am fond of, as declarative statements that look presumptuous when one doesn't realize that the speaker's already done his homework--when I say something in a declarative way, it's because I [probably] have done that homework).

Ehhh, why so serious?

What are you, some sort of professional programmer?

Apparently he is. He seems to know what he's doing, at least.

Ahh, now I know what (y)our problem is, BE  (And Derek who just ninja'd me)

I come here for my hobby stuff. If I would need any advice for my work stuff from a forum like this, I'd be "doin it wrong". That is why most people here have a hobby attitude: it's supposed to be fun and games. So yeah, hobbyist logic, because I'm here for Fun, not the absolute truth in programming. Also, I got a genuine Toady warning the last time I talked to someone like you, so I'm going to stop doing that.

Currently, I've split my project into multiple files each containing a certain thing, such as one set for item implementations and another for rooms. I'm finding this easier to maintain because of the length of files involved, but at the same time I sometimes run into strange errors to do with it, and I'm worried the web'll just start tangling up into a mess after a while.

Well, you only ever need to include .h files. You hardly ever have to include files from .h files, if you use pointers as members. Then you can suffice with a "class B;" statement in the top.

For instance, room.h does not need to include door.h:

Code: [Select]

class Door;

class Room {
  public:
  std::list<Door*> doors;
};
In order to use any functions on the real Door object, you do need to include Door.h from the Room.cpp file, but that's okay. Keep in mind that all #include does, is make One Big Text File of your code, in a certain order. Circular references are bad.

Right, I'm aware of that, and as far as I can tell I'm not making anything circular.

Should I be splitting them like this and using the #includes, or should I merge them all anyways?

It might not be the best example, but looking at the LCS 4.1 source they've used just one file for the whole game.

It is just a matter of preference?

[Nadaka]

Its been absolutely forever since I did c++, but when I did I tended to put everything in one main file, but that was for relatively small programs.

[eerr]

@eerr:
And so my face met my desk.

Eh. I don't see what's the problem. Person A has viewpoint A. Person B has viewpoint B. They argue about their viewpoints, Person C now sees the relative merits of both viewpoint A and viewpoint B. It's a learning process.

I know, this was for Blank Expression, specifically.

It seems like we drive away people who act the same as they do professionally, here.

[Siquo]

Spoiler: offtopic (click to show/hide)

It seems like we drive away people who act the same as they do professionally, here.

... I'd hate to be their colleague, then. Anyone who claims that X is always better than Y is always wrong (where X can be your IDE, compiler, language, OS, colour of your skin, anything), IMNSHO.

Ontopic:
Everything in one big file is.. more cumbersome in my experience. Even for smaller programs.

[qwertyuiopas]

I can see a few different ways of interpreting "one big file". Care to elaborate? It could mean one single source file that contains everything, or all of the headers combined, some odd combination of the two...

[Shades]

I'm fairly new to programming, so unfortunately I can't really say what about Visual Studio makes it better.  It's been very nice to work in so far though.

Visual Studio is arguably MS's best product, and if you want one feature which puts it a head and shoulders about other IDE's I've used it is the debugging and remote debugging integration. Not that GDB isn't great but it's not as easy to use and doesn't tie into any IDE as well as the VS is setup, and lets face it if your debugging there is a good chance your mind wants to be on the problem and not struggling against UI.

I use Code::Blocks a lot at home and Eclipse CDT from time to time, and tend to use VS at work, however the only reason I don't use it at home is because I don't run Windows as my main OS. Other aspects than the debugger it's more a swings and roundabouts thing, and the latest VS compiler and the current GCC are comparable for features and optimisation abilities.

Everything in one big file is.. more cumbersome in my experience. Even for smaller programs.

Very much so, the bigger a program is the more this will cause problems. It's just easier to find stuff in nicely organised code, and you may as well start your organisation at the file level. You will also find that big files lead to strange code dependencies, depending on which language you are using you might find that your code only compiles because object a and b are in the same file which is not something you want to require.

[Siquo]

Now that's an answer I can work with. So, as I'm unwilling to spend any money, is it worth it to try out VS Express?

[lordnincompoop]

I used VSExpress, and it was possibly the best IDE I found for C++ at least. Yes, try it and use it. You can even use it forever as long as you do tha registering thing.

[Siquo]

I'm okay with "registering". I'm just not paying any money to "that company" on personal principle. Yes, I'm looking at you, IE. There's still so many hours of my life that I want back, first.