Quote:
As for jpetrie, the whole of your post was useless, except for the very last line. Please avoid preaching.
And if you don't want unsolicited advice, please avoid making posts on a public forum
asking for help. Your original question was answered quite effectively already, so frankly I see no fault in pointing out ways in which you could improve yourself as a programmer. That is, in fact,
why I moderate this forum.
If you're not interested in suggestions on how to improve your code you are entirely free to ignore them. As fair warning, the remainder of this post will be a comment on the educational process. You may want to skip it.
Quote:
But jpetrie, I'm following a book. You're criticizing my coding practices... when I'm not the one coding.
It is through critique and peer review that we learn. You shouldn't make the mistake of taking critique of your code as critique of your person, nor you should you read that critique as any kind of lack of respect of your person on the part of the person offering the critique. You seem awefully offended that somebody is just trying to help.
Furthermore, I'm quite aware that you're getting the code from a book and thus it is not code of your complete authorship. That doesn't make it any more or less than what it is, however, and what it is is poor C++ code. It is not idiomatic within the language, nor is it promoting safe, efficient, manageable practices. The value you place on those -- the latter, especially -- directly correlates to the value you place on the professionalism of this craft.
Quote:
Secondly, I don't really mind whether my code is perfectly OOP or C++. C's a fine language.
Nothing I mentioned really had anything to do with OO as a paradigm; I don't mind whether your code is OO or not either. There is a time and place for everything, and if the paradigm isn't appropriate or desired there is nothing wrong with not using it.
C is a fine language, too. But C is C and C++ is C++. You are using one or the other. In this case, you are using C++ since you are using at least "new," "delete" and "class" and such -- all of these are C++-only constructs.
You make a fine point about both being used for their intended purposes, but you're
not using C here. You are using the idioms of C within C++, and they are very different languages that just so happen to share enough syntactical compatibility as to be backwards compatible. But C++ isn't a strict superset of C in terms of functionality and behavior. You can write seriously broken programs by misusing C idioms in C++, because much of the behavioral differences are very subtle. Fortunately nothing you've shown here is anywhere near that kind of danger, but the damage done still runs the gamut from stylistically poor (but subjective) and objectively unsafe (such as the use of manual memory management where RAII via std::vector and such would be a better option and thus -- as I mentioned -- something you should
think about).
Quote:
like structs for handling small batches of data. Nice and tidy when I don't plan on putting in any functions. Easy to access. Don't have to build any functions- just some simple dot syntax. I use unions, too. And arrays. When appropriate.
...
Oh hell, do I like that better. The second is just redundant. Structures have a place and a purpose, and so do classes.
You misunderstood me greatly. At no point did I suggest to you that you replace the former code with the latter, there. In fact, you are correct in disliking the latter code, because it is redundant and a pointless "encapsulation" of data -- a bad design.
I suggested you avoid "typedef struct..." because that is a C-ism. In C++, you can simply use "struct..." without the typedef. As such, what I was suggesting there was:
struct ZFXTEXTURE{ float fAlpha; // overall transparency value char *chName; // texture filename void *pData; // texture data ZFXCOLOR *pClrKeys; // color key array DWORD dwNum; // number of color keys };
Not that class you seemed to think I was suggesting. That class exhibits very poor encapsulation design among other things.
Additionally, some of what you are saying sounds to me like you think struct and class are different things in C++. They are not, in general. In fact, they differ
only in that a struct's members (and inheritance access) are public by default, and a class's are private by default. In all other respects you can interchange struct and class as much as you want.
