I wrote these two, they may be of some interest...


http://www.akbkhome.com/blog.php/View/114/interesting_languages__D.html
http://www.akbkhome.com/blog.php/View/115/More_on_Digitalmars_D__Simple_SVG_render_for_GnomeCanvas.html

I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)

Regards
Alan

On Tue, 28 Feb 2006 10:40:47 +0800, Alan Knowles wrote:

> I wrote these two, they may be of some interest...
> 
> http://www.akbkhome.com/blog.php/View/114/interesting_languages__D.html http://www.akbkhome.com/blog.php/View/115/More_on_Digitalmars_D__Simple_SVG_render_for_GnomeCanvas.html
> 
> I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)

The web pages don't display very well in Opera (v8.52 Build 7721). It looks like some non-standard code is being used.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
28/02/2006 1:50:48 PM

Derek Parnell wrote:
> On Tue, 28 Feb 2006 10:40:47 +0800, Alan Knowles wrote:
> 
> 
>>I wrote these two, they may be of some interest...
>>
>>http://www.akbkhome.com/blog.php/View/114/interesting_languages__D.html
>>http://www.akbkhome.com/blog.php/View/115/More_on_Digitalmars_D__Simple_SVG_render_for_GnomeCanvas.html
>>
>>I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)
> 
> 
> The web pages don't display very well in Opera (v8.52 Build 7721). It looks
> like some non-standard code is being used.
> 
Yeah, only the top menu is a bit broken, I've never worked out (or bothered that much) how to fix it for IE/Opera, as they dont have free downloable CSS editors on linux. Feel free to send me patches to the CSS ;)

Regards
Alan

On Tue, 28 Feb 2006 10:40:47 +0800, Alan Knowles <alan@akbhome.com> wrote:
> I wrote these two, they may be of some interest...
>
>
> http://www.akbkhome.com/blog.php/View/114/interesting_languages__D.html
> http://www.akbkhome.com/blog.php/View/115/More_on_Digitalmars_D__Simple_SVG_render_for_GnomeCanvas.html
>
> I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)

Nice work! (but like Derek mentioned it doesn't look so good in Opera)

I'm mostly sure this is incorrect however (someone else correct me if I'm wrong)..

"
File f = new File( r"/tmp/data.svg", FileMode.In );
while (!f.eof()) {
  testdata ~= f.readString(  f.available());
}
almost as simple as file_get_contents(), and since D cleans up the File handle at the end of the method it's in, you dont really need to delete f to close the file handle."

D is garbage collected and the collector does not guarantee to call the destructor for the File object. So, the above code may never close the file.

However, D has a feature currently called 'auto' (I say 'currently' because there is some debate on the topic of late)

auto File f = new File( r"/tmp/data.svg", FileMode.In );
while (!f.eof()) {
  testdata ~= f.readString(  f.available());
}

'auto' will ensure the File object is deleted at the end of the scope.

Also, a recent new feature "on scope" can help here too:
  http://www.digitalmars.com/d/exception-safe.html
  http://www.digitalmars.com/d/statement.html#scope

Oh, and std.file contains a function "read" which will read an entire file into an array. It returns a void[] which can be cast to whatever array type you actually require, eg.

import std.file;
import std.stdio;

void main()
{
	wchar[] text = cast(wchar[])read("utf16.txt");
	writefln(text);
}

Regan

On Tue, 28 Feb 2006 16:15:38 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> D is garbage collected and the collector does not guarantee to call the destructor for the File object. So, the above code may never close the file.

Which reminds me, your other statement in the first article:

"memory management (autofreeing at the end of each function) - so you dont need to splatter the code with malloc)(/free()"

should probably mention the garbage collector as the reason you don't need malloc/free.

The statement:
  "autofreeing at the end of each function"

isn't exactly true, the current GC tends to free when resources get tight, i.e. you ask for more memory and there isn't enough.

Regan

Thanks, I'll have a look at updating them later, so they are more technically acurate

Regards
Alan

Regan Heath wrote:
> On Tue, 28 Feb 2006 16:15:38 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> 
>> D is garbage collected and the collector does not guarantee to call the  destructor for the File object. So, the above code may never close the  file.
> 
> 
> Which reminds me, your other statement in the first article:
> 
> "memory management (autofreeing at the end of each function) - so you dont  need to splatter the code with malloc)(/free()"
> 
> should probably mention the garbage collector as the reason you don't need  malloc/free.
> 
> The statement:
>   "autofreeing at the end of each function"
> 
> isn't exactly true, the current GC tends to free when resources get tight,  i.e. you ask for more memory and there isn't enough.
> 
> Regan

"Alan Knowles" <alan@akbhome.com> wrote in message news:du0d5a$5j0$1@digitaldaemon.com...
> I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)

Oh, you poor man!  Writing code like you're still in C!  This is D we're talking about here.

int main(char[][] args)
{
    writefln("Hello World");
    writefln("args.length = ", args.length);

    for (int i = 0; i < args.length; i++)
    {
        // Still a good idea to use the %s, so it doesn't escape the arg
string
        writefln("args[", i, "] = '%s'", args[i]);
    }

    return 0;
}

Or even:

    foreach (uint i, char[] arg; args)
    {
        writefln("args[", i, "] = '%s'", arg);
    }

Also, this isn't valid code:

char[char[]] testarray =
[
    "one": "1",
    "two": "2"
];

There are no associative array initializers yet.  In fact, there are no non-static array initializers (dumb, I know).  They've been proposed, but they don't exist.

On Tue, 28 Feb 2006 16:15:38 +1300, Regan Heath wrote:

> 
> Oh, and std.file contains a function "read" which will read an entire file into an array. It returns a void[] which can be cast to whatever array type you actually require, eg.
> 
> import std.file;
> import std.stdio;
> 
> void main()
> {
> 	wchar[] text = cast(wchar[])read("utf16.txt");
> 	writefln(text);
> }

Just to clarify, the cast here "cast(wchar[])" does not convert the bytes read in to UTF16. If you use a cast here, the bytes must already by in the order implied by the cast. Thus "cast(wchar[])" is useful if the file is already  UTF16 encoded file. If the file is, say ASCII or UTF8, and you need it converted to UTF16, ...

    wchar[] text = std.utf.toUTF16(cast(char[])read("utf08.txt"))

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
28/02/2006 3:23:28 PM

Jarrett Billingsley wrote:
> "Alan Knowles" <alan@akbhome.com> wrote in message news:du0d5a$5j0$1@digitaldaemon.com...
> 
>>I'm sure they are lacking in many ways, but feel free to post comments/corrections ;)
> 
> 
> Oh, you poor man!  Writing code like you're still in C!  This is D we're talking about here.
> 
> int main(char[][] args)
> {
>     writefln("Hello World");
>     writefln("args.length = ", args.length);
> 
>     for (int i = 0; i < args.length; i++)
>     {
>         // Still a good idea to use the %s, so it doesn't escape the arg string
>         writefln("args[", i, "] = '%s'", args[i]);
>     }
> 
>     return 0;
> }
> 
> Or even:
> 
>     foreach (uint i, char[] arg; args)
>     {
>         writefln("args[", i, "] = '%s'", arg);
>     }
> 

Or even:

foreach(i, arg; args)
{
...
}

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote in message news:du1an7$16so$1@digitaldaemon.com...
> Or even:
>
> foreach(i, arg; args)
> {
> ...
> }

Autotyping scares me.  I like knowing exactly what everything is.