Dec 20 2006, 8:09 am
In response to Kaioken
|
|
Cecil81067
 |
That's an easier way of understanding it heh. I was never tought what #define really was so I just assumed it was something more advanced. I mainly use constant variables to do that. I suppose #define is probably better to cut down variable usage?
|
Cecil81067 wrote:
I mainly use constant variables to do that. I suppose #define is probably better to cut down variable usage? Yes. If you have a global constant variable for a numeric value or a short text string, it's better off as a #define macro. Constant vars are for long text strings, and for holding created-object references. Note that #define names can be whatever you like, however it's commonly accepted to make them all in CAPS to indicate they're a #define macro. It's preference of course. In my islist() "procedure" example, I didn't make it in caps, because that can be considered a proc since what it does is just call the istype() proc. Though, because I've seen (non-idiotic) people use const vars for numeric values (even more so, I've seen it used in stddef.dm (a special file that is always included when compiling. Some of it's contents are lots of #defines for built-in numeric values, like SEE_OBJS, NORTH, SOUTH, etc. Actually, it appears that it uses const vars for the directions, rather than #defines... That made me wonder if it's just randomly done or there is a reason, hence this topic: (I guess watch it if you're interested) [link] | |
(added another paragraph to previous post!) >_>
Also, I didn't mention, a small "issue" (not really). With #defines, unlike const vars, the order matters (because the compiler "adds them to its glossary" as it compiles, reading threw the code in alphabet-file and top-bottom order). So if you have something like this code: world << MSG It won't work, you need to #define before you use it. Generally, you can just plug all #defines in the first file in your project. What I did is create a DM file called 00_Initial.dm and put most of my #defines there (00 means its the first in "alphabet" order). If I have specific defines for specific procs/DM files, I put it before them (for example, the latter of the '#define n' I previously posted is specific for that procedure - but #defines like islist() aren't and can be used anywhere, therefore they should be first and in the 00_Initial.dm file). Actually, if/when you have more projects, it's likely you will want to use a shared 00_Initial.dm by them and #include it first in each. | |
Kaioken wrote:
Did YOU read MY post? Which happened to be in reply to yours. Your way of just shortening that copy&pasting some 5 lines has an efficiency penalty, which makes it pretty worthless. Nuh-uh. Mine does not have an efficency penalty. It doesn't loop through every variable in the list, but only the ones you want to nullify! It's very efficient. On the other hand, your definition will cause problems with readability of the code. | |
Android Data wrote:
Nuh-uh. Mine does not have an efficency penalty. It doesn't loop through every variable in the list, but only the ones you want to nullify! It's very efficient. I didn't mean it loops threw the 'vars' var. I meant it loops threw your temporary, newly created list. But it IS slower, and DOES uselessly create a list for not much of a shortcut. Let's look at your code... proc In my suggested code, the ONLY actions are straight 'set variable to null'. The compiler does the checking for you at compile-time. So right, maybe it won't take as much as 5 seconds to run, but your approach is definetely pointlessly too inefficient. On the other hand, your definition will cause problems with readability of the code. I'm sorry, but provided you read the single #define line, it is just as readable, if not more than, as you creating a loop, etc. Though anyway, this topic is solved now, let's lay off, uh huh? | |
First off - You don't need to have a var/const at the start of a file.
Secondly - You're not going to hit the variable limit unless you're doing something ridiculous. Thirdly - I have no idea why defines and constant variables are mixed like that in stddef.dm. Likely, because it was produced over time by various programmers. (Personally, I like to use var/consts, so I can do stuff like this:) var/const/NORTH=1 | |
#define isn't just useful for macros, it's also useful for conditional compilation.
Example: #define BANCHECK You can then #define and #undef BANCHECK to include/exclude our world/IsBanned definition. | |
Kaioken wrote:
I didn't mean it loops threw the 'vars' var. I meant it loops threw your temporary, newly created list. And how is code like for(var/obj/O in world) any different? Sure, it doesn't create a temporary list, but it DOES loop through every instance in the world.contents list. But it IS slower, and DOES uselessly create a list for not much of a shortcut. But it's more robust than your version, since your version has a pre-defined set of arguments, forces you to use a definition which is going to be confusing in the future and this all just so you can avoid having 0.0065 seconds of processing? Please. Unless DreamSeeker has a memory leak, there's no need to argue about a temporary list being created. If you're that close to the limit you should really consider to work smarter anyway. /*for() loop == create a new list object. create 11 text I concur that I goofed up with verbs. I thought I removed that in the final run, as I already knew it was there. Doesn't matter, the point still comes through and I corrected myself later on. There's nothing wrong with using it that way. In fact, I can already think of one thing that might be better to do here: datum/proc/nullify() for(var/X in args) if(X in src.vars) src.vars[X]=null There we go. That's all I forgot to do here. I'm sorry, but provided you read the single #define line, it is just as readable, if not more than, as you creating a loop, etc. That "single #define line" would be repeated over and over in the code whenever you wanted to nullify more variables, since your brain wants to use that method more rather than "waste space". In fact, if you really want to be efficient: M.Float=null; M.Image=null; M.Regen=null; M.Haste=null; M.Quick=null; M.Shell=null; M.Armor=null; M.Countdown=null; M.HP_Leak=null; M.Wall=null; M.Berserk=null | |
Er, dude, drop it. Sure, again, you frequently loop threw things and it doesn't freeze games, BUT all I'm saying is that this time looping is unnecessary, and not looping is indeed more efficient.
Android Data wrote: But it's more robust than your version, since your version has a pre-defined set of arguments, Yeah, and I stated it there, anyway, drop the 3rd #define I posted. 'n(varname)' instead of 'M.varname=null' is shortening enough. forces you to use a definition Right. So what? Your method "forces you to create a list and use a loop". which is going to be confusing in the future It won't be, because the #define is right there, available for reading a year later, just like the rest of the code. and this all just so you can avoid having 0.0065 seconds of processing? And all YOU'RE doing is just so you can, in the first place, avoid having 3 seconds of copy and pasting 'var=null'? That "single #define line" would be repeated over and over in the code whenever you wanted to nullify more variables, And instead your way would be repeated over and over in runtime, which is exactly why it's less efficient. since your brain wants to use that method more rather than "waste space". Just saying that if you're already using a method to shorten something, you should, where able, at least make as efficient as the "no-shorts" version. In fact, if you really want to be efficient: M.Float=null; M.Image=null; M.Regen=null; M.Haste=null; M.Quick=null; M.Shell=null; M.Armor=null; M.Countdown=null; M.HP_Leak=null; M.Wall=null; M.Berserk=null XD. Good morning, mate! This is exactly what my #defines get compiled as. They just save you the typhing. | |
Jp wrote:
First off - You don't need to have a var/const at the start of a file. Yeah. I stated that. Secondly - You're not going to hit the variable limit unless you're doing something ridiculous. I [should of] stated that I don't care about that either, just like RAM. I just wanna have code more 'optimized', in the sense of "don't-use-vars-when-you-don't-have-to", and I'm sure he (Cencil [link]) is too. Thirdly - I have no idea why defines and constant variables are mixed like that in stddef.dm. Likely, because it was produced over time by various programmers. That's a good explanation. Belongs more in the respective topic I made though. >_> Even though that, the stddef is not that long, and is easy to unify #define/const usage once it's done (which it pretty much is). (Personally, I like to use var/consts, so I can do stuff like this:) > var/const/NORTH=1 Good point. Though if you're already presenting NORT & EAST as numbers, might as well just present NORTHEAST as the combined numbers and solve that issue. Though yeah, I understand your point. In the specific example you posted it looks ridicolous because every idiot would know that "northeast" == "north and east", but when using different #define names, people could be much more clueless. Though, should be able to be solved by a small //explanation after the #define. >_> Audeuro wrote: #define isn't just useful for macros, it's also useful for conditional compilation. Also true, slipped my mind. To clarify a bit more, code (anything) between the #if ( #ifdef is really short for #if defined() ) and the #endif is only read by the compiler if the #if expression was true, otherwise the compiler skips directly to the code beneath the #endif. | |
Kaioken wrote:
Er, dude, drop it. Sure, again, you frequently loop threw things and it doesn't freeze games, BUT all I'm saying is that this time looping is unnecessary, and not looping is indeed more efficient. I'm not arguing that not looping would be inefficent; I'm arguing that the code will become unreadable over time due to your weird method. which is going to be confusing in the future Of course the #define will be there in the future. Wether or not you'll understand the #define - sitting right in the middle of your code just so you can use it once to null a few variables - is another thing. and this all just so you can avoid having 0.0065 seconds of processing? No. I don't do it that way, I do it the way I prescribed at the bottom of my message. You gave a weird version of doing it, and I corrected you. My version may do this at runtime, but that doesn't make it any more or less efficent than your version: my version might lose efficency at runtime (0.0065 seconds of additional processing) but yours not only loses efficency at compile-time (another staggering 0.0065 seconds) but it also confuses the developer in the future because they have a bunch of #defines running around. God forbid the point in time where the developer forgets to #undef and ends up with brittle code. XD. Good morning, mate! This is exactly what my #defines get compiled as. They just save you the typhing. Your #defines are pointless and will confuse in the future. They're less efficent because the compiler has to spend additional time processing it. The best solution would be to use the one I provided and just do your "extra typing". Mind you it's not that much of extra typing, since with a few variables it's usually about the same length. And with that simple method, you too can benefit from the best possible efficency: no loss at all on both compile-time AND runtime! for(var/i=1 to 3) world<<"Hooray!" | |
You're just gonna keep repeating yourself, having me do the same? Refer to my last post.
The only new argument you presented is "longer compile time". Making the compile-time longer is not an efficiency problem; as it doesn't have any effect on the game itself. Anyway, however, what makes you entirely sure, that my code compiles slower than your code, which has a proc call, for() loop, and accessing associated list values? :P My #defines are less pointless than your approach. Both are designed to shorten the code, but yours harms performance. Rather, my approach is truly a 'shortcut', while your approach is additional, pointless code. But whatever, you can probably go on for ages like this, just drop this, you win. -_- Also, BTW, take your own advice. The for() loop you posted in your recent post is inefficient. :P
androiddata << "Hooray!\nHooray!\nHooray!"
| |
Good point. Though if you're already presenting NORT & EAST as numbers, might as well just present NORTHEAST as the combined numbers and solve that issue. Though yeah, I understand your point. In the specific example you posted it looks ridicolous because every idiot would know that "northeast" == "north and east", but when using different #define names, people could be much more clueless. Though, should be able to be solved by a small //explanation after the #define. >_> But then you have to work out what 1|4 is yourself. If you're doing more interesting operations, this might be harder then it is in this case. For example: var/const That is a random, pointless, not-exactly-useful example, but hopefully you get the point - this way, you don't have to work it out. Really, though, it's a matter of preference. | |