PB Compiler Directives

[Cliff Nichols]

I am working on cleaning up some of my code made in the past, and still allow for backwards compatibility and have run into some minor details that I would like to get your take on if it should be submitted to PB for possible changes.

I probably already know MCM's take on it. But would like others input.

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
100  ERROR 69
     SELECT CASE %PB_REVISION
          CASE > = &H900
MSGBOX "PB Version = " + LEFT$(HEX$(%PB_REVISION), 1) + "." + MID$(HEX$(%PB_REVISION), 2) + $CR + "Error at " + ERL$
          CASE < &H900
MSGBOX "ERL$ is not available in PB version " + LEFT$(HEX$(%PB_REVISION), 1) + "." + MID$(HEX$(%PB_REVISION), 2)
     END SELECT
END FUNCTION

Now this is NOT a "Bug" / NOT an Error / NOT a mistake, but just something that did not exist in PB 8.04 and therefore will not compile in 8.04 because "ERL$" did not exist then.

Would a NFS be in order for future compilers to somehow account for compilers farther in the future to use or not to use keywords? IE: If this were the days of 8.04 to somehow account for what we now know as ERL$ ???

Or is there already a way to determine if ERL$ exists in the compiler?
Its just a thought of minor things that may need a change (if it can be changed) that I have run across.

[Conrad Hoffman]

I'm more a fan of forward compatibility than backward. Once we're a few revisions ahead, why would you want to go back? Right now 9.01 is the latest and greatest, but sometime you'll be using version 11.02 and think 9.01 is archaic. Version 8 won't even be on the radar. What's important to me is that old code compile with the new compilers, hopefully with zero or near-zero changes, and so far that's been the case. Where it isn't, suitable warnings have been put in the docs about things that may not be supported in the future, so I try to follow best practice and update my code.

[Cliff Nichols]

I'm more a fan of forward compatibility than backward.

I am of the same, but I often see users that are using older versions for various reasons, like if they can not afford a current copy (and I see NO reason why they could not afford it), or just waiting to see if the current version is stable enough for them to want to upgrade.

To Me, PB is a GRAND "Odd-Duck" in the world of compilers since each version I have seen is never rushed out the door, and documentation is complete (or as complete as possible) unlike other products I have seen out there.

That said, I am looking at code I may have written as far back as PB6 and upgrading to knowledge I have now, that I did NOT have back then (GAWWWD WHAT a NEWBIE, my code was back then)

IF for some god-forsaken reason I would ever want to compile code back then that does not exist till now, maybe I would have built in conditions for checking for keywords that I did not even know would exist in the future.

Probably a lil Over-Anal, but it was a passing thought that I figured I would ask about.

[Michael Mattias]

>probably already know MCM's take on it.

I have no 'take' on it.

Dealing with new versions of compilers is something I've done for more than twenty years, or even longer if you count some of the mainframe code I worked on where those programs had not been touched in twenty years... the executables worked, so why worry about abilty to compile it? (Until someone wanted a change!).

While some of the IBM mainframe compilers supported directives such as..

  COBVERSION(68)

.. allowing the use of 1968 syntax in a nominally '74 or '85 compiler, these were $40,000 compilers: no such thing as a $99.00 upgrade option.

Basically, the only way to keep the PB compilers backward compatible is to not upgrade.

