Bill Baxter wrote:
> Walter Bright wrote:
>  > C can't do any of those things.
> 
> Sure it can.
> 
>>> * No way to initialize a static array without counting elements
>>>     static byte[???] imageData = [...];   // i hope you like counting!
> 
> C has no problem with this.  I do it all the time:
> 
>        static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };
> 
>>> * No way to initialize a dynamic array with a known length
>>>     byte[] imageData;  imageData.length = 5;  // two steps - meh
> 
> C has no problem with this (using malloc, its own concept of "dynamic arrays"):
> 
>    byte* imageData = (byte*)malloc(5*sizeof(byte));
> 
> A better comparison is C++, which has no problem with it's std library vector class:
> 
>    vector<int> imageData(5);
> 
> 
>>> * No way to initialize array of strings
>>>     char[][] list = ["eggs","bacon","milk","break"];  //uh uh
> 
> C can do this:
> 
>     char *list[] = { "eggs","bacon","milk","break" };
> 
>>> * No way to initialize non-static struct
>>>     Point p = { x:1.0, y:2.0 };  // nope...not static
> 
> C has no problem with that either:
> 
>     struct Point { float x, y; };
>     void foo() {
>        Point p = {1.0,2.0};
>     }
> 
> (and C99 can do it with the x: y: syntax too, I think)
> 
>>>
>>> * No way to initialize associative array
>>>     char[int] strTable = {"hello":5, "hi":2, "greetings":9}; // no way
> 
> Well you got me there.  C can't do that.

I think C++ 0x *might* be able to do this.  They've added initializer lists for vectors, but I can't remember offhand if they will work for maps as well.


Sean

Anders F Björklund wrote:
> Walter Bright wrote:
>> One way is with Notepad - "Save As" and pick UTF-8.
> 
> I highly recommend *not* using a BOM with UTF-8,
> and instead only use it with UTF-16 and UTF-32...
> There are several Unix tools that choke on the BOM,
> adding it will make those fail for no added value ?

The added value appears when using tools that default to Latin1 unless they see a BOM.

Bill Baxter wrote:

> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>  > C can't do any of those things.
>>>
>>> Sure it can.
>>>
>>>>> * No way to initialize a static array without counting elements
>>>>>     static byte[???] imageData = [...];   // i hope you like counting!
>>>
>>> C has no problem with this.  I do it all the time:
>>>
>>>        static const unsigned char[] = { 1,2,3,4,5,6,7, 255 };
>> 
>> True, but that's only because C doesn't have dynamic arrays. In D,
>> 
>> const char[] c = [ 1,2,3,4,5,6,7, 255 ];
>> 
>> works fine, though it's a dynamic array.
> 
> Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D.  If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length.
> 
> If D has some other convenient and portable way to embed data like icons and images into one's exe, then I'd be interested in hearing about it, but for right now it seems to me like working with static data is a pain in D.
> 
> Anyway, this one thing has actually been the biggest annoyance I've run across in trying to port C++ code to D.  Most things become easier, but this one thing is harder in D.
> 
I thought this would work but apparently it does not (what is the type of an
array literal?)

//begin code
static foo=[cast(ubyte)1,2,3,4,5];

void main()
{
        printf("%d\n",foo.sizeof);
}
//end code

I get this error

johan@Dragon:~$ dmd test.d
test.d(4): Error: cannot infer type from initializer

which feels strange as i thought array literals defaulted to fixed size arrays.

Bill Baxter wrote:
> Walter Bright wrote:
>> const char[] c = [ 1,2,3,4,5,6,7, 255 ];
>>
>> works fine, though it's a dynamic array.
> 
> Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D.  If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length.

If you want an array put into the static data segment,
    static const char[] c = [ 1,2,3,4,5,6,7, 255 ];
will do it.

>> So can D:
>> char *list[] = [ "eggs","bacon","milk","break" ];
>  > char[] list[] = [ "eggs","bacon","milk","break" ];
> 
> Nope, D cannot:
>    dchar.d(12): Error: cannot implicitly convert expression ("bacon") of type char[5] to char[4]

The following D program:
------------------
char *list[] = [ "eggs","bacon","milk","break" ];
char[] list2[] = [ "eggs","bacon","milk","break" ];
------------------
compiles without error.


> But, then you're making everything dynamic when it should be static. Correct me if I'm wrong, but in the C/C++ version of this above, basically everything is static.  The strings will be embedded into the exe, and the array will just consist of pointers directly to those strings in the data segment.  But in the D version you'll have that same data in the data segment, and then you'll also make dynamic copies of all the data onto the heap at runtime.  I don't want two copies of all my static data, especially if one of those copies requires runtime heap allocations.

