Quote:Original post by Palidorflame

Oh, the reason i'm using this instead of fstream is because at Full Sail, we are learning code optimization, and including fstream would add a lot of overhead stuff that wouldn't be needed or wanted in a large scale game. And we're building code that we'll use in projects to come, so i wanted to make the most speed-based menu system i could.

This is a bunch of FUD and so wrong on so many levels.

Your code uses std::cout and std::string (apparently), which means that 95% of "overhead" is already in. Including fstream doesn't change much.

Or are we talking code bloat? How much does fstream contribute to that?

Compilation times? There's ios_fwd.

What are the performance characteristics of DynArray?

On any large scale project in C++ you do not want C with classes. You want solidly engineered robust classes that don't crash on every error. And looking into performance of a menu system is completely redundant, especially at this point, especially while learning C with classes, especially before even covering things like polymorphism.

This is exactly the reason why such schools get such bad rep, even if it ultimately isn't always warranted.

I apologize if something i comment on about programming is either incorrect, or not efficient. I just started c++ for the first time in November. In my opinion, i'm doing a fairly good job, but I had a small coding problem that i was hoping someone here could help me discover (that's the point of forums, right?).

I will just consult friends and teachers. Thanks for the responses.

I don't understand why your design is so complicated.

Why would a "full menu" contain "options" that are not "menu options"? Aren't they menu options by virtue of the fact that they are in a menu? Even then, why would you need to downcast? Is there something that menu options can do that ordinary options can't? If so, why?

Also, why do you have to ask the menu what its "selected index" is, and then ask it again what option corresponds to that index? Why would calling code ever even care that the menu has such a concept as an "index"? Your interface is too complicated; what the calling code wants to know is what option is selected, so that's what the member function should be: getSelectedOption().

Also, why do you have to save the old menu and create a new one in two steps? The "menu stack" can be more intelligent than that. Why would you ever push something and then not create a new menu? Why would you ever create a new menu without remembering the current one? Pairs of actions are algorithms; encapsulate them.

Also, don't convert characters to integers just to figure out what character they are. There are symbolic constants for characters: you just put them in single quotes.

Also, use references to avoid repeating common sub-expressions (often, this is a temporary measure until you can refactor in a better way).

Quote:Original post by Palidorflame
I apologize if something i comment on about programming is either incorrect, or not efficient. I just started c++ for the first time in November. In my opinion, i'm doing a fairly good job, but I had a small coding problem that i was hoping someone here could help me discover (that's the point of forums, right?).

I won't try to speak for other forums, but the point of our forum is to teach you something. If you are not interested in learning from us, then I suppose I won't very easily convince you otherwise, but I would urge you to reconsider. You don't need to apologize for not knowing something, but you are expected not to assert things without being able to justify them. (Whether or not you are doing a "fairly good job" is (a) dependant on a lot of missing context (previous programming experience?) and (b) largely irrelevant anyway.)

Antheus knows what he's talking about, here. Also, consider that constant overheads are more acceptable in a large project: they get averaged out. Basically the only people who care about <iostream> adding half a meg to the final executable size are the ones who have a ridiculously small executable size as a design requirement (i.e., people in the demo scene).

Zahlman,

I looked over my code a few hundred times, and while doing so i looked for some of the things you mentioned that would be better design. I have to admit, i haven't really had a chance to think about design that much, so I've had a hard time creating good objects.

I do see some thing that probably don't even need to be there, such as the Option class altogether, and i'm going to start changing these areas. I do thank you for your insight. I didn't mean to sound rude earlier, but after looking at it, i realized it must have come off that way. So i apologize to all.

I finally did figure out what was wrong, and it was a stupid problem lol When i initialized my currentmenu, i hardcoded the file name, but the entries in my text file were there as inside quotes. So, when it tried to read the file, there were quotes on both sides of the filename. So it did in fact error out, as stonemetal and Antheus said!

Quote:Original post by Palidorflame
I do see some thing that probably don't even need to be there, such as the Option class altogether, and i'm going to start changing these areas. I do thank you for your insight. I didn't mean to sound rude earlier, but after looking at it, i realized it must have come off that way. So i apologize to all.

It happens; don't worry about it. The unspoken policy is

1) Try really hard to make sure you sound like you're criticizing code, and not the person.
2) Try really hard to assume your code is what is being criticized, rather than you.

Quote:I finally did figure out what was wrong, and it was a stupid problem lol When i initialized my currentmenu, i hardcoded the file name, but the entries in my text file were there as inside quotes. So, when it tried to read the file, there were quotes on both sides of the filename. So it did in fact error out, as stonemetal and Antheus said!

Heh. :) (EDIT: I initially misread your description of the problem.)

incidentally on the whole optimizing stuff by dropping back to C style file handling, I really think you are looking in the wrong area. First off the slowest part of file I/O is going to be disk access the difference in speed is like ordering a book from amazon and it gets delivered a year later optimizing the order process so that it takes seconds instead of minutes doesn't even register on the clock. As far as code size goes, IDtech5 supports textures of 5GB in size and games on xbox360 have shipped on three DVDs do you really think dropping a half meg off your executable size really means anything?

If you want to do something that may make a difference download zlib and try compressing your art assets. You still won't get much out of it since most of your textures and what not will already be compressed, but from what I have seen most model formats don't use compression so you will get some benefit out of it. Another thing to try is build a pre-loader so that load times are hidden as much as possible.