[Implemented] Macro Redefinition (override)

[grabiller]

Hi,

I've searched through the forum and did not find anything (sorry in advance if I've missed something).

One great addition to PureBasic could be the ability to redefine macros, either implicitly or explicitly.

So having:

Code: Select all

Macro Plop
a
EndMacro
; then somewhere else:
Macro Plop
b
EndMacro

Wouldn't be a problem.

This would allow us to use some code differently depending on the context of the code, simply by overriding the macros.

Cheers,
Guy.

[Kukulkan]

For me, please don't! What a nightmare to have two macros with same name and different functionality...

Kukulkan

[grabiller]

For me, please don't! What a nightmare to have two macros with same name and different functionality...

Kukulkan

It's not a nightmare if you know what you are doing, this feature would be terribly powerfull.

At least, perhaps, explicitly, meaning you would have to use "MacroUndef Plop" for instance so you wouldn't override a Macro unintentionaly.

Would that be ok with you ?

Cheers,
Guy.

[Josh]

+ 1

http://www.purebasic.fr/english/viewtop ... ilit=macro

[Kukulkan]

It's not a nightmare if you know what you are doing, this feature would be terribly powerfull.

It might be if you are a single developer knowing all your sources even after years. But we are a complete team. We use a lot of include files with functions and macros for different purposes. I believe it will be a desaster if someone is creating a macro in an include that overwrites functionality of another macro in a different source. EnableExplicit has been invented to exactly prevent such problems with variables and a good compiler should also complain about two macros with the same name.

Anyway, if such a feature will come up, please make it an option that explicitely must get activated.

Kukulkan

[Shield]

It's not that after that you'll have two macros with the same meaning.
After a macro has been undefined it will simply not exist anymore.
If you then create a new macro with the same name, the old macro will be replaced.

This is how stuff works in C / C++ for years and this feature is used quite excessively,
for example by standard headers such as Windows.h.

Now, I don't say the use of such a feature macro is good practice, but, after all, it is a feature
and it can come in handy sometimes, if you know what you are doing.

If a person doesn't know what he / her is doing, that person shouldn't be programming anyway.

[BorisTheOld]

@grabiller

Bad Idea

If Plop is a single line macro then use Plop(x) notation to modify the generated code.

And if Plop is a multiline macro then use procedures - the amount of code would be about the same.

What you're suggesting is not "terribly powerful", it's just terrible. I've seen this sort of thing done before, and the aftermath is not something you'd wish on your worst enemy.

[Tenaja]

If there is a separate command (i.e. UnDefMacro X or ReMacro X, etc), then it IS a good idea. Nothing that expands the power of PB, and retains its backwards compatibility, is a BAD idea.


What may be a "better" request for enterprise level development is a way to "localize" macros to a specific file. Perhaps similar to EnableExplicit, such as EnableLocalized, which would be used at the top of an include file. That would make it so nothing was global unless specifically listed. Fred would "merely" have to prepend the filename to the macroname in his parse table.

[grabiller]

@grabiller

Bad Idea

If Plop is a single line macro then use Plop(x) notation to modify the generated code.

And if Plop is a multiline macro then use procedures - the amount of code would be about the same.

What you're suggesting is not "terribly powerful", it's just terrible. I've seen this sort of thing done before, and the aftermath is not something you'd wish on your worst enemy.

I think you simply don't get it, I mean the use for this.

When working on heavy code/application, this could be a time/code saver as it is in C/C++.

For instance, if you have a long list of enumeration and you want to have the enumeration and a datasection of strings synchronized, you could use something like that:

Code: Select all

Macro ENU_LIST
  ENU_DEF( #RAA_ERR_INVALID,      "invalid"      )
  ENU_DEF( #RAA_ERR_NULL_POINTER, "null pointer" )
  ; etc..
EndMacro

Macro ENU_DEF( ec_, es_ )
  ec_
EndMacro
Enumeration
  ENU_LIST
EndEnumeration

; (MacroOff ENU_DEF / MacroUndef ENU_DEF / ..)
Macro ENU_DEF( ec_, es_ )
  Data.s es_
EndMacro
DataSection
  error_strings:
  ENU_LIST
EndDataSection

; (MacroOff ENU_LIST / MacroUndef ENU_LIST / ..)

And this can be much more complex than that.

This is *terribly* powerfull, I've used this so many times in C/C++ without any problem, on the contrary, this leads to cleaner code and less mistake (a forgotten enumeration string, etc..)

This can be applied to 'Class' definitions, and a multitude of other things.

Cheers,
Guy.

[BorisTheOld]

Clever, but I'm not convinced.

Allowing runtime redefinition of macros is too much like self-modifying code. Sure it's a powerful technique, but screw-ups can be a disaster, and debugging can be a nightmare.

Schedules, budgets, and sanity go out the window, and this is not something that should be encouraged.

[grabiller]

Clever, but I'm not convinced.

Allowing runtime redefinition of macros is too much like self-modifying code. Sure it's a powerful technique, but screw-ups can be a disaster, and debugging can be a nightmare.

Schedules, budgets, and sanity go out the window, and this is not something that should be encouraged.

Well, from my experience the use of Macro redefinition in C/C++ in practice leads to exactly the opposite.

Less bugs, cleaner and shorter code, faster development, more robust and consistant result, happier developpers and clients.

But again, if you don't know what you are doing, using macros redefinition, using pointers, using bad named variables or procedures, using FASM, using a programming language, using a car, a motorcycle, walking in the streets, you can allways screw-up, and this can be a disaster, and 'debugging' can be a nightmare, yes, and those activities shouldn't be encouraged.

But what about those who do ? Should they live in a safeguarded room for the rest of their live ? I don't think so.

Cheers,
Guy.

[BorisTheOld]

Still not convinced.