In the above D program, everything is put into the static data segment. Here's an excerpt from the object file:

_DATA   segment
        db      065h,067h,067h,073h,000h,062h,061h,063h
        db      06fh,06eh,000h,06dh,069h,06ch,06bh,000h
        db      062h,072h,065h,061h,06bh,000h,000h,000h
        dd      offset FLAT:_DATA
        dd      offset FLAT:_DATA[5]
        dd      offset FLAT:_DATA[0Bh]
        dd      offset FLAT:_DATA[010h]
_D4test4listAPa:
        db      004h,000h,000h,000h
        dd      offset FLAT:_DATA[018h]
        db      065h,067h,067h,073h,000h,062h,061h,063h
        db      06fh,06eh,000h,06dh,069h,06ch,06bh,000h
        db      062h,072h,065h,061h,06bh,000h,000h,000h
        db      004h,000h,000h,000h
        dd      offset FLAT:_D4test4listAPa[8]
        db      005h,000h,000h,000h
        dd      offset FLAT:_D4test4listAPa[0Dh]
        db      004h,000h,000h,000h
        dd      offset FLAT:_D4test4listAPa[013h]
        db      005h,000h,000h,000h
        dd      offset FLAT:_D4test4listAPa[018h]
_D4test5list2AAa:
        db      004h,000h,000h,000h
        dd      offset FLAT:_D4test4listAPa[020h]

Daniel Keep wrote:

> 
> 
> BCS wrote:
>> ...
>> However, I don't known how to put in a BOM.
> 
> You can use Notepad to do it.  Yes, the crappy old Notepad that comes with Windows.  When you go File -> Save As, make sure to set the encoding as appropriate.
> 
> I'm still very annoyed that Notepad has better Unicode support than GVim

How so? I've never had any problems getting GVim probably setup for Unicode.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Bill Baxter wrote:
> So, what's left on everyone's lists for D1.0 must-have features?
> 
> I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me.
> 
> What about the iterators?  Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon.
> 
> --bb

There is no way to differentiate between function overloads.


int foo(){ return 0;}
int foo(int i){ return 0;}


int bob()
{
		// foo() or foo(int)?
	auto fn = &foo;
	auto tmp = TemplateTakingFn!(foo);
}

BCS wrote:
> Bill Baxter wrote:
>> So, what's left on everyone's lists for D1.0 must-have features?
>>
>> I glanced over the "Pending Peeves" list, but none of those things seems particularly serious to me.
>>
>> What about the iterators?  Mostly that can be a library thing that comes after the 1.0 release, but it would be nice if foreach at least had the smarts built-in to use an iterator once the method names are decided upon.
>>
>> --bb
> 
> There is no way to differentiate between function overloads.
> 
> 
> int foo(){ return 0;}
> int foo(int i){ return 0;}
> 
> 
> int bob()
> {
>         // foo() or foo(int)?
>     auto fn = &foo;
>     auto tmp = TemplateTakingFn!(foo);
> }

That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do   'int function() fn = &foo' to get the one you want?

--bb

Thanks for the reply.

So in short, are you saying that
   static const char[] c = [1,2,3,4,5,6];
really does not cause any heap allocations?  If so then that's exactly what I want.

However, if that is the case then this should work:

static const ubyte[]  icon1 = [1,2,3,4,5];
static const ubyte[]  icon2 = [1,2,3,4,5];
static const ubyte[]  icon3 = [1,2,3,4,5];
static const ubyte*[] all_icons = [&icon1[0], &icon2[0], &icon3[0] ];

But it gives errors like:
staticdata.d(7): Error: non-constant expression cast(ubyte*)(icon1)

This, however, works:
static const ubyte[5]  icon1 = [1,2,3,4,5];
static const ubyte[5]  icon2 = [1,2,3,4,5];
static const ubyte[5]  icon3 = [1,2,3,4,5];
static const ubyte*[] all_icons = [&icon1[0], &icon2[0], &icon3[0] ];


The error messages are the main thing that led me to believe that the former must be doing dynamic heap allocations.

So is this whole issue really just a bug with deducing what's const and what's not?

--bb

