"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b9brks$7sd$1@digitaldaemon.com...
> In Sather, you could simply accept $OB and then do something like:
>
> typecase some_arg
> when INT then
>     #OUT + "Got Integer: " + some_arg;
> when FLT then
>     #OUT + "Got Float: " + some_arg;
> when $STR then
>     #OUT + "Got String: " + some_arg;
> end;
>
> The typecase statement tries to cast the object to diffrent types and allows to do type-dependant actions. It may also contain an else-branch.

This is much like 'instanceof' in Nice: http://nice.sourceforge.net/safety.html

In D, that could be make work like this:

    class A { ... }
    class B : A { ... }

    void foo(A a) {
          if (cast(B)a) {
                // in this scope, 'a' is casted to B.
          }
    }

The mechanism does not seem to be fully functional in Nice yet. I don't know if it causes any problems.

Regards,
Martin M. Pedersen

Some good ideas there.

"Richard Krehbiel" <rich@kastle.com> wrote in message news:b9bilf$2uu6$1@digitaldaemon.com...
> In news://news.digitalmars.com/a7d9d2$qtv$1@digitaldaemon.com I wrote up a type-safe varargs proposal:
>
>
> Start with the function declaration:
>
> void printf(char[], PrintfParam args...)
> {
> // Function body
>
>
> "type args..." is like "type args[]" but signals that the compiler should collect up the arguments into the array. "type... args" should be a synonym of "type args..." just as "type[] array" is the same as "type array[]". The body of this function treats args as if it were a regular dynamic array, because it is.
>
> When a user codes:
>      char[] name = "Cecil";
>      printf("My name is %s\n", name);
>
> ..the compiler does the equivalent of this:
>
>     PrintfParms[] _t;
>     _t[0] = new PrintfParms(name);
>     printf("My name is %s\n", _t);
>
> Rules:
>
>      Each function argument must be implicitly compatible with the
> argument type; else,
>
>      Each argument must be convertible to the argument type via the
> type's constructor; else,
>
>      The argument's not valid and the compiler prints an error.
>
> Only the final parameter to a function can be varargs, just like C.
>
> I like this better than the universal VARIANT type that VB uses, since that way allows programmers to pass types that the function doesn't expect, and/or requires the called function to expect every type.  The argument type only needs constructors for types it can deal with.
>
> You can't make a varargs function in C which is allowed to take zero arguments.  But with this method, you can:  void NoArgs(Type args...) could be called with no arguments, and would receive a zero-length array.
>
> "<type> args..." is implicitly compatible with "<type> args[]" and, as such, can be passed around between functions, like C's va_list can.  But it's even better: you can write code to construct the a "<type> args[]", but you *can't* construct a va_list in C except by calling a varargs function.

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EB74DD5.53F278D6@chello.at...
> > C++ iostreams got it right.  They totally separate the stream
buffer/device
> > from the stream formatting/insertion/extraction.  That way is so much
more
> > flexible.
> But this IO is very costly and adds a lot to the C++ bloat.

I agree. iostreams is both bloated and slow.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b96mc5$15eh$1@digitaldaemon.com...
> Walter wrote:
> > ... Me, I always thought printf should just be built in to the operating system, so every program shares one copy.
> Microsoft compilers, as well as LCC-Win32 and MingW32 make use of this
one:
> MSVCRT.DLL

That's not really building it into the operating system, it's just making a dll out of their C runtime library. The downside of that is the usual dll-hell versioning problem.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b97dmp$1rj1$1@digitaldaemon.com...
> If you write one humongous printf, it's going to replace quite a few calls to individual print functions.  What you're missing is that all those
calls
> are made up for by the gargantuan implementation of printf itself, hidden away in the library.

printf actually isn't that large.

But then you also have sprintf and fprintf!!  ;)

The main problems with printf are:

It's not extensible
It's not typesafe
It's not retargetable

I could care less if it generates slightly smaller code than the library which does all of the above.  Code size, so long as it's reasonable, is not that big of a deal.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b9gk4i$gsq$2@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b97dmp$1rj1$1@digitaldaemon.com...
> > If you write one humongous printf, it's going to replace quite a few
calls
> > to individual print functions.  What you're missing is that all those
> calls
> > are made up for by the gargantuan implementation of printf itself,
hidden
> > away in the library.
>
> printf actually isn't that large.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9gn26$lqj$1@digitaldaemon.com...
> But then you also have sprintf and fprintf!!  ;)

Those are only a few bytes each. All the printf variants call the same core routine.

> The main problems with printf are:
>
> It's not extensible

Yup.

> It's not typesafe

I've been using printf for 20 years and this just hasn't been an issue.

> It's not retargetable

Not sure what you mean.

> I could care less if it generates slightly smaller code than the library which does all of the above.  Code size, so long as it's reasonable, is
not
> that big of a deal.

