> <*-Hint-*>I know that I promised not to bug you, but it has been a little
> while now, so here goes nothing...are you any closer to putting in the
> ifind(), and irfind() (and maybe hopefully the ireplace() and icount()
> functions) into std.string? Please. I need them for the code I'm writing,

<*- Hint -*> I'm sure Walter accept patches <g>

>> - structs and unions (presumably .toString(), if it has one....)
>
>Yup. Though this won't work yet for structs until TypeInfo is improved.
>
>> - enums (do these count as integral types?)
>
>Enums I have special plans for. When TypeInfo gets better, I plan to have writef write out the enum identifier corresponding to the value. Right now, they come out as integers.
>
>> - arrays other than strings
>
>Waiting on improved TypeInfo. Probably will do a comma separated list.

Could you perhaps tell something about the improved Typeinfo? What can be done with it? What will be changed?

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:ccp56o$sjl$1@digitaldaemon.com...
> >> - structs and unions (presumably .toString(), if it has one....)
> >
> >Yup. Though this won't work yet for structs until TypeInfo is improved.
> >
> >> - enums (do these count as integral types?)
> >
> >Enums I have special plans for. When TypeInfo gets better, I plan to have writef write out the enum identifier corresponding to the value. Right
now,
> >they come out as integers.
> >
> >> - arrays other than strings
> >
> >Waiting on improved TypeInfo. Probably will do a comma separated list.
>
> Could you perhaps tell something about the improved Typeinfo? What can be
done
> with it? What will be changed?

Basically having specialized TypeInfo's for each type.

In article <ccp4j1$rio$1@digitaldaemon.com>, Juanjo =?ISO-8859-15?Q?=C1lvarez?= says...
>
>> <*-Hint-*>I know that I promised not to bug you, but it has been a little
>> while now, so here goes nothing...are you any closer to putting in the
>> ifind(), and irfind() (and maybe hopefully the ireplace() and icount()
>> functions) into std.string? Please. I need them for the code I'm writing,
>
><*- Hint -*> I'm sure Walter accept patches <g>
>

Juanjo: Thxs!!

But I've already did that, done that in the following messages "Re:DMD 0.92
release 06/12/2004 11:44 AM" with ifind() and irfind()
REF:<caf8dk$2l38$1@digitaldaemon.com> and "Re:DMD 0.92 release 06/15/2004 01:45
PM" with ireplace() and icount() REF:<canciu$2p8q$1@digitaldaemon.com>. And
Walter had allowed me the chance to do them, so now it's just a matter of
waiting.

:P ... <g>

P.S. I bug Walter ever now and then, because he seems to work better and faster
under pressure. :))

