What about the performance of printf vs some object oriented printing.

I would like

IO.WriteLn "A=", A, " and then B=", B, " and then C="

to be as fast as

printf( "A=%d and then B=%d and then C=%d", A, B, C );

In C++, it is no where near as fast and can never be as fast.

How do D and LX stack up when it comes to writing huge amounts of formatted data?

Christophe de Dinechin wrote:
> 
> 35/ printf rules?
> 
> printf sucks. Really. I could write 218918231231 pages on this.
> 
>     -- Unformatted IO
>     IO.WriteLn "A=", A, " and then B=", B
> 
>     -- Formatted IO
>     IO.WriteLn A format "A=####", B format "B="#5.9#"
> 
>     -- Definition of WriteLn
>     generic type writable if
>         with writable W
>         IO.Write W
> 
>     procedure WriteLn() is
>         Write Unicode.CR
> 
>     procedure WriteLn(writable X; others) is
>         Write X
>         WriteLn others
> 
> Now, if you really care about the printf formatting idiotisms, you can implement that in LX too. Not that I would recommend it...
> 
> Christophe

How does LX compare when it comes to runtime (

see also the "What is the D runtime like?" thread).

Specifically (reposting my last post to the above thread):

What does that mean with regards to:

running programs that contain LX modules from multiple LX compiler versions
   features especially if the object model changes between the two?
   what about stuff like GC?
running programs that have a C mainline and are linked with the C linker.
running programs that have a C++ mainline?
running a D module in a kernel?
running a D module as a COM inproc component?

Christophe de Dinechin wrote:
> 
> Interestingly, my background is close to that of Walter: I also developed video games for a living, I also worked on a commercial C++ implementation, and I also designed my own language, called LX. More information on LX can be found at http://mozart-dev.sf.net.
> 
> So I am going to start a big series of post to try to compare D and LX. To avoid polluting the newsgroup too much, I am going to try to post all of them under the same thread.
> 
> I am obviously biased. On the other hand, I believe there is much to be gained if we exchange ideas and compare designs. Please bear with me...
> 
> Christophe

Oops, I started changing references from D to LX below and didn't get all the way through.  All of the questions pertain to LX, not to D.

Phil Brooks wrote:
> 
> How does LX compare when it comes to runtime (
> 
> see also the "What is the D runtime like?" thread).
> 
> Specifically (reposting my last post to the above thread):
> 
> What does that mean with regards to:
> 
> running programs that contain LX modules from multiple LX compiler versions
>    features especially if the object model changes between the two?
>    what about stuff like GC?
> running programs that have a C mainline and are linked with the C linker.
> running programs that have a C++ mainline?
> running a D module in a kernel?
> running a D module as a COM inproc component?
> 
> Christophe de Dinechin wrote:
> >
> > Interestingly, my background is close to that of Walter: I also developed video games for a living, I also worked on a commercial C++ implementation, and I also designed my own language, called LX. More information on LX can be found at http://mozart-dev.sf.net.
> >
> > So I am going to start a big series of post to try to compare D and LX. To avoid polluting the newsgroup too much, I am going to try to post all of them under the same thread.
> >
> > I am obviously biased. On the other hand, I believe there is much to be gained if we exchange ideas and compare designs. Please bear with me...
> >
> > Christophe

Phil Brooks wrote in message <3BA147BC.DA11B7AB@mentor.com>...
>How do D and LX stack up when it comes to writing huge amounts of formatted data?

D will support use of printf(), other methods may be supplied via the
runtime library.

This is where I disagree.

The compiler doesn't need a separate interface and implementation.  It should be able to find the whole declaration (in D, the declaration and definition are the same thing) and figure out what the public, accessible parts are (the interface)

If you link in a library, you don't even need the source as long as you have parse info built into the .obj files.  This is how Java and C# and most modern languages work.  It saves the programmer the tedium of maintaining two different parts of the source that say the exact same thing.