That depends on who you are! If you're doing embedded systems, code size is still a big deal.

Walter wrote:
> That's not really building it into the operating system, it's just
> making a dll out of their C runtime library.

And what would you call "building into an operating system"? The Windows
kernel is a DLL. The whole OS is all based off DLLs.

> The downside of that is the usual dll-hell versioning problem.

I'm not intending to start a flame on DLL hell... BUT there is
definately a basic functionality which you should be able to rely upon -
and it is documented somewhere. And what do you care what version of DLL
it is, if it does the right stuff??? Maybe some new OS would need a new
version - or could run better with it than with a program-embedded runtime?

It also appears to me that the DLL versioning problems are more or less in the past - since executables now have a version signature, and installer programs are not allowed to overwrite systemwide installed libraries with older ones.

I see a possibility - and it is yet a compiler writer's decision whether he makes use of it or embeds his own. That's another reason why GCC version of D would be good.

-i.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b9gptd$pfu$1@digitaldaemon.com...
> Walter wrote:
> > That's not really building it into the operating system, it's just making a dll out of their C runtime library.
> And what would you call "building into an operating system"? The Windows kernel is a DLL. The whole OS is all based off DLLs.

Good point, but there is a distinction. Operating system APIs are well documented and relatively language agnostic. The MSVC runtime dll is intimately connected with MSVC. Calling the printf in it may bet (and is) heavilly dependent on undocumented MSVC startup code and other characteristics in it. To successfully call printf in it essentially means you must be calling it from code compiled with VC. This is not true for operating system APIs.


> > The downside of that is the usual dll-hell versioning problem.
> I'm not intending to start a flame on DLL hell... BUT there is definately a basic functionality which you should be able to rely upon - and it is documented somewhere. And what do you care what version of DLL it is, if it does the right stuff??? Maybe some new OS would need a new version - or could run better with it than with a program-embedded
runtime?

The problem is the dependency of printf on the rest of the runtime system for the C compiler, which does change.


> It also appears to me that the DLL versioning problems are more or less in the past - since executables now have a version signature, and installer programs are not allowed to overwrite systemwide installed libraries with older ones.

That doesn't really solve the problem, as a program may depend on the distinct behavior of an older DLL. Every time I upgrade, I pray that my apps don't break <g>.

> I see a possibility - and it is yet a compiler writer's decision whether he makes use of it or embeds his own. That's another reason why GCC version of D would be good.

"Walter" <walter@digitalmars.com> wrote in message news:b9gpa1$ott$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9gn26$lqj$1@digitaldaemon.com...
> > But then you also have sprintf and fprintf!!  ;)
>
> Those are only a few bytes each. All the printf variants call the same
core
> routine.
>
> > The main problems with printf are:
> >
> > It's not extensible
>
> Yup.

This means you can't add your own formatting commands.  You can't make it handle new types.

> > It's not typesafe
>
> I've been using printf for 20 years and this just hasn't been an issue.

Lucky you.  You will admit however that it is not type safe?  Personal issues aside, just a simple yes or no.

> > It's not retargetable
>
> Not sure what you mean.

Meaning you can't printf to anything you want.  You also have to know the size of the buffer before you call, for sprintf.  This is tedious.  It's another aspect of not being extensible, but on the back end.

You've heard me bitching about not being able to redirect printf to OutputDebugString for a while now, haven't you?  I'd use fprintf if that would work, but it doesn't.  And there's no way to call the printf core without going thru sprintf, which destroys any buffering possibilities because you have to preallocate enough storage to guarantee it'll be sufficient.  What if sprintf runs out of room?  Oh, wait, there's snprintf. If your vendor supports it.  There's no such thing as smallocprintf, but I suppose someone could figure out a way to make one.

C standard library designers did *not* think of every possible use ahead of time, but there's no way we can extend it properly.  That doesn't seem elegant to me.  That seems really sad.

> > I could care less if it generates slightly smaller code than the library which does all of the above.  Code size, so long as it's reasonable, is
> not
> > that big of a deal.
>
> That depends on who you are! If you're doing embedded systems, code size
is
> still a big deal.

We've already established that typesafe printf could be had for the same number of bytes as printf would take.  It would however require compiler support.

My gcc compiler for PS/2 is so sloppy, it outputs 4 32-bit NOP's in a row all over the place, just because it feels like it, evidently.  It's supposed to be an optimized build.  With that kind of overhead who would notice a few extra parms pushed or a few extra calls?  It's not like printf needs to be especially fast;  it's either printing to screen (limited by human perception) or disk (limited by mechanical processes), so fprintf probably spends most of its time waiting on the OS to flush the buffers.

It would seriously pay to concentrate on making a truly elegant, *usable* I/O foundation for D.  Most of the work can be done by someone here, there are people willing to code I/O libraries, but some of the functionality needs to be in the language itself, and its early implementations.

Sean