On 13.02.2012 10:33, Walter Bright wrote:
On 2/12/2012 11:45 PM, Alf P. Steinbach wrote:
Anyway, I haven't yet started delving into the language documentation
or any
tutorials, just used gut-feeling, so I'd appreciate discussion of how
to make
this my first D console program less non-idiomatic <g>:
<code>
import std.stdio;
import std.ascii;
import std.string; // chop
//import core.sys.windows.unicode_based_api; <-- DOES NOT WORK.
There is no D import with the name unicode_based_api. Where does that
name come from?
It's the name of the module generated by the program, just more clean
aliases for the Unicode based Windows API functions -- e.g., in C++
one would write `MessageBox`, not `MessageBoxW`, so I alias them.
By the way, I see that the list of functions provided by
core.sys.windows.windows is rather short, covering a very small fraction
of the API:
How would one go about extending that?
For a console app that just reads and writes files, there shouldn't be a
need to access the Windows API at all. The D runtime library does that
for you.
Oh, you'd be surprised.
The Windows console is a pretty dirty thing, especially wrt. Unicode for
the standard streams, so considering that Microsoft's own Visual C++
runtime doesn't get it right I doubt that the D runtime does. Yet. :-)
Anyway, testing the generated module involves first of all getting it to
work as a module. I do not yet have the foggiest idea about how D
building works, except compiling individual source files. I just thought
it doesn't matter which program it's used from then, so I put the
`import` in the generating program.
Cheers &
- Alf
