Error: array operation d1[] + d2[] without assignment not implemented

2014-09-13 Thread deed via Digitalmars-d-learn

struct Vector (T)
{
  T[]arr;
  void opSliceAssign (T[] a) { arr[] = a[]; }
}
unittest
{
  auto v = Vector!double([1, 2]);
  double[] d1 = [11, 12];
  double[] d2 = [21, 22];
  double[] d3 = new double[](2);
  d3[] = d1[] + d2[];
  assert (d3 == [11.+21., 12.+22.]);
  assert (is(typeof(d1[] + d2[]) == double[]));
  v[] = d1[]  // Fine
  v[] = d1[] + d2[];  // Error: array operation d1[] + d2[] 
without assignment not implemented

}

How can opSliceAssign be defined to make this work?


Re: Idiomatic async programming like C# async/await

2014-09-13 Thread Kagamin via Digitalmars-d-learn
No, vibe provides synchronous non-blocking interface similar to 
async/await.


Re: Error: array operation d1[] + d2[] without assignment not implemented

2014-09-13 Thread Ilya Yaroshenko via Digitalmars-d-learn

On Saturday, 13 September 2014 at 14:18:57 UTC, deed wrote:

struct Vector (T)
{
  T[]arr;
  void opSliceAssign (T[] a) { arr[] = a[]; }
}
unittest
{
  auto v = Vector!double([1, 2]);
  double[] d1 = [11, 12];
  double[] d2 = [21, 22];
  double[] d3 = new double[](2);
  d3[] = d1[] + d2[];
  assert (d3 == [11.+21., 12.+22.]);
  assert (is(typeof(d1[] + d2[]) == double[]));
  v[] = d1[]  // Fine
  v[] = d1[] + d2[];  // Error: array operation d1[] + d2[] 
without assignment not implemented

}

How can opSliceAssign be defined to make this work?


Hi!

struct Vector (T)
{
T[]arr;
T[] opSlice() { return arr; }
}
Vector!double v;
double[] d;
v[][] = d[] + d[];

//first [] call opSlise, second [] for array syntax

Best Regards,
Ilya


Re: Error: array operation d1[] + d2[] without assignment not implemented

2014-09-13 Thread Ilya Yaroshenko via Digitalmars-d-learn


Operations like ar1[] op= ar2[] op ar3[] is only for arrays.
There is no operator overloading for this staff.


Re: Should dmd have given me a warning at least?

2014-09-13 Thread WhatMeWorry via Digitalmars-d-learn

On Saturday, 13 September 2014 at 08:09:15 UTC, Mike Parker wrote:

On 9/13/2014 7:44 AM, WhatMeWorry wrote:


// the following two lines compile cleanly but when executed, 
I get

// D:\Projects\Derelict02_SimpleOpenGL_3_3_program.exe
// object.Error: Access Violation
// 

string glShadingLangVer =
to!string(glGetString(GL_SHADING_LANGUAGE_VERSION));
writeln(glShadingLangVer is , glShadingLangVer);




glGetString has the following signature:

const GLubyte* glGetString(GLenum name);

I presume the const is causing the problem.  Is there a work 
around?


Thanks.


Can you show more of your code so we can get some context?

---
This email is free from viruses and malware because avast! 
Antivirus protection is active.

http://www.avast.com


Well, this morning on another system, the code works beautifully

string glShadingLangVer = 
to!string(glGetString(GL_SHADING_LANGUAGE_VERSION));

writeln(glShadingLangVer is , glShadingLangVer);

returns

glShadingLangVer is 4.20 - Build 10.18.10.3345

Thanks for you help.


Re: Error: array operation d1[] + d2[] without assignment not implemented

2014-09-13 Thread deed via Digitalmars-d-learn

Hi!

struct Vector (T)
{
T[]arr;
T[] opSlice() { return arr; }
}
Vector!double v;
double[] d;
v[][] = d[] + d[];

//first [] call opSlise, second [] for array syntax

Best Regards,
Ilya


Thanks for your suggestion. It's not as attractive though, it 
would be the same as v.arr[] = ..., exposing the naked array. The 
syntax also becomes a bit confusing.


With alias this it works, but functionality is lost. See
http://dpaste.dzfl.pl/35081c1f1745

It feels not consistent, so I guess that's the reason for the 
not implemented message.


String Theory Questions

2014-09-13 Thread WhatMeWorry via Digitalmars-d-learn


The name string is aliased to immutable(char)[]

Why was immutable chosen? Why not mutable.  Or why not just make 
another alias called


strung where it is aliased to mutable(char)[]

Also, since strings are arrays and arrays are structs with a 
length and ptr
field, I ran the following code for both an empty string and a 
null string.


string emptyStr = ;
writeln(emptyStr.ptr is , emptyStr.ptr);
writeln(emptyStr.length is , emptyStr.length);

string nullStr = null;
writeln(nullStr.ptr is , nullStr.ptr);
writeln(nullStr.length is , nullStr.length);

and got the following results:

emptyStr.ptr is 42F080
emptyStr.length is 0
nullStr.ptr is null
nullStr.length is 0

I guess I was expecting them to be equivalent.  I can understand 
why both lengths are zero.  But what is emptyStr.ptr doing with 
the 42F080 value? I presume this is a address?  If so, what does 
this address contain and what is it used for?


