I commented in github.
Thx!
On Sun, 08 Jun 2014 19:44:12 +, monarch_dodra wrote:
> On Sunday, 8 June 2014 at 18:28:25 UTC, Byron wrote:
>> void c_free(bar* b) { b = null; }
>
> Heads up: This code does nothing. You are passing the pointer by value,
> so "b = null;" will have no effect at the end of the call.
> Use pass
On Sunday, 8 June 2014 at 18:28:25 UTC, Byron wrote:
void c_free(bar* b) { b = null; }
Heads up: This code does nothing. You are passing the pointer by
value, so "b = null;" will have no effect at the end of the call.
Use pass by ref:
void c_free(ref bar* b) { b = null; }
On Sunday, 8 June 2014 at 18:48:03 UTC, monarch_dodra wrote:
Mixin templates can only insert declarations, not arbitrary
code. When it sees "scope", it's expecting it to be the
attribute, not the declaration.
To add to that, if you want to mixin arbitrary code, then you can
use a string mixin
On Sunday, 8 June 2014 at 18:28:25 UTC, Byron wrote:
Can we not use scope(..) in a mixin template?
struct bar {}
bar* c_make() { return new bar(); }
void c_free(bar* b) { b = null; }
mixin template Foo() {
auto b = c_make;
scope(exit) if(b) c_free(b);
}
void main() {
mixin Foo;
}
I get
Can we not use scope(..) in a mixin template?
struct bar {}
bar* c_make() { return new bar(); }
void c_free(bar* b) { b = null; }
mixin template Foo() {
auto b = c_make;
scope(exit) if(b) c_free(b);
}
void main() {
mixin Foo;
}
I get Error: Declaration expected, not '('
-Byron
On 08/06/14 18:41, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
On 08/06/14 10:47, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
Issue report submitted: https://i
On 08/06/14 10:47, Joseph Rushton Wakeling via Digitalmars-d-learn wrote:
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
Issue report submitted: https://issues.dlang.org/show_bug.cgi?id=12877
On 08/06/14 16:25, monarch_dodra via Digitalmars-d-learn wrote:
Arguably, the issue is the difference between "invalid" and downright "illegal"
values. The thing about dchar is that while it *can* have values higher than
dchar max, it's (AFAIK) illegal to have them, and the compiler (if it can) w
On Sunday, 8 June 2014 at 13:55:48 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
On Sun, Jun 08, 2014 at 11:17:41AM +0200, Joseph Rushton
Wakeling via Digitalmars-d-learn wrote:
On 08/06/14 11:02, monarch_dodra via Digitalmars-d-learn wrote:
>Why would we ban uniform!T from accepting dchar? I s
On Sun, Jun 08, 2014 at 11:17:41AM +0200, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
> On 08/06/14 11:02, monarch_dodra via Digitalmars-d-learn wrote:
> >Why would we ban uniform!T from accepting dchar? I see no reason for that.
> >
> >Let's just fix the bug by tweaking the internal ch
On Sat, Jun 7, 2014 at 10:59 AM, Tom Browder wrote:
> Given a single ddoc source file (with no D source), how can one
> generate the default html output?
I solved the problem by starting with the build system for the D lang
web site here:
https://github.com/D-Programming-Language/dlang.org
So
@monoarch_dodra
I solved BogoSort
import std.stdio, std.algorithm, std.random;
void bogoSort(T)(T[] data) {
while (!isSorted(data))
randomShuffle(data);
}
void main() {
auto array = [2, 7, 41, 11, 3, 1, 6, 5, 8];
bogoSort(array);
writeln(array);
}
https://github.com/ag
On Sunday, 8 June 2014 at 08:44:42 UTC, monarch_dodra wrote: of.
If you want to use a bad algorithm, you could also go for
bogosort:
void main() {
auto data = [2, 7, 4, 3, 5, 1, 0, 9, 8, 6, -1];
while (!isSorted(data))
randomShuffle(data);
data.writeln;
}
I'm partial to Mi
On Friday, 6 June 2014 at 16:33:27 UTC, Adam D. Ruppe wrote:
When you compile the final program, the library .d file needs
to be available too, either in the folder based on its name or
passed straight to dmd explicitly.
Despite the presence of the .lib file, the .d file is still
needed so it
On 08/06/14 11:02, monarch_dodra via Digitalmars-d-learn wrote:
Why would we ban uniform!T from accepting dchar? I see no reason for that.
Let's just fix the bug by tweaking the internal check.
Yea, I came to the same conclusion while working on it. :-)
The solution I have is (i) in uniform!"
On Sunday, 8 June 2014 at 08:54:30 UTC, Joseph Rushton Wakeling
via Digitalmars-d-learn wrote:
I think it should suffice to forbid uniform!T from accepting
dchar parameters and to tweak the integral-type uniform()'s
internal check to avoid calling that specialization with dchar.
Thoughts ... ?
Hello all,
Here's an interesting little bug that arises when std.random.uniform is called
using dchar as the variable type:
//
import std.conv, std.random, std.stdio, std.string, std.typetuple;
void main()
{
forea
On Saturday, 7 June 2014 at 22:01:25 UTC, Ali GOREN wrote:
Thank you. I can not resolve it in quicker time, right?
Depends what exactly you want to achieve. This will achieve the
same result in a fraction of the time.
void main() {
auto data = [2, 7, 4, 3, 5, 1, 0, 9, 8, 6, -1];
sort
19 matches
Mail list logo
