Author Topic: Features Wishlist (Read 683662 times)

Freyaday · « **Reply #2910 on:** January 02, 2012, 04:50:18 pm »

Would it be possible to check if a constant has been defined in a preprocessor conditional?

Runer112 · « **Reply #2911 on:** January 02, 2012, 05:03:18 pm »

* Runer112 points to his post on the last page

Quote from: Runer112 on December 27, 2011, 12:46:13 pm

The addition of preprocessor conditionals was awesome, and I will find it very useful. But could there also be something similar to #ifdef? It would be useful for Axe libraries that allow the user to customize them by including defines in their own source code, and the library can fill in any defines with default values if the user didn't define them. The obvious solution would be a new command that determines whether or not the constant is defined. If you don't want to add a new command, you could also try something like the standard preprocessor conditional, but with the constant being used in a trivial comparison, like this:

...!If °Size≥0 8→°Size ...

Freyaday · « **Reply #2912 on:** January 02, 2012, 06:35:47 pm »

Oh! I didn't know that's what you meant.That syntax doesn't make any sense though. The address doesn't exist, it is undefines, it has no value. It's like asking if the color pi is greater than the yellow orange. It makes no sense.

Runer112 · « **Reply #2913 on:** January 02, 2012, 06:57:56 pm »

My idea was that any (unsigned) number in Axe is greater than or equal to 0, but NaN is not. But on second thought that syntax suggestion is sort of confusing. I guess a new command may be the best way to go.

Quigibo · « **Reply #2914 on:** January 02, 2012, 07:50:36 pm »

I'm not so sure if I want an "IfDef" type command. What's wrong with just defining a constant as 0 or -1 if its going to be unused? Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

parserp · « **Reply #2915 on:** January 02, 2012, 08:26:20 pm »

One question: in the poll, what is mode7?

annoyingcalc · « **Reply #2916 on:** January 02, 2012, 08:26:58 pm »

kind of like 3d

parserp · « **Reply #2917 on:** January 02, 2012, 08:27:29 pm »

Quote from: annoyingcalc on January 02, 2012, 08:26:58 pm

kind of like 3d

ahh thanks. That would be really cool

annoyingcalc · « **Reply #2918 on:** January 02, 2012, 08:28:02 pm »

I think so too

Runer112 · « **Reply #2919 on:** January 02, 2012, 08:44:59 pm »

Quote from: Quigibo on January 02, 2012, 07:50:36 pm

I'm not so sure if I want an "IfDef" type command. What's wrong with just defining a constant as 0 or -1 if its going to be unused? Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

The main purpose I can think of is, as I suggested in my original post, Axe libraries. Say you want to write a killer tilemapping library. You may need a bunch of different options to make it really versatile: tile width, tile height, black and white or grayscale, bits per tile, compression scheme, tileset pointer location, map pointer location, read from archive ability, smooth or rough scrolling, custom/variable buffer pointer, animated tile support... the list could go on. Being a true library, it's not proper to edit the library file itself. The user should specify customization settings in their own program.

Without something like an #ifdef, you would have to force the programmer to define a dozen different constants for features they don't need, or don't even know exist. If a new feature was added to the library down the road, their program would instantly be broken because it would need a new constant defined. And including all of these constants in their source would cause unnecessary headaches and source bloat that could be a hundred bytes or more.

Builderboy · « **Reply #2920 on:** January 02, 2012, 09:14:20 pm »

Another option would be to have Axe not disallow multiple constant defines. If two constants were defined, it would chose the first one encountered and ignore the rest. This would allow the same as what Runer is suggesting, but without any new commands.

Freyaday · « **Reply #2921 on:** January 02, 2012, 09:40:49 pm »

But that doesn't work if you want to have several programs with repeated data in them that you don't want duplicated when you compile them into one program.

Builderboy · « **Reply #2922 on:** January 02, 2012, 09:41:59 pm »

Quote from: Freyaday on January 02, 2012, 09:40:49 pm

But that doesn't work if you want to have several programs with repeated data in them that you don't want duplicated when you compile them into one program.

True I suppose, not throwing an error would made for some really annoying bugtesting if you unintentionally created a duplicate filename.

Quigibo · « **Reply #2923 on:** January 03, 2012, 12:09:08 am »

Quote from: Runer112 on January 02, 2012, 08:44:59 pm

Quote from: Quigibo on January 02, 2012, 07:50:36 pm
I'm not so sure if I want an "IfDef" type command. What's wrong with just defining a constant as 0 or -1 if its going to be unused? Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

The main purpose I can think of is, as I suggested in my original post, Axe libraries. Say you want to write a killer tilemapping library. You may need a bunch of different options to make it really versatile: tile width, tile height, black and white or grayscale, bits per tile, compression scheme, tileset pointer location, map pointer location, read from archive ability, smooth or rough scrolling, custom/variable buffer pointer, animated tile support... the list could go on. Being a true library, it's not proper to edit the library file itself. The user should specify customization settings in their own program.

Without something like an #ifdef, you would have to force the programmer to define a dozen different constants for features they don't need, or don't even know exist. If a new feature was added to the library down the road, their program would instantly be broken because it would need a new constant defined. And including all of these constants in their source would cause unnecessary headaches and source bloat that could be a hundred bytes or more.

But these can still be done without ifdef. You could have a constant defined as 0 for monochrome, 1 for 3-scale and 2 for 4-scale. If you are using monochrome you need not define the other constants required for 4-scale such as external buffer locations. Defines can be inserted into conditional comments as well which can be used to chain them and perform the logic you might need.

Another feature coming next version will be to preprocess more operations on constants than just +-*/^. These will include all signed/unsigned equality and comparisons, bit operations, and bit checking. This should make it easier for library writers.

Runer112 · « **Reply #2924 on:** January 03, 2012, 12:18:25 am »

My suggestion is that you should be to use #ifdef in a library to fill in defines with default values if the user doesn't define them. Say the user just wants a basic tilemapper. You'd probably expect that to default to a black and white 8x8 smoothscroller with 8 bits per tile, no compression, a static buffer (plotSScreen), no animated tile support, no support for reading tiles from archive, and so on. It would be a pain and possibly confusing for someone who just wants to use an easy, basic tilemapper to be forced to define a dozen different constants in their program just to say that he/she doesn't want to deal with the fancy stuff.

EDIT: Also, you said that you didn't want an IfDef type command. I'm not sure if you meant the idea of it being an individual command, or it existing entirely. If it's the former, you can still add this ability without an actual IfDef command by adding a command like Defined(), or as I suggested before, by using a trivial comparison like ≥0 in a preprocessor conditional. If it's the latter, I guess people will manage, it'll just require extra source code for users of customizable libraries.

Author Topic: Features Wishlist (Read 683662 times)

Freyaday

Re: Features Wishlist

Runer112

Re: Features Wishlist

Freyaday

Re: Features Wishlist

Runer112

Re: Features Wishlist

Quigibo

Re: Features Wishlist

parserp

Re: Features Wishlist

annoyingcalc

Re: Features Wishlist

parserp

Re: Features Wishlist

annoyingcalc

Re: Features Wishlist

Runer112

Re: Features Wishlist

Builderboy

Re: Features Wishlist

Freyaday

Re: Features Wishlist

Builderboy

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Runer112

Re: Features Wishlist