No "DataSection/EndDataSection" and a request

[Sylvia]

With each PureBasic-Update some superfluous orders disappear. When
does "DataSection/EndDataSection" disappear finally ? The Statement
"Data" should suffice however to the absolute identification of data !


And to it still a request:

In my projects i note them used PB-Version and hold them ready for the
later access.
However one has also a pool at Standard-Procedures and definitions
them with many PB-Updates rewritten must become. The test can take
still more time in claim

If from the Pool of PureBasic orders are removed, then please so, that
itself of the compilers nevertheless not at the exist of this Command
disturbs.
With it however PureBasic not that equal (constricting) kompatibilityproblem
suffers like Windows, would be it at least not badly, which kompatibility
respectively up to the next Mainversion to receive (e.g. should a program,
which written with the V3.01 became, at least still with V3.99 without
change in the code of the compiler accepted will)

[Kale]

With each PureBasic-Update some superfluous orders disappear. When does "DataSection/EndDataSection" disappear finally ? The Statement "Data" should suffice however to the absolute identification of data !

I disagree, DataSection should not dissapear, its not only used for actual Data statements but also included binaries, so they are included in the data section of the exe.

[blueznl]

you could actually *read* that?!? impressive...

[GedB]

Sylvia,

Have you considered using Tailbite to convert your standard library of routines into UserLibraries.

The big advantage of this is that Tailbite converts your PureBasic code into an ASM library. It will therefore not be affected by any future changes to the PureBasic syntax.

If you have to fix and recompile any of this libaries, you can deal with any compatability problems as needed.

[Fred]

How determine if a label is related to a data section then ? Or how put your binary or code in data or code section ? DataSection/EndDataSection is a must have and won't disappear (BTW, you can omit EndDataSection if you put your data at the very end of the code).

[freedimension]

The big advantage of this is that Tailbite converts your PureBasic code into an ASM library. It will therefore not be affected by any future changes to the PureBasic syntax.

Not exactly. All of your code will be compiled to PB, with the exception of PB Functions. They will be linked at compiletime of the source using your lib, thus preventing including them twice or more times.

[oldefoxx]

The addition of new features and content to a language, and in the increased range of commands, will always result in some conflict with existing code as external processes are gradually incorporated into the language itself.

Most people like the idea of adding procedures to a language that appear as though they are a part of the language itself. For instancem you could write a procedure to Sort() an array, and it looks like a part of the language. So it is tempting to use names that are dead ringers for the names that might eventually make it into the language itself.

Had you picked names that are unlikely to be used later, or chosen a naming convention that would normally be only used by yourself, then you could have avoided this. For instance, had you named this My_Sort(), then you would have been spared this problem.

Don't worry though, this is a common problem that most programmers run up against at least once. The trick is to use an editor with a Replace feature and go through your old source code, ranaming any user defined functions and calls to prevent this from happening when you run it under a later version of the compiler.

If you intend to take advantage of a new command, such as Sort(), then you may have an issue with the order or type of parameters being passed. Permitting the conflicts to continue under the new compiler can be a useful way to quickly find where the source code has to be modified or rearranged to take advantage of the new command.

An interesting aspect of some compilers is that they allow you to redefine existing commands and substitute your own procedures for ones that are part of the command set. This is not a particularly useful feature, but it does give programmers a chance to recodify the compiler to their own preferences.

[Kale]

An interesting aspect of some compilers is that they allow you to redefine existing commands and substitute your own procedures for ones that are part of the command set.

OMG what a horrible 'feature' 8O

[blueznl]

scary indeed...

oh well, i stick to my good old x_thisismyproceduresodonotmesswithitokay() approach... has served me for years...

[Doobrey]

OMG what a horrible 'feature' 8O

I dunno, could be quite usefull if you want to write one source to be cross compiled to different operating systems without loads of compilerifs etc..

[Soulfire]

What if the compiler retained the ability to successfully compile old code with new updates? For example, each source file includes the PB version number that the code was intended to be compiled with, and the compiler then uses the syntax, functions, and abilities of that particular version to compile the exe. When updates are released, new sources automatically use the latest version, but if a source was created (or otherwise altered) to be compiled with an older version, it would still be able to be compiled with the newest compiler without breaking the code.

[Kale]

What if the compiler retained the ability to successfully compile old code with new updates? For example, each source file includes the PB version number that the code was intended to be compiled with, and the compiler then uses the syntax, functions, and abilities of that particular version to compile the exe. When updates are released, new sources automatically use the latest version, but if a source was created (or otherwise altered) to be compiled with an older version, it would still be able to be compiled with the newest compiler without breaking the code.

Hmmm... nice and bloaty! 8O

[oldefoxx]

the problem is, as always, with those slightly out-of-touch with what is going on. If previous versions are maintained, then previous compilers and help files would be needed, and if people are comfortable with an older version and continue to use it, then what is to keep them from continuing to request new features and fixes to the older version without regard for the fact that these have already been incorporated in the latest version? If you suggest that they upgrade to the latest version, then the grumbling starts all over again, and they want to know why they can't combine aspects of the old version with the new version, and then if something doesn't come off the way they expected, they complain because it's buggy or too difficult to manage.

Users always have the choice of keeping older versions alongside the most current version, by setting up different sets of folders each time they install or upgrade. you can rename the base folder by version number, such as PB3.81 and create a new PureBasic folder for the most current release. If you need the old version for an upgrade, you just duplicate everything from PB3.81 into PureBasic, and go from there.

For myself, I usually just keep major releases. I have a history with PowerBasic, so I have folders named PB32, PB35, PBCC20, PBCC21, PBCC30, PBDLL60, PBDLL61, and PBWIN70, along with a buch of related folders. I can grab a source file from any of these, and attempt to compile it under any other version. If it works, fine. If it doesn't, I can either work with it under a version that it compiles with, or go through the effort to rewrite portions to make it work under a different version. Either way, my choice, my effort. Since I organized it myself, I should have some idea of the merit and gain to me by employing a system like this.