1. An illuminating experiment using platform().
- Posted by Shawn Pringle B.Sc. Jul 12, 2008
- 875 views
The topic of platform() getting depricated has come up again. If there is one thing that should be depricated it is the depricate function. It keeps getting called at random and is only useful for breaking software.
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example:
include os.e if platform() = WIN32 then printf(1, "Hello Windows", {} ) end if if platform() = DOS32 then printf(1, "Hello DOS32", {} ) end if if platform() = LINUX then printf(1, "Hello LINUX", {} ) end if
Okay, so we will expect to see a comparison in the C code jumping over some display code after we compile. A branch seems like a little thing but some say that it is too ineficient to let us keep it. Just for curiosity, lets see how the branch is implemented. Is it a goto? I translated it using the options -plat DOS -wat and got this:
// ifdef WIN32 then
// if platform() = WIN32 then
// if platform() = DOS32 then
// printf(1, "Hello DOS32", {} )
EPrintf(1, _1153, _10);
L1:
// if platform() = LINUX then
Cleanup(0);
So, as you can see, the EPrintf() is there to replace the EUPHORIA printf but only the DOS32 version is there. The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
2. Re: An illuminating experiment using platform().
- Posted by Jeremy Cowgar Jul 12, 2008
- 882 views
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Yes, when translating there is no cost, however, platform() is used in interpreted applications as well. In addition the ifdef system does things platform() could not touch. For example:
while next_line() do ifdef DEBUG then printf(1, "Processing line: %s\n", {line}) end ifdef -- normal code end while
Now, here is the code that the interpreter or translator sees when running...
$ exu -D DEBUG myprog.ex
while next_line() do printf(1, "Processing line: %s\n", {line}) -- normal code end while
$ exu myprog.ex
while next_line() do -- normal code end while
Notice this works on something that has nothing to do with platform(). Also notice it works in the interpreter or translator.
Now, further ifdef can do things like this:
ifdef EU400 then export function super_41_function() return 10 end function end ifdef
This is a 4.1 Euphoria application that maintains backward compatibility with 4.0. It's assuming that the function super_41_function() was added in 4.1 and did not exist in 4.0. The uses of ifdef are vast compared to the very limited usefulness of platform(). Further, platform() is generally flawed when it comes to dealing with Linux and FreeBSD. Why? Because they are not the same. FreeBSD has a set directory structure that Euphoria apps should pay attention to. It could enable the use of different FreeBSD facilities, etc... Even DLL loading is slightly different on FreeBSD than Linux. The ifdef handles these types of checks much better than platform()...
ifdef FREEBSD then -- FreeBSD ONLY elsifdef LINUX then -- Linux ONLY elsifdef OSX then -- OS X ONLY elsifdef WIN32 then -- WIN32 ONLY elsifdef DOS32 then -- DOS32 ONLY end ifdef
Now, what if you just want to know if you should use cp or copy ? Easy.
ifdef UNIX then -- FreeBSD, Linux or OS X else -- Right now only DOS32 or WIN32 end ifdef
Now, if that is not enough, you can define your own words to accomplish all sorts of tasks.
function save() ifdef SHAREWARE then if record_count = 100 then alert("You have reached the limits of the shareware version") return 0 end if end ifdef -- Save the record end function
So, when you bind or translate your app for shareware versions, it contains limits. Or maybe it doesn't contain features:
ifdef not SHAREWARE then -- feature that is not in shareware version end ifdef
This totally prevents someone from hacking your shareware version because there are no features to hack! That's just an example. Now, you could also do things such as:
ifdef SAFE then include safe.e else include machine.e end ifdef
Or, how about choosing a database include?
ifdef PGSQL then include pgsql.e as db elsifdef MYSQL then include mysql.e as db elsifdef SQLITE then include sqlite.e as db end ifdef db:conn db_con = db:open("host=localhost name=mydb") db:query(...) db:close(db_con)
Which is exactly what I do right now, I have pgsql.e, mysql.e and sqlite.e that expose the identical interface, thus, I have a Euphoria app that can run any db I want. The possibilities are endless if ifdef and platform() has no advantage over ifdef. Oh, and in case you are thinking shrouded apps, I think we have a way that ifdef will work just fine in shrouded apps as well.
So, why use platform()? I have no clue.
Jeremy
3. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 12, 2008
- 876 views
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example: <snip> The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
Agreed. However, platform() has two flags which make it inferior to the platform detection support available via ifdef.
First, ifdef supports using UNIX and making finer distinguishment via LINUX/FREEBSD/OSX (and perhaps more to come). platform() is inconsistent, with the builtint version only separating OSX from UNIX.
Second, platform() is inconsistent. The machine_func(53) call will return a 3 on OSX but the builtint platform() returns a 4. At one point in time, both versions of platform returned a 4 for FreeBSD.
It is possible to clean up platform() and give it the ability to tell you if you are just on a UNIX, or tell you more fine grained information (linux vs osx vs bsd). This will never happen since we have the ifdef system now.
4. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 12, 2008
- 864 views
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example: <snip> The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
Agreed. However, platform() has two flags which make it inferior to the platform detection support available via ifdef.
That should read flaws, not flags.
First, ifdef supports using UNIX and making finer distinguishment via LINUX/FREEBSD/OSX (and perhaps more to come). platform() is inconsistent, with the builtint version only separating OSX from UNIX.
Second, platform() is inconsistent. The machine_func(53) call will return a 3 on OSX but the builtint platform() returns a 4. At one point in time, both versions of platform returned a 4 for FreeBSD.
It is possible to clean up platform() and give it the ability to tell you if you are just on a UNIX, or tell you more fine grained information (linux vs osx vs bsd). This will never happen since we have the ifdef system now.
In summary, platform() and machine_func(53) are inconsient with each other. So both versions are arguably broken.
This is why you should move to ifdef.
The only reason to pick platform() is for backwards compatibility. But since its broken, I don't see it being easily kept backwards compatible for long.
On a side note, I discovered that the same platform() optimization applies to the IL code, not just the C translated code. So even if you use platform(), shrouded (i.e. IL) code can not be run under multiple platforms, only under the platform it was shrouded for.
5. Re: An illuminating experiment using platform().
- Posted by Shawn Pringle B.Sc. Jul 12, 2008
- 887 views
- Last edited Jul 13, 2008
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example: <snip> The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
Agreed. However, platform() has two flags which make it inferior to the platform detection support available via ifdef.
First, ifdef supports using UNIX and making finer distinguishment via LINUX/FREEBSD/OSX (and perhaps more to come). platform() is inconsistent, with the builtint version only separating OSX from UNIX.
Second, platform() is inconsistent. The machine_func(53) call will return a 3 on OSX but the builtint platform() returns a 4. At one point in time, both versions of platform returned a 4 for FreeBSD.
It is possible to clean up platform() and give it the ability to tell you if you are just on a UNIX, or tell you more fine grained information (linux vs osx vs bsd). This will never happen since we have the ifdef system now.
You give some good examples of how flexible ifdef is: Especially for DEBUG and defining functions. It is not a question of speed but flexibility of what you can do at parse time.
You haven't explained why anyone should care if machine_func(53,{}) and platform() return the same result or not. Who has ever heard of machine_func(53,{}). I don't think it is necessary and I do think it is a bad idea to remove something that already exists and is relied on just because there is a more capable method now.
It is rather analogous to banning radio because people can go buy tvs.
Shawn
6. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 12, 2008
- 866 views
- Last edited Jul 13, 2008
You give some good examples of how flexible ifdef is: Especially for DEBUG and defining functions. It is not a question of speed but flexibility of what you can do at parse time.
Right, the value of ifdef is independent from its use to differenciate between platforms. That's a secondary property of the ifdef.
You haven't explained why anyone should care if machine_func(53,{}) and platform() return the same result or not. Who has ever heard of machine_func(53,{}).
It is machine_func(M_PLATFORM) and it was used for platform() in misc.e before platform() became a builtin. Basically they should be the same function, otherwise the results might be confusing.
I don't think it is necessary and I do think it is a bad idea to remove something that already exists and is relied on just because there is a more capable method now.
It is rather analogous to banning radio because people can go buy tvs.
Shawn
You make a good point. machine_func(M_PLATFORM) has been decapricated since before Euphoria went FOSS, and it is still in there. It is also suffering from bitrot.
7. Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 845 views
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Which is exactly what I do right now, I have pgsql.e, mysql.e and sqlite.e that expose the identical interface, thus, I have a Euphoria app that can run any db I want. The possibilities are endless if ifdef and platform() has no advantage over ifdef. Oh, and in case you are thinking shrouded apps, I think we have a way that ifdef will work just fine in shrouded apps as well.
So, why use platform()? I have no clue.
Jeremy
For cross compilation purposes.
I'm on a Windows platflrom, and wish to output code that might run under Unix. An ifdef WIN32 statement will indeed cut off any Unix specific code, and the code won't ever show up in generated IL.
The easiest way out is to distribute ckear source code, so that it is ILed on the same machine where it will run. Perhaps some licensing agreement about using some third party code will prevent that. Or perhaps your app is payware, so there must be some copy protection.
platform() is obviously less versatile than ifdef. But it is the only currently known way to defer cutting code off whie having parsed it already, and still distribute only one file. Cross-translating is fine, but then you must distribute as ùmany executables as psupported platforms.
If we had a deferred_ifdef, then platform() could be deprecated.
CChris
8. Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 837 views
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example: <snip> The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
Agreed. However, platform() has two flags which make it inferior to the platform detection support available via ifdef.
That should read flaws, not flags.
First, ifdef supports using UNIX and making finer distinguishment via LINUX/FREEBSD/OSX (and perhaps more to come). platform() is inconsistent, with the builtint version only separating OSX from UNIX.
Second, platform() is inconsistent. The machine_func(53) call will return a 3 on OSX but the builtint platform() returns a 4. At one point in time, both versions of platform returned a 4 for FreeBSD.
It is possible to clean up platform() and give it the ability to tell you if you are just on a UNIX, or tell you more fine grained information (linux vs osx vs bsd). This will never happen since we have the ifdef system now.
In summary, platform() and machine_func(53) are inconsient with each other. So both versions are arguably broken.
This is why you should move to ifdef.
The only reason to pick platform() is for backwards compatibility. But since its broken, I don't see it being easily kept backwards compatible for long.
On a side note, I discovered that the same platform() optimization applies to the IL code, not just the C translated code. So even if you use platform(), shrouded (i.e. IL) code can not be run under multiple platforms, only under the platform it was shrouded for.
Hmm right.
This changes my earlier statement to:
- platform() has no advantages over ifdef, so it could be deprecated or dropped;
- there is an even stronger case for a deferred_ifdef statement, which would cause code selection at execution time, whether translated or shrouded, and not at initial parse time.
CChris
9. Re: An illuminating experiment using platform().
- Posted by Jeremy Cowgar Jul 13, 2008
- 846 views
So, why use platform()? I have no clue.
For cross compilation purposes.
I'm on a Windows platflrom, and wish to output code that might run under Unix. An ifdef WIN32 statement will indeed cut off any Unix specific code, and the code won't ever show up in generated IL.
I do not fully understand what you are saying here. Are you saying that the cross-translation sets up the wrong PLATFORM ? If so, that's a bug that needs to be fixed.
platform() is obviously less versatile than ifdef. But it is the only currently known way to defer cutting code off whie having parsed it already, and still distribute only one file. Cross-translating is fine, but then you must distribute as ùmany executables as psupported platforms.
Why would you want that? Also, if you are not cross-translating, then what are you doing? ifdef works just fine in interpreted applications as well. There is no need what-so-ever to translate to make ifdef work.
] If we had a deferred_ifdef, then platform() could be deprecated.
What exactly would deferred_ifdef do that cannot be done with ifdef?
Jeremy
10. Re: An illuminating experiment using platform().
- Posted by Derek Parnell Jul 13, 2008
- 835 views
I do not fully understand what you are saying here.
How can I create an executable, targeted for Linux, on my Windows environment?
11. Re: An illuminating experiment using platform().
- Posted by Jeremy Cowgar Jul 13, 2008
- 835 views
I do not fully understand what you are saying here.
How can I create an executable, targeted for Linux, on my Windows environment?
We have cross-translator abilities. The cross-translator should be defining UNIX, LINUX when on a Windows machine during the translation process. This shouldn't be a problem at all. I am not saying their is not a bug in it. I have not tried this process. However, I am saying that if it does not work then it is a bug that is easily fixed.
Jeremy
12. Re: An illuminating experiment using platform().
- Posted by Shawn Pringle Jul 13, 2008
- 833 views
Hmm right.
This changes my earlier statement to:
- platform() has no advantages over ifdef, so it could be deprecated or dropped;
- there is an even stronger case for a deferred_ifdef statement, which would cause code selection at execution time, whether translated or shrouded, and not at initial parse time.
CChris
What is the semantic difference then betweeen deferred_ifdef and if?
Shawn
13. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 13, 2008
- 836 views
I do not fully understand what you are saying here.
How can I create an executable, targeted for Linux, on my Windows environment?
ecw.exe -GCC -PLAT LINUX thesource.exu
These last two steps assume you have MSYS or some similar environment installed, as well as a gcc cross compiler:
sed.exe -i s/gcc/i686-unknown-linux-gnu-gcc.exe/g emake
sh.exe emake
14. Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 846 views
I do not fully understand what you are saying here.
How can I create an executable, targeted for Linux, on my Windows environment?
We have cross-translator abilities. The cross-translator should be defining UNIX, LINUX when on a Windows machine during the translation process. This shouldn't be a problem at all. I am not saying their is not a bug in it. I have not tried this process. However, I am saying that if it does not work then it is a bug that is easily fixed.
Jeremy
This (probably) works. It requires creating as many exeecutables as targeted platforms.
What I am talking about is canned IL, which is what shrouding outputs. If the code being shrouded has an ifdef WIN32, its else part won't be parsed. Fine if I want that IL to execute under Windows. Less fine if I want the IL to execute under Unix.
deferred_ifdef would parse all the alternatives, and make notes about where each starts and ends. When InputIL() is invoked on the target platform, it will cut the unnecessary IL off, so that the backend will execute _as if_ the ifdefs had been resolved on the same machine.
One file to distribute, no parse time. The added decoompression overhead is negligible, unless there are a ton of ifdefs.
If you want more speed, then have straight exevcutables by cross translation. The deferred_ifdef route would be a very convenient intermediate step between plain source and plain .exe .
CChris
15. Re: An illuminating experiment using platform().
- Posted by Jeremy Cowgar Jul 13, 2008
- 955 views
This (probably) works. It requires creating as many executables as targeted platforms.
Yes, which is what most people do when distributing applications. Usually they have an installer and offer pre-compiled binaries.
What I am talking about is canned IL, which is what shrouding outputs. If the code being shrouded has an ifdef WIN32, its else part won't be parsed. Fine if I want that IL to execute under Windows. Less fine if I want the IL to execute under Unix.
deferred_ifdef would parse all the alternatives, and make notes about where each starts and ends. When InputIL() is invoked on the target platform, it will cut the unnecessary IL off, so that the backend will execute _as if_ the ifdefs had been resolved on the same machine.
That would take away almost any benefit of ifdef? Then, how would you decide if you want to use ifdef or deferred_ifdef ? And this is only for shrouded code? i.e. interpreted, bound or translated code will all work fine with ifdef.
One file to distribute, no parse time. The added decoompression overhead is negligible, unless there are a ton of ifdefs.
A shrouded file only runs if the user has downloaded Euphoria for their platform and installed it. Do most applications expect the user to do this? Sure, it's fine for developers, but users?
I would suggest that having defered_ifdef would be pretty confusing and counter productive.
Jeremy
16. Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 810 views
Hmm right.
This changes my earlier statement to:
- platform() has no advantages over ifdef, so it could be deprecated or dropped;
- there is an even stronger case for a deferred_ifdef statement, which would cause code selection at execution time, whether translated or shrouded, and not at initial parse time.
CChris
What is the semantic difference then betweeen deferred_ifdef and if?
Shawn
if checks at run time which branch to take. deferred_ifdef parses all options at parse time. Only the one which is valid on the target machibe gets its IL to the bacjend.
In addition, other defines might be taken in account by deferred_ifdef, while platform() is limite d in scope.
CChris
17. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 13, 2008
- 859 views
deferred_ifdef would parse all the alternatives, and make notes about where each starts and ends. When InputIL() is invoked on the target platform, it will cut the unnecessary IL off, so that the backend will execute _as if_ the ifdefs had been resolved on the same machine.
One file to distribute, no parse time. The added decoompression overhead is negligible, unless there are a ton of ifdefs.
If you want more speed, then have straight exevcutables by cross translation. The deferred_ifdef route would be a very convenient intermediate step between plain source and plain .exe .
CChris
If I understand correctly then, its basically an ifdef that is outputed into the IL and then interpretered by the backend at run time....
It is possible to take IL and reverse engineer it into almost the original euphoria source code quite easily. I think there is a tool provided to do this. We no longer seem to have shrouding as in the old days where the source was completely hidden (or scrambling?). I therefore do not think having a deferred_ifdef solely for the benefit of shrouded code makes sense. If it benefits translated or interpreted code as well, then it could still be worthwhile.
For interpreted code, we don't need the ifdef to be deferred, since from the user's point of view parse time is the same as run time. So no benefit here.
For translated code, the deferred_ifdef would need to be parsed and evaluated before the conversion to C code anyways. (Even if it wasn't, the result C code is only expected to work on a single platform, so there is no benefit to preventing optimization.) If we care, a similar argument applies to the case of bound executables.
So it looks like a deferred_ifdef only helps the shrouded code case be more portable. The use of raw IL files seems to be rare.
If we had a way to cross-compile IL files, and perhaps do cross-binding, I'd say there was no need for an deferred_ifdef even for shrouded code.
18. Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 819 views
deferred_ifdef would parse all the alternatives, and make notes about where each starts and ends. When InputIL() is invoked on the target platform, it will cut the unnecessary IL off, so that the backend will execute _as if_ the ifdefs had been resolved on the same machine.
One file to distribute, no parse time. The added decoompression overhead is negligible, unless there are a ton of ifdefs.
If you want more speed, then have straight exevcutables by cross translation. The deferred_ifdef route would be a very convenient intermediate step between plain source and plain .exe .
CChris
If I understand correctly then, its basically an ifdef that is outputed into the IL and then interpretered by the backend at run time....
It is possible to take IL and reverse engineer it into almost the original euphoria source code quite easily. I think there is a tool provided to do this. We no longer seem to have shrouding as in the old days where the source was completely hidden (or scrambling?). I therefore do not think having a deferred_ifdef solely for the benefit of shrouded code makes sense. If it benefits translated or interpreted code as well, then it could still be worthwhile.
For interpreted code, we don't need the ifdef to be deferred, since from the user's point of view parse time is the same as run time. So no benefit here.
For translated code, the deferred_ifdef would need to be parsed and evaluated before the conversion to C code anyways. (Even if it wasn't, the result C code is only expected to work on a single platform, so there is no benefit to preventing optimization.) If we care, a similar argument applies to the case of bound executables.
So it looks like a deferred_ifdef only helps the shrouded code case be more portable. The use of raw IL files seems to be rare.
If we had a way to cross-compile IL files, and perhaps do cross-binding, I'd say there was no need for an deferred_ifdef even for shrouded code.
You got it right. The use of raw IL files is rare because of:
- it wasn't possible at all before 3.0, which isn't too old;
- the platform issues were, and are, there.
Cross-output of IL, ie telling Eu that OSX is defined and WIN32 isn't ven though IL is output under Windows, would take care of the issue. And make use of raw IL more frequent, as it solves any parse time issues.
CChris
19. Re: An illuminating experiment using platform().
- Posted by Jeremy Cowgar Jul 13, 2008
- 818 views
Cross-output of IL, ie telling Eu that OSX is defined and WIN32 isn't ven though IL is output under Windows, would take care of the issue. And make use of raw IL more frequent, as it solves any parse time issues.
I'm not really convinced of this. Who would use IL code? Not end users, only developers. Now, would developers really use IL code? I would want source. I wouldn't use IL code and I suspect that will be the opinion of most, but don't want to speak solely for them, so speak up if you disagree.
Now, let's say that you do have a product that you distribute to your end users and you want to give them IL code for some reason. You have presumably (hopefully) already had to give them a platform dependent copy of euphoria. Thus, you are already maintaining platform dependent installs. Further, you have hopefully provided the end user with an installer? Further making your install platform dependent.
Now, let's say you do not give them euphoria and you do not give them an installer and just a bunch of IL files in a zip file and leave the rest up to them. Wow... what percentage of applications is this actually? 1%? 0.1%?
I do not see how distributed IL code is beneficial. I see great benefit in distributing bound and translated code. I suspect that we will begin to see much more translated code out there because it's so easy and because it's totally free now. Both in Euphoria and with open source compilers. OpenWatcom is literally cake to install. gcc comes with Linux/FreeBSD platforms so there is not even the need to do that there.
Jeremy
20. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 13, 2008
- 817 views
You got it right. The use of raw IL files is rare because of:
- it wasn't possible at all before 3.0, which isn't too old;
- the platform issues were, and are, there.
Cross-output of IL, ie telling Eu that OSX is defined and WIN32 isn't ven though IL is output under Windows, would take care of the issue. And make use of raw IL more frequent, as it solves any parse time issues.
CChris
Ok. Cross-output of IL seems to be the more generic solution. This is what we should go for.
21. Re: An illuminating experiment using platform().
- Posted by Jim C. Brown Jul 13, 2008
- 825 views
Cross-output of IL, ie telling Eu that OSX is defined and WIN32 isn't ven though IL is output under Windows, would take care of the issue. And make use of raw IL more frequent, as it solves any parse time issues.
I'm not really convinced of this. Who would use IL code?
Cross-output of IL is a prerequite of cross-binding (binding an .exe from a GNU/Linux box for example). With cross compilers its possible to use a single box of one platform to go from eu source to executable for a completely different platform. I do not believe that we have this flexibility when creating bound executables.
22. Re: An illuminating experiment using platform().
- Posted by Unkmar Jul 13, 2008
- 836 views
The topic of platform() getting depricated has come up again. If there is one thing that should be depricated it is the depricate function. It keeps getting called at random and is only useful for breaking software.
Seriously, there is little cost involved using platform() as compared to say ifdef with the correct parameters. I wrote a seven line program called example:
include os.e if platform() = WIN32 then printf(1, "Hello Windows", {} ) end if if platform() = DOS32 then printf(1, "Hello DOS32", {} ) end if if platform() = LINUX then printf(1, "Hello LINUX", {} ) end if
Okay, so we will expect to see a comparison in the C code jumping over some display code after we compile. A branch seems like a little thing but some say that it is too ineficient to let us keep it. Just for curiosity, lets see how the branch is implemented. Is it a goto? I translated it using the options -plat DOS -wat and got this:
// ifdef WIN32 then
// if platform() = WIN32 then
// if platform() = DOS32 then
// printf(1, "Hello DOS32", {} )
EPrintf(1, _1153, _10);
L1:
// if platform() = LINUX then
Cleanup(0);
So, as you can see, the EPrintf() is there to replace the EUPHORIA printf but only the DOS32 version is there. The branches that include platform() = to other platforms are not even included.
There is absolutely no branching cost of using platform() rather than ifdef when translating to C.
Shawn Pringle B.Sc.
Let's take a look at a slightly more realistic issue.
include os.e for idx = 1 to 123456 if platform() = WIN32 then printf(1, "Hello Windows", {} ) end if if platform() = DOS32 then printf(1, "Hello DOS32", {} ) end if if platform() = LINUX then printf(1, "Hello LINUX", {} ) end if end for --Versus ifdef for idx = 1 to 123456 ifdef WIN32 then printf(1, "Hello Windows", {} ) end ifdef if DOS32 then printf(1, "Hello DOS32", {} ) end ifdef ifdef LINUX then printf(1, "Hello LINUX", {} ) end ifdef end for
The platform() example remains as 3 if tests for all 123456 iterations of the idx loop. The ifdef gets reduced to a single print statement within the loop. I believe that we can all clearly see that it will execute many times faster. It simply has less to do. Some of you will say that this isn't a realistic example. Imagine that, instead of it being a for loop. It is a procedure or function that contains the ifdef or platform() test. Maybe sockets for Windows versus Linux. With platform(), every time the function is called, the decision must be made. However, using ifdef, the decision is made once and only the applicable code is applied.
Unkmar - Lucius L. Hilley III
PS: Creole did not wish to allow me to format my signature to my liking. Apparently {{{ must be on a line all by itself.
23. Re: An illuminating experiment using platform().
- Posted by Unkmar Jul 13, 2008
- 829 views
Effectively, He wants platform() to work in shrouded code.
Unkmar
24. Use of {{{ in messages
- Posted by Derek Parnell Jul 13, 2008
- 844 views
Creole did not wish to allow me to format my signature to my liking. Apparently {{{ must be on a line all by itself.
There may be some confusion with resect to {{{ }}} tags.
This tag is known as the non-wiki tag. Its purpose is to prevent translating any wiki (creole) tags enclosed by the braces into HTML. It comes in two forms - inline and block. When used inline the text it encloses is put into the output without translatation and placed inside <tt> ... </tt> HTML tags. The block form also prevents translation but puts the output text inside <pre> ... </pre> tags.
Example of inline mode :
The following asterisks should display and **not** be translated into bold, but this should be bold.
Example of block mode :
The **asterisks** are displayed and not translated.
If the effect you wanted was to have your signature show up in monospaced font, inline with the test of the text, the use ## markup instead.
Eg. Your Signature is now monospaced.
25. Re: An illuminating experiment using platform().
- Posted by Unkmar Jul 13, 2008
- 836 views
Who would use IL code? Not end users, only developers. Now, would developers really use IL code? I would want source. I wouldn't use IL code and I suspect that will be the opinion of most, but don't want to speak solely for them, so speak up if you disagree.
snip
Jeremy
Some developers will release IL code. They will think of it as shrouding. Mind you, it is rather pointless.
Ask Liquid Nitrogen what I did to his bound copy of Lemon Heads. This was before shrouding was possible. Back then, the euphoria code ended up with all functions and variables renamed to meaningless names. Comments were stripped and all includes became part of the code. All the pretty indentions and whitespace was also removed. This ugly representation of the original code was then appended to the end of the interpreter.
I discovered where the values of health and so forth where and created an invincible character that was no longer limited to 3 shots on screen at a time along with automated firing. And I did all this before the debinding or whatever it was called was created and released.
My point. If you use IL to hide your code, and someone really wants that code. They will get it pretty easily. Shrouding made it not worth my while to get the code. However, I'm not a full force cracker with leet abilities.
UnkmarPS: Preview is your friend.
26. Re: Use of {{{ in messages
- Posted by Unkmar Jul 13, 2008
- 840 views
Nope, I think what I wanted and just realized is indent.
:Unkmar