The wonderful new writef() replacement for printf() being as a prime example.
Keep Truckin' Walter!!

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Stewart Gordon wrote:
<snip>
> The obvious way would be to add writef and writefln methods to Stream (we'd have Unicode or not to consider - maybe also writefW and writeflnW), and to create a function
> 
>     dchar[] swritef(...);
<snip>

I've just discovered that there's a function

	char[] format(...);

in std.string that does this.  Yet another undocumented feature.  And I'm not sure why it's only been written for char, not for wchar or dchar, considering that doFormat itself generates dchars....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

<snip>
> The obvious way would be to add writef and writefln methods to Stream (we'd have Unicode or not to consider - maybe also writefW and writeflnW), and to create a function
<snip>

Here they are....

----------
void writef(...) {
	void putc(dchar c) {
		char[] buf;
		std.utf.encode(buf, c);

		writeString(buf);
	}

	std.format.doFormat(&putc, _arguments, _argptr);
}


void writefln(...) {
	void putc(dchar c) {
		char[] buf;
		std.utf.encode(buf, c);

		writeString(buf);
	}

	std.format.doFormat(&putc, _arguments, _argptr);
	version (Win32) {
		writeString("\r\n");
	} else version (Mac) {
		writeString("\r");
	} else {
		writeString("\n");
	}
}


void writefW(...) {
	void putc(dchar c) {
		wchar[] buf;
		std.utf.encode(buf, c);

		writeStringW(buf);
	}

	std.format.doFormat(&putc, _arguments, _argptr);
}


void writeflnW(...) {
	void putc(dchar c) {
		wchar[] buf;
		std.utf.encode(buf, c);

		writeStringW(buf);
	}

	std.format.doFormat(&putc, _arguments, _argptr);
	version (Win32) {
		writeStringW("\r\n");
	} else version (Mac) {
		writeStringW("\r");
	} else {
		writeStringW("\n");
	}
}


-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

This code doesn't compile properly.  The first line in classTemplate works, but the second reports the error "no property 'type' for type 'classBase'".  It should create a field of the given alias type.

    class classBase
    {
        alias int type;
        const int constant = 1;
    }

    class classTemplate (parameter)
    {
        int value = parameter.constant;
        parameter.type field;
    }

    alias classTemplate! (classBase) instantiation;

"Walter" <newshound@digitalmars.com> wrote in message news:cck67e$2irt$1@digitaldaemon.com...
> Finally, the new printf is here! (called writef). The rest are bug fixes.
>
> http://www.digitalmars.com/d/changelog.html
>

Hooray!

I don't think the format %.*s works as expected. It's printing out the
entire string rather than using the alternate length from the stack:
   writef("%.*s", 2, "hello");
Still prints out the entire "hello". I know we don't need this anymore, but
I think it should at least be consistent.

All the types cleanly print what you would expect, except strings are still
treated as formats. I just don't think it's all that good. The same old
problem with printf(): you get user input and go to print it, if the user
types a % it is processed as a format and all hell breaks loose (the
typesafety prevents some of the problems). Sure you could just writef("%s",
userinput) but it's just not very clean with the rest of it. I guess I'm
having a hard time explaining it. But I have an idea to make it better, by
using a different string type as the format:
   writef(f"this is a format string", "this isn't");
   writef("%s does nothing", f"%s does something");
the f"" tells the compiler to use fchar[], fwchar[] or fdchar[] (can be
typedef'd in object.d) that instruct writef() to process it as a format
string instead of a regular string. Then writef(userinput) is safe. I think
it will fit in fine because we won't need as many format strings as printf()
did, since writef() knows about the types.

Vathix wrote:
<snip>
> All the types cleanly print what you would expect, except strings are still
> treated as formats.

Yes, that's the whole point of writef.

> I just don't think it's all that good. The same old
> problem with printf(): you get user input and go to print it, if the user
> types a % it is processed as a format and all hell breaks loose (the
> typesafety prevents some of the problems). Sure you could just writef("%s",
> userinput) but it's just not very clean with the rest of it.

I tend to use puts to write a string by itself.  The only problem is if you want to do it without a trailing newline.

Maybe we should have another function or two in std.stdio for this....

> I guess I'm
> having a hard time explaining it. But I have an idea to make it better, by
> using a different string type as the format:
>    writef(f"this is a format string", "this isn't");
>    writef("%s does nothing", f"%s does something");
> the f"" tells the compiler to use fchar[], fwchar[] or fdchar[] (can be
> typedef'd in object.d)
<snip>

For the syntax to be supported, the types would have to be built into the language.  But it does seem a rather ad hoc feature....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cd08je$2ar5$1@digitaldaemon.com>, Vathix says...
>
[...]
>All the types cleanly print what you would expect, except strings are still treated as formats. I just don't think it's all that good. The same old problem with printf(): you get user input and go to print it, if the user types a % it is processed as a format and all hell breaks loose (the typesafety prevents some of the problems). Sure you could just writef("%s", userinput) but it's just not very clean with the rest of it. I guess I'm having a hard time explaining it. But I have an idea to make it better, by using a different string type as the format:
>   writef(f"this is a format string", "this isn't");
>   writef("%s does nothing", f"%s does something");
>the f"" tells the compiler to use fchar[], fwchar[] or fdchar[] (can be
>typedef'd in object.d) that instruct writef() to process it as a format
>string instead of a regular string. Then writef(userinput) is safe. I think
>it will fit in fine because we won't need as many format strings as printf()
>did, since writef() knows about the types.

Exactly my thought, with the difference that I think you can use a custom class to specify a format:

# class Format
# {
# ...
# }
#
# // the fspec utility function
# Format fspec(char[] fs)
# {
#   ...
# }
#
# Format fspec(wchar[] fs)
# {
#   ...
# }
#
# Format fspec(dchar[] fs)
# {
#   ...
# }

Then you can safely write:

writef("This is 100% safe!");
writef("Items: ", num , ", free: ", fspec("%7.3f%%"), (max-num)/max*100);

Ciao