Re: Help passing D strings to C libs
-Daniel I tried what you said: char* ptr = toStringz(path); SDL_LoadBMP(ptr); and made a check to see if the pointer is null, which it isn't, but I'm unable to inspect is value, I haven't a debugger at the moment, could you recommend one ? I also made the string a char[] and tested to see if that made a difference. I think it may be something to do with SDL itself. I tried calling another function, SDL_GetTicks(), and that's causing problems as well. -Jonathan I read the docs earlier and found the same thing about literals being null terminated but not regular strings, which explains why they work. Double check after double check, I am also certain that no other code is messing with it and changing values.
Re: Help passing D strings to C libs
On Sunday 13 March 2011 22:38:49 Gene P. Cross wrote: > I've amended the source to pass the strings pointer (path.ptr) after adding > a null but the problem still persists. > > I lost for what it could be and I'm certain this is where the problem is, > because if I remove the method call, the program runs fine. > > I've noticed that calling SDL_LoadBMP and passing a string literal seems to > work, instead of a string variable. I might load all the images > independently into an array and have each object reference that array, > instead of every object loading its own. In D2 (and I assume D1, but I don't know), string literals all have "\0" one past their end, so you can safely pass them to C functions. Other strings don't have them, so you have to append the "\0". Other than that, I don't know why there would be any difference between passing a string literal and a regular string. Perhaps something else in your code is altering the string later (which it wouldn't do if you just passed a literal) and _that_ is screwing it up. I don't know. For the most part, there shouldn't be much difference between dealing with string literals and dealing with normal strings. - Jonathan M Davis
Re: Help passing D strings to C libs
On 3/14/2011 1:38 AM, Gene P. Cross wrote: I've amended the source to pass the strings pointer (path.ptr) after adding a null but the problem still persists. I lost for what it could be and I'm certain this is where the problem is, because if I remove the method call, the program runs fine. I've noticed that calling SDL_LoadBMP and passing a string literal seems to work, instead of a string variable. I might load all the images independently into an array and have each object reference that array, instead of every object loading its own. It sounds like a bug with version of D your using. I make heavy use of toStringz with a lua wrapper I have. If you can debug your program, try doing something like this. char* ptr = toStringz(path); SDL_LoadBMP(ptr); and inspect ptr before the call to SDL_LoadBMP. I would also replace string with char[]. To be sure that string isn't really wchar[] or dchar[]. Although, I imagine the compiler would catch that.
Re: Help passing D strings to C libs
I've amended the source to pass the strings pointer (path.ptr) after adding a null but the problem still persists. I lost for what it could be and I'm certain this is where the problem is, because if I remove the method call, the program runs fine. I've noticed that calling SDL_LoadBMP and passing a string literal seems to work, instead of a string variable. I might load all the images independently into an array and have each object reference that array, instead of every object loading its own.
Re: Help passing D strings to C libs
On Sunday 13 March 2011 21:32:49 Gene P. Cross wrote:
> Hi, I'm fairly new to D and I'm writing a Space Invaders clone to get
> myself acquainted with the language.
>
> I'm having trouble passing D strings (char[]) to SDL, in particular
> SDL_LoadBMP(), I keep receiving a segfault.
>
> Heres the code:
>
> void setImg(string path) {
> // concat null terminating char to string and cast to c type string
> when // passing to SDL_LoadBMP()
> path ~= "\0";
> image = SDL_LoadBMP( cast(char*)path );
> }
>
> and the value of path is "./resources/cannon.bmp"
>
> I'm using SDL 1.2.14 and DMD 1.067 on Ubuntu 10.10
>
> If someone could tell me what I'm doing wrong it would be greatly
> appreciated.
I don't use D1, so I don't know all of the ins and outs, but you're going to
have to make sure that you put a "\0" at the end of the string so that it's
properly null-terminated (which you appear to be doing), and you should be
passing the string's ptr property to the function, not casting the string to
char*.
If you were dealing with D2, you'd also have to worry about not passing a
string
(as opposed to a char[]) to a C function if there's _any_ chance that it would
alter it, since string in D2 is immutable(char)[], but that's not the case in
D1, so that shouldn't be a problem with what you're doing.
- Jonathan M Davis
Re: Help passing D strings to C libs
toStringz is in D1 but still no luck, I still get the same error Thanks for the suggestion though
Re: Help passing D strings to C libs
Wait, actually I'm not sure if there's toStringz for D1, it is there for D2. Try it out, I guess.
Re: Help passing D strings to C libs
Use toStringz from std.string, ala: SDL_LoadBMP(toStringz(path)); Do not embed nulls before calling toStringz, so remove 'path ~= "\0";'
Help passing D strings to C libs
Hi, I'm fairly new to D and I'm writing a Space Invaders clone to get myself
acquainted with the language.
I'm having trouble passing D strings (char[]) to SDL, in particular
SDL_LoadBMP(), I keep receiving a segfault.
Heres the code:
void setImg(string path) {
// concat null terminating char to string and cast to c type string when
// passing to SDL_LoadBMP()
path ~= "\0";
image = SDL_LoadBMP( cast(char*)path );
}
and the value of path is "./resources/cannon.bmp"
I'm using SDL 1.2.14 and DMD 1.067 on Ubuntu 10.10
If someone could tell me what I'm doing wrong it would be greatly appreciated.
Dependencies file format
After some searching, I found the documentation here: http://d.puremagic.com/issues/show_bug.cgi?id=3122 Shouldn't this be on the web site somewhere?
Re: "Semi-const" methods?
On Sunday 13 March 2011 15:32:34 Magnus Lie Hetland wrote: > On 2011-03-13 23:27:14 +0100, Magnus Lie Hetland said: > > Any other ideas on how to handle this sort of "mostly const" or "const > > where it counts" stuff? Perhaps my design intentions here are off to > > begin with?-) > > OK -- a *little* quick on the trigger there. My solution: Declare the > method const, and assign the non-essential cache stuff to local > variables, casting away the constness. > > (Still open to schooling on the design part of this, though. Perhaps > declaring a method as const is no good when it's not *really* const? > For now, I'm just doing it to check that I don't inadvertently change > things I don't want to change.) What you want is logical const. You want it to be const from the perspective of an observer of the function but actually have stuff non-const within it. C++ has the mutable keyword to handle this. It's also completely legal and well-defined to cast away constness in C++. D, on the other hand, does not technically support logical const at all. It has to do with the complete lack of compiler guaranteeds. You _can_ cast away constness in D, but it's breaking the type system when you do. It is perfectly valid for the compiler to assume that you function really is const and optimize appropriately. So, if you don't actually manage to _really_ be logically const, or if you do this with an immutable object (which would likely result in a segfault), you _are_ going to have incorrect code. On the whole, I'd advise just not using const when you need logical const, but if you're _very_ careful, you can get away with it. But thanks to immutable, it can be _very_ dangerous to cast away constness in a const function unless you're _very_ careful. You really should check out this question on stackoverflow and the answers that go with it: http://stackoverflow.com/questions/4219600/logical-const-in-d - Jonathan M Davis
Re: "Semi-const" methods?
On 2011-03-13 23:32:34 +0100, Magnus Lie Hetland said: (Still open to schooling on the design part of this, though. Perhaps declaring a method as const is no good when it's not *really* const? For now, I'm just doing it to check that I don't inadvertently change things I don't want to change.) Actually, I have a local (recursive) traversal function in the method I was talking about. Ended up not declaring the method as const, but declaring the argument of the traversal function as const. No misleading const declarations "outside", and I get the automatic checks that I want. -- Magnus Lie Hetland http://hetland.org
Re: "Semi-const" methods?
On 2011-03-13 23:27:14 +0100, Magnus Lie Hetland said: Any other ideas on how to handle this sort of "mostly const" or "const where it counts" stuff? Perhaps my design intentions here are off to begin with?-) OK -- a *little* quick on the trigger there. My solution: Declare the method const, and assign the non-essential cache stuff to local variables, casting away the constness. (Still open to schooling on the design part of this, though. Perhaps declaring a method as const is no good when it's not *really* const? For now, I'm just doing it to check that I don't inadvertently change things I don't want to change.) -- Magnus Lie Hetland http://hetland.org
"Semi-const" methods?
I have a data structure that's generally static (const, or even immutable), but it has some utility storage, which caches certain results during use. This caching etc. doesn't really affect the semantics of the main object, and are reset between operations, so I think it still would be useful to declare (and statically check) that certain methods don't modify any of the *rest* of the structure (i.e., the "main parts"). I *could* declare the methods const, and pass in a second object (a non-const parameter) for the caching etc. Or I cast the relevant parts to const (assigning them to local variables) early on in the relevant methods (dropping the const modifier on the method itself -- sort of a bummer). Any other ideas on how to handle this sort of "mostly const" or "const where it counts" stuff? Perhaps my design intentions here are off to begin with?-) -- Magnus Lie Hetland http://hetland.org
Re: "foo.bar !in baz" not allowed?
On 2011-03-13 21:27:27 +0100, spir said: On 03/13/2011 07:58 PM, Magnus Lie Hetland wrote: For some reason, it seems like expressions of the form "foo.bar !in baz" aren't allowed. I suspect this is a grammar/parser problem -- the bang is interpreted as a template argument operator, rather than a negation operator, [snip] Would be nice to copy the error, wouldn't it? template argument expected following ! Ah. I thought my explanation (see above) made that clear. Anyway, this is definitely a bug in my opinion. Turns out it's an old one. Sorry about that: http://d.puremagic.com/issues/show_bug.cgi?id=4159 -- Magnus Lie Hetland http://hetland.org
Re: "foo.bar !in baz" not allowed?
On 03/13/2011 07:58 PM, Magnus Lie Hetland wrote:
For some reason, it seems like expressions of the form "foo.bar !in baz" aren't
allowed. I suspect this is a grammar/parser problem -- the bang is interpreted
as a template argument operator, rather than a negation operator, and there's
really no need to make that interpretation when it is immediately followed by
"in". This suspicion is strengthened by the fact that "bar !in baz" is fine, as
is "(foo.bar) !in baz".
Should I file this as a bug?
Small sample program:
struct Foo {
uint bar;
}
struct Baz {
bool opIn_r(uint e) {
return false;
}
}
void main() {
Baz baz;
Foo foo;
auto res = (foo.bar) !in baz;
res = !(foo.bar in baz);
// res = foo.bar !in baz; // Not OK...
uint frozz;
res = frozz !in baz;
}
Would be nice to copy the error, wouldn't it?
template argument expected following !
Anyway, this is definitely a bug in my opinion.
Denis
--
_
vita es estrany
spir.wikidot.com
"foo.bar !in baz" not allowed?
For some reason, it seems like expressions of the form "foo.bar !in
baz" aren't allowed. I suspect this is a grammar/parser problem -- the
bang is interpreted as a template argument operator, rather than a
negation operator, and there's really no need to make that
interpretation when it is immediately followed by "in". This suspicion
is strengthened by the fact that "bar !in baz" is fine, as is
"(foo.bar) !in baz".
Should I file this as a bug?
Small sample program:
struct Foo {
uint bar;
}
struct Baz {
bool opIn_r(uint e) {
return false;
}
}
void main() {
Baz baz;
Foo foo;
auto res = (foo.bar) !in baz;
res = !(foo.bar in baz);
// res = foo.bar !in baz; // Not OK...
uint frozz;
res = frozz !in baz;
}
--
Magnus Lie Hetland
http://hetland.org
Re: Points and Vectors in 3D
On 13/03/2011 15:29, Simen kjaeraas wrote: On Sun, 13 Mar 2011 15:43:09 +0100, Simon wrote: Convention is to use ^ as cross product and * as dot product. Really? I've never heard of it. Rather, everyone I've talked to about it has said exactly what I did. Openscenegraph uses those conventions and I've seen it used elsewhere as well. Not sure where they originated though. Seeing as dot & cross product are very common, having them as operators is really handy. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: Points and Vectors in 3D
On Sun, Mar 13, 2011 at 9:11 AM, Simen kjaeraas wrote: > Spacen Jasset wrote: > > Can't see a fitting operator in D. Multiplication (*) is ambiguous at best > and no other operator seems fitting. > > I agree. It's just better do define 'dot' and 'cross'. That's how it's done in Eigen and it works great.
Re: Points and Vectors in 3D
On Sun, 13 Mar 2011 15:43:09 +0100, Simon wrote: On 13/03/2011 14:11, Simen kjaeraas wrote: Spacen Jasset wrote: On 13/03/2011 00:06, Bekenn wrote: On 3/12/2011 2:20 PM, Simon wrote: I've done lots of 3d over the years and used quite a lot of different libraries and I've come to prefer code that makes a distinction between points and vectors. Agreed. This has some nice benefits with operator overloading, as well: vec v = ...; pt p = ...; auto p2 = p + v; // p2 is pt auto p3 = p + p2; // error auto v2 = v + v; // v2 is vec ...and with properties: p.x = 5; // p is pt, sets p._vals[0] v.dx = 3; // v is vec, sets v._vals[0] Would you then go on to define things like a cross product as an operator overload? Can't see a fitting operator in D. Multiplication (*) is ambiguous at best and no other operator seems fitting. Convention is to use ^ as cross product and * as dot product. Really? I've never heard of it. Rather, everyone I've talked to about it has said exactly what I did. -- Simen
Re: Points and Vectors in 3D
On 13/03/2011 14:11, Simen kjaeraas wrote: Spacen Jasset wrote: On 13/03/2011 00:06, Bekenn wrote: On 3/12/2011 2:20 PM, Simon wrote: I've done lots of 3d over the years and used quite a lot of different libraries and I've come to prefer code that makes a distinction between points and vectors. Agreed. This has some nice benefits with operator overloading, as well: vec v = ...; pt p = ...; auto p2 = p + v; // p2 is pt auto p3 = p + p2; // error auto v2 = v + v; // v2 is vec ...and with properties: p.x = 5; // p is pt, sets p._vals[0] v.dx = 3; // v is vec, sets v._vals[0] Would you then go on to define things like a cross product as an operator overload? Can't see a fitting operator in D. Multiplication (*) is ambiguous at best and no other operator seems fitting. Convention is to use ^ as cross product and * as dot product. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: Points and Vectors in 3D
Spacen Jasset wrote: On 13/03/2011 00:06, Bekenn wrote: On 3/12/2011 2:20 PM, Simon wrote: I've done lots of 3d over the years and used quite a lot of different libraries and I've come to prefer code that makes a distinction between points and vectors. Agreed. This has some nice benefits with operator overloading, as well: vec v = ...; pt p = ...; auto p2 = p + v; // p2 is pt auto p3 = p + p2; // error auto v2 = v + v; // v2 is vec ...and with properties: p.x = 5; // p is pt, sets p._vals[0] v.dx = 3; // v is vec, sets v._vals[0] Would you then go on to define things like a cross product as an operator overload? Can't see a fitting operator in D. Multiplication (*) is ambiguous at best and no other operator seems fitting. I'd like to have more of unicode's mathematical operators and symbols[1] as operators in D, but currently that's beyond the horizon. Use cases: Vector a, b; auto angle = a ∠ b; assert( a == (b ∓ .1) ); assert( ( a ∟ b ) == ( angle == degrees( 90 ) ) ); assert( a ∥ b ); auto v = a ⋅ b; Set c = ∅, d = ∅; auto union = c ∪ d; auto intersection = c ∩ d; assert( "foo" ∈ c ); assert( "foo" ∉ d ); assert( d ∌ "foo" ); assert( c ∋ "foo" ); assert( d ⊂ c ); assert( d ⊅ c ); assert( ∏[1,2,3] == ∑[1,2,3] ); Of course, this requires a method for typing these symbols, something which TeX has already solved for us. [1]: http://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode -- Simen
Re: Ranges
On 03/13/2011 01:05 AM, Jonathan M Davis wrote: If you were to try and iterate over a char[] by char, then you would be looking at code units rather than code points which is _rarely_ what you want. If you're dealing with anything other than pure ASCII, you _will_ have bugs if you do that. You're supposed to use dchar with foreach and character arrays. That way, each value you process is a valid character. Ranges do the same, only you don't give them an iteration type, so they're _always_ iterating over dchar. Side-note: you can be sure the source is pure ASCII if, and only if, it is mechanically produced. (As soon as an end-user touches it, it may hold anything, since OSes and apps offer users means to introduces characters which are not on their keyboards). This can also easily be checked in utf-8 (which has been designed for that): all ASCII chars are coded using the same code as in ASCII, thus all codes should be < 128. Denis -- _ vita es estrany spir.wikidot.com
Re: Points and Vectors in 3D
On 13/03/2011 00:06, Bekenn wrote: On 3/12/2011 2:20 PM, Simon wrote: I've done lots of 3d over the years and used quite a lot of different libraries and I've come to prefer code that makes a distinction between points and vectors. Agreed. This has some nice benefits with operator overloading, as well: vec v = ...; pt p = ...; auto p2 = p + v; // p2 is pt auto p3 = p + p2; // error auto v2 = v + v; // v2 is vec ...and with properties: p.x = 5; // p is pt, sets p._vals[0] v.dx = 3; // v is vec, sets v._vals[0] Would you then go on to define things like a cross product as an operator overload?