If one were inclined, the IDE could extract the parse info from the .obj files and show the programmer a trimmed down, publics-only source file automatically, on request.  Or the IDE class browser could have an option to hide everything but publics.  Or the library author could include such a publics-only, no-implementation source file for distribution, merely for programmer reference purposes because the compiler wouldn't need it.

Question for Walter:  If there were such a thing as forward declaration in D, what would the syntax be?  This is only so I could write such a IDE browser tool that showed functions in a standard way.

Sean

"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7C9418.23275491@earthlink.net...
> 14/ Declaration vs. Definition - Modularity aspect
>
> Good modularity sometimes imply that you don't make the implementation details public. LX has clearly separate interface and implementation, with a 'body' keyword that allows the kind of repetitions required in C++.
>
>     -- Interface, in file fact.lxs
>     function factorial(integer N) return integer
>
>     -- Body, in file fact.lxb. 'body' replaces all arguments
>     function factorial body is
>         ...
>
> For completeness, let me also indicate that what LX allows you do to with any object is what the interface says, regardless of whether you see the implementation. No 'private' parts. The exception is for types, where knowing the implementation gives you access to it.
>
>     -- Type interface
>     type complex with
>         real Re, Im
>         out real Rho, Theta
>
>     -- This is legal just seeing the above
>     function Re(complex Z) return real is
>         return Z.Re
>
>     -- Type definition (possibly another file)
>     -- Notice there is no Rho and Theta fields
>     type complex body is
>         real Re, Im
>     -- So we need to tell the compiler what to do when the user does Z.Rho
>     function Rho(complex Z) return real written Z.Rho is
>         return Math.sqrt(Z.Re^2 + Z.Im^2)
>
>
> Christophe
>
>

Why not just "synch" or "sync" ?   ;)  Long keywords == more typing.

Sean

"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7C9867.C7F4A052@earthlink.net...
> 21/ Synchronize
>
> I am afraid that your approach to multitasking is too simplistic. In addition, I believe that multitasking belongs to the library, not to the language. LX will offer a multitasking library at some point, which I started discussing from an interface point of view on my web page somewhere. Most notably, with pragmas, you ensure that this seems integrated in the language, yet it remains outside of it.
>
>     {synchronized} array Buffer[0..1023] of byte
>
> The Ada community discovered the hard way that building a given tasking model into the language was convenient, but ultimately closed too many doors. Real-time multitasking doesn't require the same primitives as web-server applications...
>
> A possible use in LX of a tasking model implemented in a library can be found at http://mozart-dev.sourceforge.net/lx_tasking.txt. It tries to mimic the "Ada" feel of tasking, but that's just one possible model. The Java feel is actually much simpler to implement :-)
>
> PS: I promise, if I ever complete a tasking library, it will have {synchronized} and {synchronised}, as well as {sincronised} for the spelling-impaired :-)
>
>
>
> Christophe

Question:

If you have a class

class A
{
  this() { ... }
  ~this() { ... }
}

Is a struct that contains one of these possible?

struct S
{
  A a;
}

If so, that makes structs have implicit destructors.

Sean

> It's actually not that bad in practice. Remember that C++ has "finally" clauses too, it's just that they are hidden (implicitly generated by the compiler). The compiler builds finally clauses for each stack allocated object that has a destructor.
>
> I never much liked the hidden bloat generated by that. It's a major reason why D has no stack allocated class objects, and "finally" clauses are explicit.

Sean L. Palmer wrote in message <9r1rj3$2etr$1@digitaldaemon.com>...
>Question for Walter:  If there were such a thing as forward declaration in D, what would the syntax be?  This is only so I could write such a IDE browser tool that showed functions in a standard way.


Forward references would look just like in C:

    int foo();

> Forward references would look just like in C:
> 
>     int foo();

I think strictly ansi speaking this is not a valid prototype, strict C wants to have it look like this:

int foo(void);

This post now thoroughly cleansed of nits.  ;)

Sean

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9r35rp$5ls$2@digitaldaemon.com...
>
> > Forward references would look just like in C:
> >
> >     int foo();
>
> I think strictly ansi speaking this is not a valid prototype, strict C wants to have it look like this:
>
> int foo(void);