Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / Game Design & Programming / Hit Fly 0.1 Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Victor Widell

January 04, 2005, 05:18 AM

I will give you a few examples of WHY macros are evil. And also a few cases where they are OK.

Evil:
* A macro cannot be debugged. Macros are basically a search-and-replace just before the compilation. Any error message or debug break will apply only to the code _after_ replacment.
* Macros don't have namespaces. A pain in the ass when you discover someone else has allready defined LoadImage(). (Happened to me, and since it was a macro, the error message was not very helpful either. It just wouldn't compile.)
* Marcos don't have scopes. A macro is defined in ALL your code, even if you re-define it locally in another scope. (Happened to me, and sice I used pure C I could not use a const. I ended up renaming the macro all over my code.)
* Macros don't have type checking. This might not be very important since the compiler will do the type checking later, but then it might be too late.

OK:
* Extremely simple, generic functions:

  1.  
  2. #define MIN(a, b) (a<b) ? (a) : (b)
  3. #define MAX(a, b) (a>b) ? (a) : (b)
  4. #define ABS(a) (a<0) ? (-a) : (a)
  5.  

* Forcing pure C tobehave nicely:
#define bool char
#define true 1
#define false 0
* Hacking things that would be very difficult to do properly. (wxWidgets event tables?)


I can understand your amusement of macros, since they CAN be very funny to play with. But if you believe they are a good, universal tool and should be used wherever possible, you might want to reconsider. (Actually, you probably don't _want_ to, but you should.)

 
Chris

January 04, 2005, 05:21 AM

And even these extremely simple generic functions should be done this way:

  1.  
  2. template <typename T>
  3. T min ( T a, T b ) { return (a<b) ? a : b };
  4.  


Because something like
  1.  
  2. x = min (++a, b)
  3.  

evaluates to
  1.  
  2. x = (++a < b) ? ++a : b;
  3.  

which obviously isn't want you intended it to do.

 
Jeroen

January 04, 2005, 06:14 AM

>You might hate me for this, but I believe object-orientation is way overrated, overused,
>and misused.

I won't hate you for it, but I don't agree with you either :) (Except on the misused part). It seems as if in your mind "Object Orientation == C++", which is definitely not the case.

Without talking about any specific language, the general concept of "Object Orientation" has as it's main advantage an increased compartmentalization of code/functionality. When a code-base grows in size, and more people work on it, it becomes increasingly critical to have clearly defined "boxes" of functionality with well-defined interfaces. This can be achieved in any language, even totally non object-oriented ones such as C, Pascal or Basic. It is simply easier to achieve in a language such as C++ because it has a number of features that make compartmentalizing code easier. I agree that this doesn't make C++ an object oriented language (It isn't).

I also agree with you about globals. Almost no programming "rule" is set in stone, as it is always possible to come up with examples where something you are Not Supposed To Do are actually a good idea. Globals are one such example. They're a technique in a software developer's toolbox, to be used when appropriate. The crux is in "when appropriate". Globals can be used in many situations, but there is almost a better way.

 
FrancoisSoft

January 04, 2005, 02:08 PM

You muscle head! Did you even look at my example? I keep telling you people to put those curlies around code blocks.

 
TobeyThorn

January 04, 2005, 02:24 PM

you are right that i dont fully understand everything technical in programming. however, i do know that making code as elegant, universal, and understandable as posible is important. you want to reinvent the wheel and do everything in your own, rediculous way for the sake of iconoclasm.

you blindly reject all of the sincere suggestions that you receive. this is silly considering these people were nice enough to share their thoughts on your projects.

also, it is clear from reading your descriptions that you have no understanding of how to undertake a project or work in a team.

 
monster

January 04, 2005, 07:04 PM

But I shouldn't have to put 'curlies' round code blocks. The language doesn't require me to, just the fact that some muscle head's stuck some dodgy macro somewhere in an include file and that's broken my code. Macros are evil; QED.

 
ReaperUnreal

January 04, 2005, 09:11 PM

You know, this code reminds me of someone who's just gone from VB to C++. Seriously, I just took an entire course on C++ programming (got an A+ too!) and let me just say that you really need to read a book or 2 on C++. This isn't VB, everything isn't just out in the open for you. Global variables ARE bad, and there ARE greivous consequences for certain actions. Seriously, don't even get me started on macros.

My best suggestion to you, go buy a C++ book (a good one, not C++ for Dummies or the like) and read. Then come back and write your little game properly.

 
Axel

January 04, 2005, 10:06 PM

Hm I'm not sure if this is a troll or not. But if he's not, he will learn his lessons soon enough :D

 
Conehead

January 04, 2005, 11:34 PM

I must disagree on this monster.

Even tough the language doesn't requires to put brackets, it is a good practice to use them anyway. My reason is simple, it is much easier to read code with totally screwed up indentation when at least you got the brackets to show you the way. Been in that situation many times (people playing with their tab settings inserting spaces when they shouldn't, wierd merges), I'll never get caught again, not for the price of two brackets!

 
Kimmo Pietilš

