On 30 Sep, 2004, at 23:27, Mars Saxman wrote:
I'd agree that there is no such thing as a "little C++ compiler", or
even a
"little C++ parser", but C is a lot simpler. Do the Win32 API
libraries use
any C++ language features? I wrote an app once that did almost exactly
what
you've described, but for 68k-era Mac OS Toolbox headers. It wasn't
that big
a deal; I think I spent about a month's worth of free time writing the
parser and macro preprocessor.
In addition, there are freely available C grammars suitable for use
with
bison or yacc. If you're willing to write the translation app in C, or
at
least write the core of the translation algorithm in C as an RB
plugin, you
can pretty much skip the parser and just write the data tables and code
generator. I won't claim it would be trivial, but it's nowhere near the
complexity of a real compiler, and it would be a good introductory
project
for someone who is interested in compiler techniques.
What's more, a parser-driven approach doesn't have to be platform
specific;
a single tool could generate Declare statements for header files from
Mac
OS, Windows, or Linux.
I've written compilers before; I finished one recently which was for
HLSL, a C-like dialect for programming graphics hardware. It's parsing
front-end was generated with Bison. I needed to process the programs
into an intermediary format so that I could produce extra HLSL code to
glue them together.
The problem with translating the Win32 APIs into something that would
be nice to work with from the RB side is all the heuristics we'd need
to work into such a compiler to recognise patterns which would be
better implemented with some additional RB glue code. For instance, the
A vs W Win32 API functions for narrow and wide strings. This isn't too
complex an example, but would still require some heuristic to recognise
this case and insert RB code to hide the A/W split and work with just a
string being passed in. There are also functions which take what should
be arrays, but you only know are arrays by looking at the MSDN
documentation. There'd be no way of noticing procedurally that a given
BLAH* pointer is actually meant to be an array, and thus the RB
function should have a prototype which specifies an array, and the glue
code converts the array into a MemoryBlock, etc. You'd need to provide
some extra info on the semantics of the function which aren't
immediately apparent from the headers.
These flourishes which make the APIs more usable in RB are not things
you want to manually add in afterwards to the auto-generated code, as
you would lose them every time you run the C->RB converter again.
I've been writing a lot of OpenGL Declares recently, too, and have
found it easier to just do it manually with some help from GLEW (since
I don't have Soft Declare in RB 5.5) than it would have been to write
them using a procedural tool like SWIG. Win32 APIs don't change much,
nor do the majority of the OpenGL APIs, so it's not like you get much
benefit by being able to recreate the whole API set using your tool
each time after you've once written them.
It's not that such a parser wouldn't be feasible given time, but that
it is a large undertaking to make work effectively to reach the holy
grail of automatic C->RB declare generation; problem more work than
just dividing the Win32 APIs amongst an infinite number of monkeys and
throwing people at the problem :-)
That isn't to say that if such a tool did once come into being that I
would be adverse to using it.
--
Kind Regards,
James Milne
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://www.realsoftware.com/listarchives/lists.html>
|