Recently (there's a post on it in Cafe Forum) I had problems with backward compatibility between 7x, 8x and 9x ... with (of all things!) when ERR is set when the VARPTR function is used. (The 7x behavior apparently was a bug in that version, since the behavior was removed in 8x).

And there have been other 'non-keyword' changes across versions.... IF and SELECT CASE did unsinged integer comparisons in 6x, and have done signed comparisons since. Array descriptors for UDT arrays also changed in 7x. Goodness knows how many times DIALOG DOEVENTS and "console size" have changed, even within versions. Regular expression behavior has changed ('\s', anyone?)

IMO the only way you can plan to change compiler versions with any update or upgrade is to plan on retesting everything in its entirety.

The one indispensible tool available if source code must be compilable by multiple versions of the compiler is conditional compilation... and the only way you can solve your specific challenge above (function not supported in prior version).

#IF %PB_VERSION AND &h0900 THEN 
    use 9x code
#ENDIF

Note that the compiler directive #ELSE is not backward compatible, nor are the relational tests ">=<" so this can get a little hairy depending on what you are doing.

(Also with lots of vesions, the "AND" test can be a problem eg two odd versions will AND to TRUE).

MCM

[John Petty]

I am of the same, but I often see users that are using older versions for various reasons, like if they can not afford a current copy (and I see NO reason why they could not afford it), or just waiting to see if the current version is stable enough for them to want to upgrade.

So as an affluent American, I assume you will donate upgrades to those of us for whom the cost is much higher as America has done such wondeful things recently to our economies and currencies
Whilst that can be an important issue, there is also the issue that there is not yet a truely compatible version of PB Forms available. Sort of like upgrading the engine of a car and not inreasing the strength of the gearbox etc to match the extra power of the engine

[Michael Mattias]

those of us for whom the cost is much higher as America has done such wondeful things recently to our economies and currencies

"Our" being ?????

Please add your location to your Forum profile so we Yanks can know whom we are upsetting this week.

MCM

[Conrad Hoffman]

IMHAO (in my humble American opinion) PowerBASIC itself and all future upgrades are free. In fact, it's almost like Bob Zale pays me! You see, the thing is a powerful tool for making money, if you choose to put it to that use. Surely you've heard the expression, "find a need and fill it". OK, they were probably talking about sex, but, find a need and write a program for it. Solve one problem for one organization and there's your upgrade plus a few coins. You can write the upgrade off and the government takes the remaining coins for taxes.

[John Petty]

"Our" being ?????

Please add your location to your Forum profile so we Yanks can know whom we are upsetting this week.

MCM

My post was a continuation of this tongue in cheek post http://www.powerbasic.com/support/pb...ad.php?t=38222
so it was not possible to purchase at AUD101 for the upgrade and the price went as high as AUD163 which made Bob not one cent more or cost Cliff or you one cent more.
As for your exact question Christopher Carrol has now created a thread in the Cafe which is the appropriate place, so I will post there and I eagerly await your participation.

[Cliff Nichols]

I know it was at least partly in jest but no clue as to

it was not possible to purchase at AUD101 for the upgrade and the price went as high as AUD163

no idea what a AUD101 or 163 are????

PowerBASIC always upgrades that recent of a full product purchase at no cost. That's been our published policy for many years.

Perhaps it would be a good idea to check it out first? A short email to [email protected] could work wonders. {smile}

Best regards,

Bob Zale
PowerBASIC Inc.

I think Bob put it succinct enough of trying to be a fair business person and do "Whats fair is FAIR" (The Legend of Billie Jean (1985)

[Barry Erick]

If you are trying to make it bacwards compatible, then you are distributing the source. Let the user make a workaround for missing statements just like everyone who wanted that function does.

One thing to consider is to be using keywords to find a version. If a keyword did not exist, someone may have used it in their program that they have your source with.

From the help file:

For determining the compiler version (see %DEF for more information):

%PB_CC32, %PB_DLL16, %PB_DLL32, %PB_EXE, %PB_REVISION, %PB_REVLETTER, %PB_WIN32

[Michael Mattias]

>If you are trying to make it bacwards compatible, then you are distributing the source

Not necessarily....

The trouble I reported (with VARPTR/ERR) was in an #INCLUDE file (whcih is never distributed unless separately licensed) which I compile with PB/Win 7x for one application and with PB/WIN 9x for others, and PB/CC 4x or 5x (I forget) for yet another.

Of course, my problem was not with COMPILING... it compiled fine, but the same statements/functions behaved differently....infinitely more frustrating.

I did have some COMPILATION issues with an #INCLUDE file due to changes between 8x and 9x in some of the COM syntax, but if I can find those problems at compile time it's a lot better than finding them at runtime.

[John Petty]

no idea what a AUD101 or 163 are????

I hope you are joking too. I know many Americans are parochial, but for a programmer to not recognise one of the six largest freely traded currencies in the world is surprising. Many countries call their currencies Dollars, so the American is USD, Canadian CAD, Australian AUD etc. There are many others.
I am continually amused be people who advertise products on international web sites in $'s, I am always tempted to pay in SBD (Solomon Island Dollars as they are worth about 12.5 US Cents or HKD (Hong Kong Dollars) at about 13 US Cents

[Christopher Carroll]

Three-letter codes to describe currencies are an ISO standard: ISO 4217.

Don't worry about not knowing that the only dollar is a United States one , as that pales into insignificance compared to a) all dates are of format MM/DD/YY[YY], b) there is only 1 set of characters needed in programs called ASCII, c) all addresses require ZIP codes, and d) the only burger is a McDonalds!