January 05, 2005, 02:04 AM

Or you could expand and write massive project and see the problems yourself, learning it hard way, then go to read a book :)

Just don't try to teach others (professionals) here or defend your coding style and design.

FrancoisSoft wrote: You didn't understand what I said. I want you to look at the game. ... Just take a look at the code and tell me if you notice anything weird. I'm not asking you to compile the code.


FrancoisSoft wrote: I really did not want people to comment on the coding style so much. I just wanted people to look at the game itself and maybe catch bugs. Why do people always go for the code???


We have difficulties in understanding what you want us to do?

 
Chris

January 05, 2005, 04:27 AM

That's exactly my message: Either show a game beta and let us test, or discuss your code with us. But in the second case, better be prepared for massive criticism because you're obviously just starting to learn programming (using VB isn't considered programming by many of us).

 
Juan Carlos Arevalo-Baeza

January 05, 2005, 06:40 AM

It seems as if in your mind "Object Orientation == C++", which is definitely not the case.


You insult me!

main advantage an increased compartmentalization of code/functionality


Yes. The common misconception (and the reason for the overrated and overused part) consists in thinking that OO is the only proper way to achieve those goals. That is not the case. There are many ways to compartmentalize software development

When a code-base grows in size, and more people work on it, it becomes increasingly critical to have clearly defined "boxes" of functionality with well-defined interfaces.


Then, do that. But OO might just not be the way in a particular case. Or maybe C++'s implementation of OO is just not appropriate enough. I recently posted an example of this around here:

http://www.flipcode.com/cgi-bin/fcmsg.cgi?thread_show=24630&msg=197750

This can be achieved in any language, even totally non object-oriented ones such as C, Pascal or Basic


Or assembler. Yes, and non-OO can be achieved in Java or C#. :-)

It's just good to know (and embrace) the fact that you have choices that you can (and should) mix and match together with OO: Event-driven programming, functional programming, database programming, value-oriented programming, generic programming, procedural programming...

Salutaciones,
JCAB

 
tussukka

January 05, 2005, 12:04 PM

  1.  
  2. // Expanded, we have:
  3.  
  4. if (Ok) {
  5.  
  6.   if (Answer == 1) { SayHello() };
  7.  
  8. }
  9.  

No, we won't. Macros generally do string substitution so you would end up with something more along the lines of:
  1.  
  2. if (Ok) {
  3.   if (Ok == 1) { ...
  4.  

And you know what? There is easier way of saying the same thing:
  1.  
  2. if ( ok && ok == 1 ) { ...
  3.  

Which infact is same as:
  1.  
  2. if ( ok ) { ...
  3.  

So I fail to see where you need a macro for this.. care to provide example where you actually make the code simpler using macros? ;)

I must add a remark that above is just my best guess what you were trying to achieve as you incorrectly expanded the macro to something else the compiled would have, so I have no idea if you meant what the macro intended to do (and therefore had error in the macro, or if the error was in your translation of the macro.. so basicly I have no way of knowing what you intended to do due to errors in your example ;)

So I had to extrapolate the missing parts, if above conclusion is incorrect please be more specific what it is that you actually wanted to do in your example.

 
monster

January 05, 2005, 08:14 PM

Oh yeah, I completely agree. But use brackets for the right reasons; readability, maintainability, coding standards, whatever. But not just because someone might write some stupid macro that will break everyone's code!

Having said that, if you've got the right mechanisms in place to make people use brackets correctly then those same standards would probably preclude you from writing dodgy macros!

 
juhnu

January 05, 2005, 11:00 PM

maybe it was you who made the min/max macros to windows.h :) those are a major headache for their convenient naming



juh


 
Conehead

January 05, 2005, 11:50 PM

You are right of course, adding brackets because some obscure macro might fail, is absolutely not a good reason. That said, macro may be your friend if you are coding in pure C (yes Im stuck with C where I work) and you try to implements mechanisms similar to template to reduce code duplication. But, in most cases, not being able to debug a macro makes me change my mind and I find another way.

 
FrancoisSoft

January 06, 2005, 02:21 PM

Been chapping off lately, have you! And by the way are the bagels fresh?

 
FrancoisSoft

January 06, 2005, 02:22 PM

I'm reimplementing the project once again!

 
This thread contains 48 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.