Walter Bright wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> const char[] c = [ 1,2,3,4,5,6,7, 255 ];
>>>
>>> works fine, though it's a dynamic array.
>>
>> Yep it's great that D has built-in dynamic arrays, but the point is that the syntax for dynamic arrays is getting in the way of static arrays, making something that's simple in C become hard in D.  If you want a static array you have no choice right now but to count up the elements, or deliberately use the wrong length to trigger compiler errors that will tell you the right length.
> 
> If you want an array put into the static data segment,
>     static const char[] c = [ 1,2,3,4,5,6,7, 255 ];
> will do it.
> 
>>> So can D:
>>> char *list[] = [ "eggs","bacon","milk","break" ];
>>  > char[] list[] = [ "eggs","bacon","milk","break" ];
>>
>> Nope, D cannot:
>>    dchar.d(12): Error: cannot implicitly convert expression ("bacon") of type char[5] to char[4]
> 
> The following D program:
> ------------------
> char *list[] = [ "eggs","bacon","milk","break" ];
> char[] list2[] = [ "eggs","bacon","milk","break" ];
> ------------------
> compiles without error.
> 
> 
>> But, then you're making everything dynamic when it should be static. Correct me if I'm wrong, but in the C/C++ version of this above, basically everything is static.  The strings will be embedded into the exe, and the array will just consist of pointers directly to those strings in the data segment.  But in the D version you'll have that same data in the data segment, and then you'll also make dynamic copies of all the data onto the heap at runtime.  I don't want two copies of all my static data, especially if one of those copies requires runtime heap allocations.
> 
> In the above D program, everything is put into the static data segment. Here's an excerpt from the object file:
> 
> _DATA   segment
>         db      065h,067h,067h,073h,000h,062h,061h,063h
>         db      06fh,06eh,000h,06dh,069h,06ch,06bh,000h
>         db      062h,072h,065h,061h,06bh,000h,000h,000h
>         dd      offset FLAT:_DATA
>         dd      offset FLAT:_DATA[5]
>         dd      offset FLAT:_DATA[0Bh]
>         dd      offset FLAT:_DATA[010h]
> _D4test4listAPa:
>         db      004h,000h,000h,000h
>         dd      offset FLAT:_DATA[018h]
>         db      065h,067h,067h,073h,000h,062h,061h,063h
>         db      06fh,06eh,000h,06dh,069h,06ch,06bh,000h
>         db      062h,072h,065h,061h,06bh,000h,000h,000h
>         db      004h,000h,000h,000h
>         dd      offset FLAT:_D4test4listAPa[8]
>         db      005h,000h,000h,000h
>         dd      offset FLAT:_D4test4listAPa[0Dh]
>         db      004h,000h,000h,000h
>         dd      offset FLAT:_D4test4listAPa[013h]
>         db      005h,000h,000h,000h
>         dd      offset FLAT:_D4test4listAPa[018h]
> _D4test5list2AAa:
>         db      004h,000h,000h,000h
>         dd      offset FLAT:_D4test4listAPa[020h]

Bill Baxter wrote:
> BCS wrote:
>> There is no way to differentiate between function overloads.
>>
>>
>> int foo(){ return 0;}
>> int foo(int i){ return 0;}
>>
>>
>> int bob()
>> {
>>         // foo() or foo(int)?
>>     auto fn = &foo;
>>     auto tmp = TemplateTakingFn!(foo);
>> }
> 
> That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do   'int function() fn = &foo' to get the one you want?
> 
> --bb

I've played with just about every permutation of this problem during the course of writing Pyd.

int foo() { return 0; }
int foo(int i) { return 0; }

void main() {
    auto fn = &foo; // Uses the lexically first function
    static assert(is(typeof(fn) == int function()));
    fn();
    //fn(12); // Error: expected 0 arguments, not 1
    int function(int) fn2 = &foo; // Works
    fn2(12);
}

In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Lars Ivar Igesund wrote:
> Daniel Keep wrote:
> 
>>
>> BCS wrote:
>>> ...
>>> However, I don't known how to put in a BOM.
>> You can use Notepad to do it.  Yes, the crappy old Notepad that comes with Windows.  When you go File -> Save As, make sure to set the encoding as appropriate.
>>
>> I'm still very annoyed that Notepad has better Unicode support than GVim
> 
> How so? I've never had any problems getting GVim probably setup for Unicode.
> 

It's basically a font problem.  GVim allows you to select exactly two fonts: a "normal" monospace font, and a "wide" font (which is used for things like kanji.)

The problem is that once you've picked those fonts, GVim will never use anything else.  This is a pain because you end up with heaps of unknown Unicode characters.  For example, none of the weird characters I used in the examples for my article on text in D show up in GVim (except for the hiragana since I have a Japanese font installed) but they all show up in Notepad which falls over to other fonts if the one it's using doesn't have that character.  There appear to be options for selecting a set of fonts to use, but they don't work on Windows.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/