Or maybe a more succinct question is why not just set 
emptyStr.ptr to null and be done with it?




Re: String Theory Questions

2014-09-13 Thread ketmar via Digitalmars-d-learn
On Sat, 13 Sep 2014 17:09:56 +
WhatMeWorry via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:

 I guess I was expecting them to be equivalent.  I can understand 
 why both lengths are zero.  But what is emptyStr.ptr doing with 
 the 42F080 value? I presume this is a address?  If so, what does 
 this address contain and what is it used for?
it's used to keep empty string. ;-)

note that null string and empty string aren't same things. arrays
are reference types and compiler magically knows that null-arrays are
just empty arrays (and you can assign 'null' to array to clear it).

but strings are special in one funny way: when compiler sees string
literal (i.e. quoted string) in source code, it actually generates
C-like zero-terminated string. this is to ease C interop, so we can
call C functions like this: `printf(my string!\n);` instead of this:
`printf(my string!\n.toStringz);`.

so your empty string is actually points to zero byte (and has zero
length, 'cause D strings aren't zero-terminated). and null string is
really null, i.e. contains no data.

as for immutable: it is done this way so compiler can place string
literals in read-only section of resulting binary. without immutability
calling `void foo (string s);` as `foo(wow!)` will require copying
string to heap first ('cause `s` contents allowed to be changed in
`foo()`).

adding implicit copy-on-writing semantic will increase compiler
complexity and hidden dynamic array struct size for virtually nothing.


signature.asc
Description: PGP signature


Re: String Theory Questions

2014-09-13 Thread AsmMan via Digitalmars-d-learn
On Saturday, 13 September 2014 at 17:31:18 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Sat, 13 Sep 2014 17:09:56 +
WhatMeWorry via Digitalmars-d-learn 
digitalmars-d-learn@puremagic.com

wrote:

I guess I was expecting them to be equivalent.  I can 
understand why both lengths are zero.  But what is 
emptyStr.ptr doing with the 42F080 value? I presume this is a 
address?  If so, what does this address contain and what is it 
used for?

it's used to keep empty string. ;-)

note that null string and empty string aren't same things. 
arrays
are reference types and compiler magically knows that 
null-arrays are
just empty arrays (and you can assign 'null' to array to clear 
it).


but strings are special in one funny way: when compiler sees 
string
literal (i.e. quoted string) in source code, it actually 
generates
C-like zero-terminated string. this is to ease C interop, so we 
can
call C functions like this: `printf(my string!\n);` instead 
of this:

`printf(my string!\n.toStringz);`.



D string are actullay C-strings?


Re: String Theory Questions

2014-09-13 Thread ketmar via Digitalmars-d-learn
On Sat, 13 Sep 2014 22:41:38 +
AsmMan via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:

 D string are actullay C-strings?
in no way. only string *LITERALS* are zero-terminated.


signature.asc
Description: PGP signature


Re: String Theory Questions

2014-09-13 Thread David Nadlinger via Digitalmars-d-learn

On Saturday, 13 September 2014 at 22:41:39 UTC, AsmMan wrote:

D string are actullay C-strings?


No. But string *literals* are guaranteed to be 0-terminated for 
easier interoperability with C code.


David


Re: String Theory Questions

2014-09-13 Thread WhatMeWorry via Digitalmars-d-learn
On Saturday, 13 September 2014 at 23:22:40 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Sat, 13 Sep 2014 22:41:38 +
AsmMan via Digitalmars-d-learn 
digitalmars-d-learn@puremagic.com

wrote:


D string are actullay C-strings?

in no way. only string *LITERALS* are zero-terminated.


Ok. So I wrote the following:

char c = *(emptyStr.ptr);
if (c == '\0')
   writeln(emptyStr only consists of an end of line character);

and sure enough, the writeln() was executed.

Ok, So an empty string has a pointer which just points to C's end 
of line character.



So is one form (Empty strings versus null strings) considered 
better than the other?  Or does it depend on the context?


Also as an aside (and I'm not trying to be flippant here), aren't 
all strings literals?  I mean, can someone give me an example of 
a string non-literal?




Re: String Theory Questions

2014-09-13 Thread ketmar via Digitalmars-d-learn
On Sun, 14 Sep 2014 00:34:54 +
WhatMeWorry via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:

 So is one form (Empty strings versus null strings) considered 
 better than the other?  Or does it depend on the context?
one is better than another in the sense that blue is better than green
(or vice versa). ;-)

don't count on that trailing zero, and don't count on empty string
being null or points to somewhere. `.length` is all that matters.

 Also as an aside (and I'm not trying to be flippant here), aren't 
 all strings literals?  I mean, can someone give me an example of 
 a string non-literal?

  string foo () {
import std.conv;
string s;
foreach (i; 0..10) s ~= to!string(i);
return s;
  }

this function returns string, but that string is in no way built
from literal.

note that it's string *contents* are immutable, not the whole string
structure. there is a difference between `immutable(char[])` and
`immutable(char)[]`. that is why you can use `~=` on strings.


signature.asc
Description: PGP signature


Re: String Theory Questions

2014-09-13 Thread Ali Çehreli via Digitalmars-d-learn

On 09/13/2014 05:34 PM, WhatMeWorry wrote:


aren't all strings literals?


Literals are values that are typed as is in source code:

  http://en.wikipedia.org/wiki/Literal_%28computer_programming%29

Ali