| View previous topic :: View next topic |
| Author |
Message |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
 Posted: Tue Dec 20, 2005 2:40 am Post subject: sprintf equivalent in Mango |
 |
|
How do I do this?
I know DisplayWriter has print and println for formatted output, but I'm confused.
Do I use the same class to apply formatting to a string? It's somewhat difficult to see how this is done without an example. I believe there's a mention of it somewhere in the docs, but I don't see any demonstration of sprintf-like features.
Thanks,
John |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Dec 20, 2005 3:01 am Post subject: |
|
|
Yes!
Absolutely perfect. Those are the kind of examples I was looking for.
Thanks!
-JJR |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Dec 20, 2005 3:13 am Post subject: |
|
|
It's perhaps worth noting that Sprint is unicode enabled at the argument level (handles char/wchar/dchar arguments) and is templated for how you want the output too. For example, you can instantiate a dchar Sprint which will give you dchar[] output.
The other distinction between the templated types has to do with the format-string type (the first argument), which reflects the type of the template. That is, a char-based Sprint expects a Utf8 format string; whereas a dchar one expects a utf32 format string.
All of mango.convert is templated like this ~ you can twist it to your needs.
Lastly, Sprint et. al. emit content as array-slices instead of one character at a time. This makes them reasonably efficient. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Dec 20, 2005 9:26 pm Post subject: |
|
|
| JJR wrote: | | Those are the kind of examples I was looking for |
Are you compiling on linux, John? |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Dec 20, 2005 10:44 pm Post subject: |
|
|
I was working on Windows, ATM. But I would need it to work on Linux too. Thus, I'll need to test it on Linux at some point. Is there a difference on Linux? Or do you just need it tested there?
-JJR |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 21, 2005 1:04 am Post subject: |
|
|
Was interested if you were trying the linux build. There were a couple of compile errors fixed recently for linux, so I wondered if you'd just ignored them 
Linux build should be good via SVN. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 21, 2005 8:21 am Post subject: |
|
|
| I'll try compiling Linux Mango with Ares also. I was pleasantly surprised that the Win32 version compiled smoothly using "version=Ares" this time. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 21, 2005 11:50 am Post subject: |
|
|
| JJR wrote: | | I'll try compiling Linux Mango with Ares also. I was pleasantly surprised that the Win32 version compiled smoothly using "version=Ares" this time. |
There's been a couple of times where I renamed the dmd\src\phobos directory, to make sure the compiler would not look in there and then get confused. Other than that it's been plain-sailing. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 21, 2005 12:00 pm Post subject: |
|
|
All I had to do was remove the reference to phobos in sc.ini; replace that with the Ares path... and away it goes.
Also, it looks like Sean added std.stdarg to Ares in a recent update; so that error is no longer an issue.
I think it would be nice, though, to add a simple build option to Mango to make only mango.io into a lib, for those that just want that part for now. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 21, 2005 12:41 pm Post subject: |
|
|
| JJR wrote: | | I think it would be nice, though, to add a simple build option to Mango to make only mango.io into a lib, for those that just want that part for now. |
Is that because some things don't build for the lib? Or because of lib entry conflicts? We could add version() to buld/mango.d but perhaps there's a different problem needing attention? |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 21, 2005 12:59 pm Post subject: |
|
|
| kris wrote: | | JJR wrote: | | I think it would be nice, though, to add a simple build option to Mango to make only mango.io into a lib, for those that just want that part for now. |
Is that because some things don't build for the lib? Or because of lib entry conflicts? We could add version() to buld/mango.d but perhaps there's a different problem needing attention? |
For neither reason. I just think mango.io is useful in and of itself apart from the rest. But then again, I guess it's not so independent anymore. I guess it would pull in things like convert, Unicode translation, and such. I just meant that it would be nice to use the IO stuff by itself. But that would only be an advantage if it allowed total program size to be smaller. Perhaps it really makes no difference, and the linker includes just the objects from the library required by the pogram? If that's so, disregard this vacant thought. It's probably of no relevance.  |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 21, 2005 1:19 pm Post subject: |
|
|
I think it's worth exploring a bit
The linker is supposed to pull in only the external labels referenced ~ one can imagine this happening recursively. Thus, if you import certain parts of mango.io, you may also see convert.Unicode linked (as you say, there's a dependency on the Unicode support within Stdin and Stdout). On the other hand, Mango is pretty good about interdependencies ~ if you try examples/hello.d you'll see what I mean?
Ultimately, it should make no difference how much is actually in a library. Still, I generally don't use mango.lib anymore since the compiler is so fast ~ and the resulting binaries are usually a bit smaller for whatever reason. Odd! Perhaps the librarian rounds up segment sizes, or something? I have noticed that the minimum executable-size increment is 512 bytes ~ there seems to be some rounding going on (beyond the file system). |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 21, 2005 9:23 pm Post subject: |
|
|
| kris wrote: | | Ultimately, it should make no difference how much is actually in a library. Still, I generally don't use mango.lib anymore since the compiler is so fast ~ and the resulting binaries are usually a bit smaller for whatever reason. Odd! Perhaps the librarian rounds up segment sizes, or something? I have noticed that the minimum executable-size increment is 512 bytes ~ there seems to be some rounding going on (beyond the file system). |
Interesting you mention this because my observations have been similar. It does appear to be more efficient to use the build utility to construct the executable.
I really don't know why but linking with a library causes the final product to balloon hugely. I believe this is the case on both Win32 and Linux. Perhaps these observations are what got me thinking of partitioning Mango into a mango.io library.
But, as you mention, build does a good enough job for the most part. There really is no need for a separate library because of it. Perhaps, though, an alternative would be possible at some point via DDL that would make use of libraries advantageous, in some respect, again? That way the executable can be guaranteed small and runtime linking of symbols can occur as necessary throughout the executable. Or that just may be overkill on this matter? (Is it even possible to runtime link with library files using DDL? Or does that only work with a shared library? On linux, of course, this is practically a non-issue; on win32, I have no idea what DDL is capable of for *.lib files).
Quick OT question: how does DDL load up type symbols, such as a class or struct? I'm used to thinking of variables and functions as being loaded from a library. But how do you load up a typename (or template for that matter) from a library and create the appropriate object in ones own program? Perhaps this is beyond the scope of DDL?
-JJR |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Wed Dec 21, 2005 10:25 pm Post subject: |
|
|
| JJR wrote: | | kris wrote: | | Ultimately, it should make no difference how much is actually in a library. Still, I generally don't use mango.lib anymore since the compiler is so fast ~ and the resulting binaries are usually a bit smaller for whatever reason. Odd! Perhaps the librarian rounds up segment sizes, or something? I have noticed that the minimum executable-size increment is 512 bytes ~ there seems to be some rounding going on (beyond the file system). |
Interesting you mention this because my observations have been similar. It does appear to be more efficient to use the build utility to construct the executable.
I really don't know why but linking with a library causes the final product to balloon hugely. I believe this is the case on both Win32 and Linux. Perhaps these observations are what got me thinking of partitioning Mango into a mango.io library. |
I think it's just OPTLINK being lazy and not doing a very good job of figuring out what modules in the .lib need each other, and which ones are just dead weight. Why this is, exactly, is a mystery to me. I'm sure if I tried writing my own compile-time linker I'd find out real quick. 
Personally, I'm the laziest of the bunch: I just dump a /mango source tree under my project where I'm working and let build sort it out. I never touch sc.ini. As a nice side-effect, it makes sure that older projects have a version-appropriate copy to compile against.
| Quote: | | But, as you mention, build does a good enough job for the most part. There really is no need for a separate library because of it. Perhaps, though, an alternative would be possible at some point via DDL that would make use of libraries advantageous, in some respect, again? That way the executable can be guaranteed small and runtime linking of symbols can occur as necessary throughout the executable. Or that just may be overkill on this matter? (Is it even possible to runtime link with library files using DDL? Or does that only work with a shared library? On linux, of course, this is practically a non-issue; on win32, I have no idea what DDL is capable of for *.lib files). |
You bet it can handle them! DDL handles both the .lib and .obj flavors of OMF files, and COFF files.
Trivia: the OMF .lib format is really just a bunch of OMF .obj files stored back-to-back with a dictionary pasted on the end. Its technically feasable to go back-and-forth between the two formats. Its also possible to map any and all internal dependencies within a lib, hence all the head-scratching.
It is nice to have .lib files for DDL since it makes mapping your dependencies a bit easier, plus it makes for some rather clean code. It makes deployment easier too. But, there is a stiff penalty: you get the whole thing sitting around in RAM, regardless if parts of it are really needed or if they're redundant with what's already in the .exe (in the case of phobos.lib and snn.lib).
The next direction I'm taking things is to develop some kind of file-path-based loader so that loose .obj files can be located as they are needed (like Java and .class files). So at the cost of searching, you get a smaller memory footprint *and* you no longer need .libs (in theory at least).
| Quote: |
Quick OT question: how does DDL load up type symbols, such as a class or struct? I'm used to thinking of variables and functions as being loaded from a library. But how do you load up a typename (or template for that matter) from a library and create the appropriate object in ones own program? Perhaps this is beyond the scope of DDL? |
That's tough to answer without completely threadjacking this conversation. I wish I had some tutorials set aside for this kind of thing. Just message me or start a thread over on DDL if you're still curious after this.
Take a look at this first:
http://www.dsource.org/forums/viewtopic.php?p=7130#6735
And then this:
http://www.dsource.org/forums/viewtopic.php?p=7130#6871
The former is the no-frills interface. The latter is somewhere between the low-level nature of DDL (as it currently stands) and a full-on reflection system (*very* possible, just not implemented).
So say you want to load an instance of your class Foobar, which is provided in a foobar.obj that you load and link at runtime. To create a Foobar you can:
- Use the technique mentioned above by looking for the right __Class
- Acquire a factory method/function from the library, then call it to create a Foobar.
- Acquire a static field that has already been established as an instance of Foobar via that module's static this().
At present, there is no facility to look up things by typename; but all the nuts-and-bolts are there to get something like that working.
Also, templates are a non-starter: they have to be instanced before they can be compiled and linked.
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
