Not allow defining constants twice

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
Justin
Addict
Addict
Posts: 829
Joined: Sat Apr 26, 2003 2:49 pm

Not allow defining constants twice

Post by Justin »

Currently you can do this

#FOO = 10
#FOO = 10

It will only raise an error if you define it with a diferent value, it is a problem when you have to define OS constants that are not defined, you will not recieve a warning if they are defined later.

You can do this even is already defined
#WM_ACTIVATE = 6

So i have to use this workaround for every OS constant:

Code: Select all

Macro _definec(c, v)
CompilerIf Not Defined(c, #PB_Constant)
#C = V
CompilerEndIf
EndMacro 

User avatar
Josh
Addict
Addict
Posts: 1183
Joined: Sat Feb 13, 2010 3:45 pm

Re: Not allow defining constants twice

Post by Josh »

-1

Where's your problem, if you have a constant in your code, which is natively known to Pb? If the constant is later introduced in Pb, then it does not bother if your constant is also present in the code and the code will work with older Pb versions as well.

In the opposite direction, it would cause great problems if constants could not be defined multiple times, e.g. if the same constant is needed in different include files.
Last edited by Josh on Sun Jun 17, 2018 7:52 pm, edited 1 time in total.
sorry for my bad english
DontTalkToMe
Enthusiast
Enthusiast
Posts: 334
Joined: Mon Feb 04, 2013 5:28 pm

Re: Not allow defining constants twice

Post by DontTalkToMe »

This would be criminal.

So including something with 100 constants where 70 of these are already in PB residents would cause the compiler to complain 70 times and I would have to delete anything already defined, even if with the same value, from the include.
And then if other 5 constants are added in a subsequent PB version, I would have to edit the include again to remove them.
And if I have to replace the include with an updated version, because it's an include with OS constants and some new constants are added in a new version of the OS, I have to convert it into a PB include and again remove all the constants already defined in PB.
Just imagine to do the same with DirectX, OpenGL, etc.
Every program including converted headers partially overlapping with PB residents would became uncompilable and a nightmare to maintain.
Currently you can do this

#FOO = 10
#FOO = 10
I hope so.
It will only raise an error if you define it with a diferent value,
I hope so.
it is a problem when you have to define OS constants that are not defined, you will not recieve a warning if they are defined later
And why it's a problem ?
You can do this even is already defined
#WM_ACTIVATE = 6
I hope so.
So i have to use this workaround for every OS constant:
Why ?

Not gonna happen, constants need to be definable twice with the same value.
User avatar
skywalk
Addict
Addict
Posts: 3972
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Not allow defining constants twice

Post by skywalk »

As mentioned, this is required to allow include files with their required constants.
math.pbi #PI2 = #PI + #PI
complex.pbi #PI2 = #PI + #PI
etc.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Dude
Addict
Addict
Posts: 1907
Joined: Mon Feb 16, 2015 2:49 pm

Re: Not allow defining constants twice

Post by Dude »

skywalk wrote:As mentioned, this is required to allow include files with their required constants.
math.pbi #PI2 = #PI + #PI
complex.pbi #PI2 = #PI + #PI
etc.
^ This. One of my apps might include "math.pbi" only, and another might include "complex.pbi" only, but a third might include both. I don't want to have edit both files all the time due to whatever an app is including.

So my vote is: -1
Justin
Addict
Addict
Posts: 829
Joined: Sat Apr 26, 2003 2:49 pm

Re: Not allow defining constants twice

Post by Justin »

The point was to throw a warning for predefined constants in a resident file, like other compilers do like ms c++, to lessen the work for the pb compiler and ide, have smaller includes.. windows.h is big.

But i recognize in this particular scenario of incomplete big header files there would be a lot of warnings for some people :D

I guess i will end making a parser that checks the includes against the res files.
Post Reply