On Jun 22, 2012, at 11:17 AM, Henrik Valter Vogelius Hansson wrote:
>
> Aight been reading a lot now about it. I'm interested in the TaskPool but
> there is a problem and also why I have to think about threads. OpenGL/DirectX
> contexts are only valid for one thread at a time. And with the task
On Sunday, 17 June 2012 at 07:23:38 UTC, Russel Winder wrote:
On Sun, 2012-06-17 at 03:15 +0200, Henrik Valter Vogelius
Hansson wrote:
Hi again!
I have looked around a little with what D offers but don't
know really what I should use since D offers several ways to
use threads. Some more high
I'm sorry, what I meant was "how to interface to C code". Sorry
for writing it in a bad way.
Do I just declare the C code as extern and then link together
with the C .lib/.o/.so file? (I'm in Ubuntu)
What about the stuff that is in header files?
On Friday, June 22, 2012 19:59:48 David wrote:
> Am 22.06.2012 16:55, schrieb Namespace:
> > If you have a null object you get an Access Violation without _any_
> > further information. That totally sucks.
>
> I don't know what you're doing or which debugger you use, gdb shows me
> exactly what ha
Am 22.06.2012 16:55, schrieb Namespace:
If you have a null object you get an Access Violation without _any_
further information. That totally sucks.
I don't know what you're doing or which debugger you use, gdb shows me
exactly what happened (line + stack + object).
And in my opinion a smal
On Fri, 22 Jun 2012 15:55:12 +0100, Namespace
wrote:
If you have a null object you get an Access Violation without _any_
further information. That totally sucks.
It doesn't have to be that way.
A debug executable contains all sort of debugging information and a Just
In Time debugger can
If you have a null object you get an Access Violation without
_any_ further information. That totally sucks.
And in my opinion a small "Ref!Type" is more informative for
others who use your code and you do not have to write assert(obj
!is null); any time in any method again.
And yes my program
Am 22.06.2012 12:52, schrieb Namespace:
On my machine it is the compiler that crashes => compiler bug.
Presumably it is having trouble with the circular alias this.
My first try to avoid this "circular" bug work with opDispatch. (As you
can read here on my blog: http://blog.rswhite.de/archives/
Dmitry Olshansky:
then every array is implicitly castable to tail immutable.
int[] array = [1, 2];
foreach (ref immutable(int) x; array) {
...
func(arr); // arr is mutable, thus func can change x
// so x can be at most const
}
I understand, thank you :-)
Bye,
On 22-Jun-12 16:16, bearophile wrote:
Tobias Pankrath:
I think it's good. In this special case, the compiler can see that you
can't change array behind his back. That seems not to be true in general.
But aren't int implicitly castable to immutable?
then every array is implicitly castable t
Tobias Pankrath:
I think it's good. In this special case, the compiler can see
that you can't change array behind his back. That seems not to
be true in general.
But aren't int implicitly castable to immutable?
Bye,
bearophile
On Friday, 22 June 2012 at 11:07:14 UTC, bearophile wrote:
Is this expected and good?
void main() {
int[] array = [1, 2];
foreach (ref const(int) x; array) {} // OK
foreach (ref immutable(int) x; array) {} // error
}
DMD 2.060alpha:
temp.d(4): Error: argument type mismatch, int to
On Friday, 22 June 2012 at 10:19:13 UTC, Timon Gehr wrote:
On 06/22/2012 08:45 AM, Tobias Pankrath wrote:
import std.container;
struct A {};
void main()
{
Array!(A)* arr = new Array!(A);
}
yields
bug.d(7): Error: template std.container.Array!(A).Array.__ctor
does not
match any function te
Is this expected and good?
void main() {
int[] array = [1, 2];
foreach (ref const(int) x; array) {} // OK
foreach (ref immutable(int) x; array) {} // error
}
DMD 2.060alpha:
temp.d(4): Error: argument type mismatch, int to ref
immutable(int)
Thank you,
bye,
bearophile
On my machine it is the compiler that crashes => compiler bug.
Presumably it is having trouble with the circular alias this.
My first try to avoid this "circular" bug work with opDispatch.
(As you can read here on my blog:
http://blog.rswhite.de/archives/741)
Now i had a new idea to save the R
On 06/22/2012 12:25 PM, Namespace wrote:
As far as i know "int" is not immutable or const by default.
So, why work this code:
[code]
import std.stdio;
class Bar {
}
class Foo {
private:
int _id;
Bar _b;
public:
this(int id, Bar b) {
this._id = id;
this._b =
On Friday, 22 June 2012 at 09:18:38 UTC, simendsjo wrote:
Bug or by design? (using dmd head)
import std.conv;
void main() {
to!(ubyte[])("");
}
std/array.d(493): Attempting to fetch the front of an empty
array of immutable(char)
[snip]
It is design. With the conversion from string to no
On 06/22/2012 12:22 PM, Namespace wrote:
I have this code:
http://codepad.org/vz17iZrm
And as long as i comment out the assert's in the constructor on line 10
and the assert in the invariant on line 16 it works as i want.
But otherwise the compiler prints stackoverflow and that's all.
Why and h
On 22-06-2012 12:22, Namespace wrote:
I have this code:
http://codepad.org/vz17iZrm
And as long as i comment out the assert's in the constructor on line 10
and the assert in the invariant on line 16 it works as i want.
But otherwise the compiler prints stackoverflow and that's all.
Why and how
As far as i know "int" is not immutable or const by default.
So, why work this code:
[code]
import std.stdio;
class Bar {
}
class Foo {
private:
int _id;
Bar _b;
public:
this(int id, Bar b) {
this._id = id;
On 06/22/2012 11:21 AM, Namespace wrote:
Based to the current const discussions (once again) I wanted to appease
my curiosity and want to ask why the following code works as described
in the comments:
[code]
import std.stdio;
class Bar { }
class Foo {
private:
string _text;
Bar _b;
I have this code:
http://codepad.org/vz17iZrm
And as long as i comment out the assert's in the constructor on
line 10 and the assert in the invariant on line 16 it works as i
want.
But otherwise the compiler prints stackoverflow and that's all.
Why and how is the stack overflowed with an simp
On 06/22/2012 08:45 AM, Tobias Pankrath wrote:
import std.container;
struct A {};
void main()
{
Array!(A)* arr = new Array!(A);
}
yields
bug.d(7): Error: template std.container.Array!(A).Array.__ctor does not
match any function template declaration
/usr/include/d/std/container.d(1625): Error
Bug or by design? (using dmd head)
import std.conv;
void main() {
to!(ubyte[])("");
}
std/array.d(493): Attempting to fetch the front of an empty array of
immutable(char)
to(_d_assert_msg+0x45) [0x43700d]
to(@property dchar
std.array.front!(immutable(char)[]).front(imm
Based to the current const discussions (once again) I wanted to
appease my curiosity and want to ask why the following code works
as described in the comments:
[code]
import std.stdio;
class Bar { }
class Foo {
private:
string _text;
Bar _b;
public:
On Friday, June 22, 2012 11:09:13 maarten van damme wrote:
> It looks a bit "dirty" to
> convert to immutable and back to mutable simply to pass it over to
> another thread...
It is, but casting to shared and back again is pretty much the same thing. So,
in most cases, you're going to end up doin
Well, maybe idup is a bit better then assumeuniqe.
I don't work anymore with that mutable array on the workerthread but
using idup is in all cases allowed and cannot cause subtle bugs like
me reusing a mutable array that I've casted to immutable and send over
to another thread.
It's a shame that sh
Seems to me that you achieved the your first purpose. Do you
need more help?
Kenji Hara
I think i'm finished. Or have you any tip for me, related to the
code?
28 matches
Mail list logo
