Re: An illuminating experiment using platform().

new topic     » goto parent     » topic index » view thread      » older message » newer message
Jim C. Brown said...
Jim C. Brown said...
Shawn Pringle B.Sc. said...

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.

Jim C. Brown said...

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu