On Sat, 14 Feb 2015 00:57:33 +, weaselcat wrote:
> On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
>> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>>> This is something I've done recently.
>>> Would be glad if my code will help you: https://github.com/Dgame/m3
>>> Es
On Fri, 13 Feb 2015 23:29:10 +, Foo wrote:
> Always the same in this newsgroup. You want to help as good as you can
> (even if it's not perfect) and all you get are subliminal messages... :)
code that you throwing at newcomer may not be perfect, but it at least
should not be wrong. your code
Is there a standard way to shallow copy objects?
eg:
class A{
int* a;
string b;
}
unittest{
auto a=new A;
a.a=new int(1);
a.b="asdf";
auto b=new A;
b.shallowCopyFrom(a);
assert(b.a==a.a);
assert(b.b==a.b);
}
How about:
option A1:
void shallowCopyFrom(T)(T a, T b) if(is(T==cla
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
/* Class and Str
Foo:
I'm regret that I tried to help, I will delete this repo as far
as possible. :)
Language communities aren't perfect, but the success of a
language comes from the help of many little hands :) Perhaps Rust
will "win" over D in the end, but there's no reason to throw away
your work just f
On Friday, 13 February 2015 at 23:29:11 UTC, Foo wrote:
On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote:
On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
Don't understand me wrong. My code is not perfect, but maybe
it can be helpful for someone.
As it is right now, I fear
On Friday, 13 February 2015 at 23:13:05 UTC, anonymous wrote:
On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
Don't understand me wrong. My code is not perfect, but maybe
it can be helpful for someone.
As it is right now, I fear it may do more harm than good.
Always the same in this
On Friday, 13 February 2015 at 23:04:25 UTC, Foo wrote:
Don't understand me wrong. My code is not perfect, but maybe it
can be helpful for someone.
As it is right now, I fear it may do more harm than good.
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
/* Class and Str
On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
This is something I've done recently.
Would be glad if my code will help you:
https://github.com/Dgame/m3
Especially the m3.d module could be useful for you.
/* Class and Struct */
emplace: You can't assume zero-initialization for struc
H. S. Teoh:
So it could be called ilog2?
Perhaps floorIlog2? Isn't ilog2 a different function?
Bye,
bearophile
On Fri, Feb 13, 2015 at 07:54:32PM +, via Digitalmars-d-learn wrote:
> On Friday, 13 February 2015 at 15:14:44 UTC, H. S. Teoh wrote:
> >Isn't it essentially floor(log_2(a)), mathematically speaking? Maybe
> >that could be the basis of a better name?
>
> integer log2:
> https://graphics.stanfo
On Friday, 13 February 2015 at 05:56:37 UTC, Jakob Ovrum wrote:
This issue, ... [is] related to the loss of guarantee
attributes when using TypeInfo methods, most recently discussed
in this thread[1]. It is essentially a bug, and a work in
progress.
I see. So, in theory, after some patching e
On 2/13/15 4:08 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath wrote:
1. Throw preallocated exceptions is the way to go
and because noone has yet shown an explicit example:
void myThrowingNogcFunc() @nogc {
static co
On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath
wrote:
1. Throw preallocated exceptions is the way to go
... and because noone has yet shown an explicit example:
void myThrowingNogcFunc() @nogc {
static const exc = new Exception("something went wrong");
throw e
On Friday, 13 February 2015 at 15:14:44 UTC, H. S. Teoh wrote:
Isn't it essentially floor(log_2(a)), mathematically speaking?
Maybe
that could be the basis of a better name?
integer log2:
https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogFloat
On Friday, 13 February 2015 at 19:10:00 UTC, Adam D. Ruppe wrote:
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler
wrote:
T construct(T,A...)(void* buffer, A args)
{
return (cast(T)buffer).__ctor(args);
}
This is wrong, you need to initialize the memory first to the
proper values
On Friday, 13 February 2015 at 19:13:02 UTC, Steven Schveighoffer
wrote:
You need to actually allocate the memory on the heap. Your data
lives on the stack frame of main, which goes away as soon as
main exits, and your exception is caught outside main.
-Steve
Yes I am aware of this. That do
On 2/13/15 2:03 PM, Jonathan Marler wrote:
This question comes from wanting to be able to throw an exception in
code that is @nogc.
I don't know if it's possible but I'd like to be able to throw an
exception without allocating memory for the garbage collector? You can
do it in C++ so I think you
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler
wrote:
T construct(T,A...)(void* buffer, A args)
{
return (cast(T)buffer).__ctor(args);
}
This is wrong, you need to initialize the memory first to the
proper values for the class, gotten via typeid(T).init.
std.conv.emplace does
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler
wrote:
This question comes from wanting to be able to throw an
exception in code that is @nogc.
I don't know if it's possible but I'd like to be able to throw
an exception without allocating memory for the garbage
collector? You ca
This question comes from wanting to be able to throw an exception
in code that is @nogc.
I don't know if it's possible but I'd like to be able to throw an
exception without allocating memory for the garbage collector?
You can do it in C++ so I think you should be able to in D. One
idea I ha
On Friday, 13 February 2015 at 09:18:29 UTC, Mike Parker wrote:
On 2/13/2015 6:14 PM, Mike Parker wrote:
On 2/13/2015 12:46 PM, Bennet wrote:
I've begun writing some basic OpenGL code using DerelictGL3
but I've hit
a wall. I've managed to open a window (with DerelictSDL2) and
call basic
OpenGL
On 2/13/15 9:01 AM, anonymous wrote:
On Friday, 13 February 2015 at 13:25:55 UTC, Steven Schveighoffer wrote:
Yes, the operator precedence (curiously not defined in the spec) is here:
http://wiki.dlang.org/Operator_precedence
Conditional operator is above assignment operators.
It's specified
H. S. Teoh:
Maybe that could be the basis of a better name?
Right.
Bye,
bearophile
On Fri, Feb 13, 2015 at 12:28:23PM +, bearophile via Digitalmars-d-learn
wrote:
> Dominikus Dittes Scherkl:
>
> >I would recommend to use something like this:
> >
> >/// returns the number of the highest set bit +1 in the given value
> >/// or 0 if no bit is set
> >size_t bitlen(T)(const(T) a
On Friday, 13 February 2015 at 13:25:55 UTC, Steven Schveighoffer
wrote:
On 2/13/15 7:38 AM, tcak wrote:
On Friday, 13 February 2015 at 09:38:04 UTC, Dennis Ritchie
wrote:
This is a bug?
import std.stdio;
void main() {
int a = 0;
writeln( (a < 10) ? a = 1 : a = 2 );// prints 2
On Friday, 13 February 2015 at 09:38:04 UTC, Dennis Ritchie wrote:
This is a bug?
import std.stdio;
void main() {
int a = 0;
writeln( (a < 10) ? a = 1 : a = 2 );// prints 2
writeln( (a < 10) ? a = 1 : (a = 2) ); // prints 1
}
Even C++ output:
1
1
Maybe a similar issue as t
On Friday, 13 February 2015 at 13:25:55 UTC, Steven Schveighoffer
wrote:
Yes, the operator precedence (curiously not defined in the
spec) is here:
http://wiki.dlang.org/Operator_precedence
Conditional operator is above assignment operators.
It's specified through the grammar [1]:
Assig
On 2/13/15 7:38 AM, tcak wrote:
On Friday, 13 February 2015 at 09:38:04 UTC, Dennis Ritchie wrote:
This is a bug?
import std.stdio;
void main() {
int a = 0;
writeln( (a < 10) ? a = 1 : a = 2 );// prints 2
writeln( (a < 10) ? a = 1 : (a = 2) ); // prints 1
}
Even C++ output:
On Friday, 13 February 2015 at 13:07:04 UTC, bearophile wrote:
I suggest you to read how a mark&sweep GC works, or better to
implement a bare-bones mark&sweep GC in C language yourself for
Lisp-like cons cells, you only need 100 lines of code or so to
do it.
Got it. Thanks.
Per Nordlöw:
Then how does the GC know when to release when there are
multiple references?
The mark phase counts what's reachable and what can't be reached.
If an object has one pointer to it, or one hundred pointers, it
is not removed. If nothing points to it, it is removed.
I suggest you
On Friday, 13 February 2015 at 12:58:40 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 12:50:14 UTC, Tobias Pankrath
wrote:
There are no reference counts involved, just simple arithmetic.
string a = "abc";
string b = a[1 .. $];
Then how does the GC know when to release when there are
On Friday, 13 February 2015 at 12:50:14 UTC, Tobias Pankrath
wrote:
There are no reference counts involved, just simple arithmetic.
string a = "abc";
string b = a[1 .. $];
Then how does the GC know when to release when there are multiple
references?
Is this because string references immutab
On Friday, 13 February 2015 at 12:40:57 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 11:52:50 UTC, Tobias Pankrath
wrote:
On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined b
On Friday, 13 February 2015 at 11:52:50 UTC, Tobias Pankrath
wrote:
On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined by s.front
implementation, caller can't affect it.
Compiling
h
On Friday, 13 February 2015 at 09:38:04 UTC, Dennis Ritchie wrote:
This is a bug?
import std.stdio;
void main() {
int a = 0;
writeln( (a < 10) ? a = 1 : a = 2 );// prints 2
writeln( (a < 10) ? a = 1 : (a = 2) ); // prints 1
}
Even C++ output:
1
1
About 2 years ago, I had a
Tobias Pankrath:
Why should splitter.front allocate?
I think that front was able to throw Unicode exceptions, that
require the GC. But I think later they have become asserts, that
don't require the GC.
Bye,
bearophile
Dominikus Dittes Scherkl:
I would recommend to use something like this:
/// returns the number of the highest set bit +1 in the given
value or 0 if no bit is set
size_t bitlen(T)(const(T) a) pure @safe @nogc nothrow
if(isUnsigned!T)
{
static if(T.sizeof <= size_t.sizeof) // doesn't work f
On Friday, 13 February 2015 at 11:34:50 UTC, Per Nordlöw wrote:
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined by s.front
implementation, caller can't affect it.
Compiling
https://github.com/nordlow/justd/blob/master/t_splitter.d
with -vgc o
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined by s.front
implementation, caller can't affect it.
Compiling
https://github.com/nordlow/justd/blob/master/t_splitter.d
with -vgc on dmd git master gives no warnings about GC
allocations!
Is th
On Friday, 13 February 2015 at 08:21:53 UTC, Per Nordlöw wrote:
When reading/parsing data from disk often try to write code
such as
foreach (const line; File(filePath).byLine)
{
auto s = line.splitter(" ")
const x = s.front.to!uint; s.popFront;
const y = s.front
On Friday, 13 February 2015 at 09:13:48 UTC, Kagamin wrote:
Whether s.front uses GC is determined by s.front
implementation, caller can't affect it.
I'm talking about internal changes to DMD, in this case.
Yeah, since @trusted is checked manually, it's sort of a problem,
if you don't know, how to check it.
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote:
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:
And I wouldn't say indiscriminately. Every function I marked
with @trusted was checked by me so far.
What did you check them for? :)
Just first example: make and destruct, being
This is a bug?
import std.stdio;
void main() {
int a = 0;
writeln( (a < 10) ? a = 1 : a = 2 );// prints 2
writeln( (a < 10) ? a = 1 : (a = 2) ); // prints 1
}
Even C++ output:
1
1
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:
And I wouldn't say indiscriminately. Every function I marked
with @trusted was checked by me so far.
What did you check them for? :)
Just first example: make and destruct, being marked as @trusted,
don't prevent caller from UAF and double
On 2/13/2015 6:14 PM, Mike Parker wrote:
On 2/13/2015 12:46 PM, Bennet wrote:
I've begun writing some basic OpenGL code using DerelictGL3 but I've hit
a wall. I've managed to open a window (with DerelictSDL2) and call basic
OpenGL functions such as glClear(). Still I can not get a basic triangle
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote:
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:
And since today it is @safe wherever possible.
Well, you marked functions @trusted rather indiscriminately :)
Such approach doesn't really improve safety, and the code could
w
Whether s.front uses GC is determined by s.front implementation,
caller can't affect it.
On 2/13/2015 12:46 PM, Bennet wrote:
I've begun writing some basic OpenGL code using DerelictGL3 but I've hit
a wall. I've managed to open a window (with DerelictSDL2) and call basic
OpenGL functions such as glClear(). Still I can not get a basic triangle
up and running. glError() does not return
On Monday, 19 January 2015 at 20:54:50 UTC, Steven Schveighoffer
wrote:
Cool. I would point out that the commented code suggests you
should be handling the 0 case, but you are not (when T.min ==
T.max)
Should I do a Phobos PR for this? If so where should I put it?
When reading/parsing data from disk often try to write code such
as
foreach (const line; File(filePath).byLine)
{
auto s = line.splitter(" ")
const x = s.front.to!uint; s.popFront;
const y = s.front.to!double; s.popFront;
...
}
In response to all the
void main(){
DerelictGL3.load();
//create your sdl context, window hints,
DerelictGL3.reload();
//Do other stuff...
}
You got to have a valid context before you call reload. These two
functions shall be called only once, I have the impression that
you call them multiple times.
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:
And since today it is @safe wherever possible.
Well, you marked functions @trusted rather indiscriminately :)
Such approach doesn't really improve safety, and the code could
work as well being @system. It's not like @system is inherentl
55 matches
Mail list logo
