On Wednesday, February 06, 2013 08:41:14 Jeremy DeHaan wrote:
> Out of curiosity, what exactly happens when we don't constrain
> what operators are being overloaded? Is it undefined behavior or
> will the program just not compile?
With no template constraint, a template will match anything with th
On Wednesday, 6 February 2013 at 06:38:11 UTC, Jonathan M Davis
wrote:
On Wednesday, February 06, 2013 07:24:10 Jeremy DeHaan wrote:
I've seen operator overloading done 3 different ways. In the
examples I provide they all compile and work as far as I can
tell. Is there any major difference betwe
On 2013-02-06 06:49, estew wrote:
Thanks for your help, much appreciated.
I'm using the delegates now for the callbacks. At your suggestion I'm
looking for a good way to change the design. I agree, the D type system
is way superior to that of C.
I would suggest you try to replace the array wit
On Wednesday, February 06, 2013 07:24:10 Jeremy DeHaan wrote:
> I've seen operator overloading done 3 different ways. In the
> examples I provide they all compile and work as far as I can
> tell. Is there any major difference between using a static if vs
> a regular if, or any situation that one wo
I've seen operator overloading done 3 different ways. In the
examples I provide they all compile and work as far as I can
tell. Is there any major difference between using a static if vs
a regular if, or any situation that one would be better than the
other?
struct Something1
{
Something1
On 6-2-2013 1:33, bearophile wrote:
Maybe this line:
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm.d#L9237
for (; !ahead.empty; ahead.popFront(), ++i)
Should be:
for (; !ahead.empty; ahead.popFront(), r.popFront(), ++i)
Thought that line loo
Thanks for your help, much appreciated.
I'm using the delegates now for the callbacks. At your suggestion
I'm looking for a good way to change the design. I agree, the D
type system is way superior to that of C.
Starting to get into mixins too, although I'm a bit wary of them.
I know they're
On Tue, 05 Feb 2013 23:17:59 -0500, Steven Schveighoffer
wrote:
e.g.:
import std.stdio;
void callit(void delegate() dg)
{
// call delegate with context pointer
dg();
}
void main()
{
int x;
auto dg = ()=>writeln(++x); // create a delegate using a lambda
function
On Tue, 05 Feb 2013 22:16:17 -0500, estew wrote:
Hi All,
I've some old C code which I'm porting to D. It's a learning exercise so
I don't want to just wrap the C lib.
I have an array of void* and an array of callbacks that take void*
pointers for user data.
I'm wondering what is a good
Hi All,
I've some old C code which I'm porting to D. It's a learning
exercise so I don't want to just wrap the C lib.
I have an array of void* and an array of callbacks that take
void* pointers for user data.
I'm wondering what is a good way to port this into D and avoid
the void*. My C++
Jonathan M Davis:
That definitely looks like a bug. "acbd" _isn't_ sorted.
OK. Thank you.
http://d.puremagic.com/issues/show_bug.cgi?id=9457
Brad Anderson:
Have a GitHub account, bearophile?
Not yet, but probably I will have one.
Just hit Edit at the top of
that
Have a GitHub account, bearophile? Just hit Edit at the top of
that link you gave, make the change, and click "Proposal File
Change" and it'll roll up a pull request. Should take less than a
minute. I use this for almost every minor pull requests I do. The
autotester takes care of the rest.
Looks
On Wednesday, February 06, 2013 01:33:29 bearophile wrote:
> This used to print true-false, now prints true-true. Is this a
> bug?
>
>
> import std.stdio, std.algorithm;
> void main() {
> auto x = "abcd";
> writeln(isSorted(x));
> auto y = "acbd";
> writeln(isSorted(y));
> }
>
This used to print true-false, now prints true-true. Is this a
bug?
import std.stdio, std.algorithm;
void main() {
auto x = "abcd";
writeln(isSorted(x));
auto y = "acbd";
writeln(isSorted(y));
}
Maybe this line:
https://github.com/D-Programming-Language/phobos/blob/master/std
Jos van Uden:
How do we avoid working on the same thing?
With a little coordination :-)
Partial translation of rcrpg-Python:
http://codepad.org/SflrKqbT
Partial translation of
permutations_rank_of_a_permutation-Python:
http://codepad.org/El9SQwOE
The 2 above, I could try.
Plus a bett
On Tuesday, 5 February 2013 at 21:14:32 UTC, Nick Treleaven wrote:
On 05/02/2013 21:13, Nick Treleaven wrote:
I've just tried it with dmd 2.059 (haven't upgraded yet)
sorry, 2.060
Right, it's "alias" being finicky, because "args.length" isn't an
actual variable (it's a property). The proble
On 02/05/2013 08:48 PM, SaltySugar wrote:
Thank you, Mike. One more question. Can I use hbox.add(btn); instead of
hbox.packStart (btn,false,false,5);
What difference between them?
Sorry, for my bad English.
hbox.add would call packStart with the defaults, witch would be
packStart(btn, true, t
On 05/02/2013 21:13, Nick Treleaven wrote:
I've just tried it with dmd 2.059 (haven't upgraded yet)
sorry, 2.060
On 05/02/2013 21:02, monarch_dodra wrote:
On Tuesday, 5 February 2013 at 20:47:46 UTC, Nick Treleaven wrote:
On 05/02/2013 16:47, monarch_dodra wrote:
T[] stack(T, alias N)(void* m = alloca(T.sizeof * N))
{
return (cast(T*)m)[0 .. N];
}
This works if you know N at compile-time. But there
On Tuesday, 5 February 2013 at 20:47:46 UTC, Nick Treleaven wrote:
On 05/02/2013 16:47, monarch_dodra wrote:
On Tuesday, 5 February 2013 at 16:37:41 UTC, Nick Treleaven
wrote:
I've just realized this doesn't work for variable-length
allocation:
T[] stack(T)(size_t N, void* m = alloca(T.sizeof
On 05/02/2013 16:47, monarch_dodra wrote:
On Tuesday, 5 February 2013 at 16:37:41 UTC, Nick Treleaven wrote:
I've just realized this doesn't work for variable-length allocation:
T[] stack(T)(size_t N, void* m = alloca(T.sizeof * N))
Error: undefined identifier N, did you mean alias T?
N is no
On 5-2-2013 21:10, bearophile wrote:
How do we avoid working on the same thing?
Partial translation of rcrpg-Python:
http://codepad.org/SflrKqbT
Partial translation of permutations_rank_of_a_permutation-Python:
http://codepad.org/El9SQwOE
The 2 above, I could try.
Plus a better Perl implem
On 2013-02-05 20:48, SaltySugar wrote:
Can I use hbox.add(btn); instead of hbox.packStart (btn,false,false,5);
What difference between them?
Using add(btn) you would probably end up with a stretched button again. :)
hbox.packStart(child, expand, fill, padding)
It was explicitly said that ex
Jos van Uden:
I'll give it a shot if you like. The RCRPG I'd like to try
first.
I have already partially written those:
Partial translation of rcrpg-Python:
http://codepad.org/SflrKqbT
Partial translation of permutations_rank_of_a_permutation-Python:
http://codepad.org/El9SQwOE
Plus a better
Why not:
[code]
T[] stack(T, const size_t N)(void* m = alloca(T.sizeof * N))
{
return (cast(T*)m)[0 .. N];
}
[/code]
?
On Tuesday, 5 February 2013 at 19:31:01 UTC, Mike Wey wrote:
On 02/05/2013 06:33 PM, SaltySugar wrote:
I can't find any tutorials about buttonboxes. Can you write
how to use it?
Here is a small example:
import gtk.MainWindow;
import gtk.Button;
import gtk.Main;
import gtk.HButtonBox;
class A
On 5-2-2013 0:55, bearophile wrote:
Is the Fwend user of Rosettacode (or some other interested person) around here?
I have written partial D implementations
for three tasks, maybe a little of coordination will speedup the work:
http://rosettacode.org/wiki/Permutations/Rank_of_a_permutation
http
On 02/05/2013 06:33 PM, SaltySugar wrote:
I can't find any tutorials about buttonboxes. Can you write how to use it?
Here is a small example:
import gtk.MainWindow;
import gtk.Button;
import gtk.Main;
import gtk.HButtonBox;
class Application : MainWindow
{
this()
{
super("GtkD
On Tue, Feb 05, 2013 at 07:38:40PM +0100, bearophile wrote:
> H. S. Teoh:
>
> >Added to wiki: http://wiki.dlang.org/Dense_multidimensional_arrays
>
> It contains:
>
> enum columns = 100;
> int rows = 100;
> double[gridSize][] gridInfo = new double[columns][](rows);
>
>
> gridSize is undefined.
H. S. Teoh:
Added to wiki:
http://wiki.dlang.org/Dense_multidimensional_arrays
It contains:
enum columns = 100;
int rows = 100;
double[gridSize][] gridInfo = new double[columns][](rows);
gridSize is undefined. I suggest to write something like:
enum nColumns = 100;
int nRows = 120;
double[
On Tuesday, 5 February 2013 at 17:05:23 UTC, Dan wrote:
But why does this even code work? I would have thought const
guarantee would prevent calls to non-const postblit function. I
was under impression this(this) const does not work - but maybe
that has changed with 2.061.
Forgot to mention,
On Mon, Feb 04, 2013 at 04:58:36PM +0100, bearophile wrote:
> monarch_dodra:
>
> >If all (but last of) the dimensions are known at compile time,
> >then you can dynamically allocate an array of fixed sized arrays:
> >
> >//
> >enum size_t gridSize = 4_000;
> >enum size_t total = gridSize * g
On Monday, 4 February 2013 at 21:55:24 UTC, Mike Wey wrote:
On 02/04/2013 03:03 PM, SaltySugar wrote:
On Sunday, 3 February 2013 at 16:07:06 UTC, Artur Skawina
wrote:
On 02/03/13 16:53, SaltySugar wrote:
GTKD. Can someone explain me how to change button size in
vbox, hbox?
setSizeRequest (70,
On Tuesday, 5 February 2013 at 16:36:16 UTC, Maxim Fomin wrote:
This does not imply such situation, simply there is a problem.
You can workaround by
[snip]
struct RC {
int i;
void postblit() { i = -5; }
this(this) const
{
void delegate() dg = &postblit;
dg();
On Tuesday, 5 February 2013 at 16:37:41 UTC, Nick Treleaven wrote:
On 05/02/2013 16:17, Nick Treleaven wrote:
On 03/02/2013 13:22, bearophile wrote:
Era Scarecrow:
On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
Sure, but alloca has the same ugly interface as malloc. :/
You me
Nick Treleaven:
^ I know you're aware of this, but maybe others might not know
the default-argument alloca wrapping trick:
For some usages it's an improvement over raw usage of alloca.
I did see this in past, but sometimes I forget.
Bye,
bearophile
On 05/02/2013 16:17, Nick Treleaven wrote:
On 03/02/2013 13:22, bearophile wrote:
Era Scarecrow:
On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
Sure, but alloca has the same ugly interface as malloc. :/
You mean that you have to specify how many raw bytes you want, then
cast
On Tuesday, 5 February 2013 at 15:49:59 UTC, Dan wrote:
- Wouldn't the scenario be exactly the same without
ValuationHistory? That is, if I comment out the member
_valuationHistory, the goo member is not changed in structure
at all, and yet it compiles just fine.
Scenario is the same if the
On 03/02/2013 13:22, bearophile wrote:
Era Scarecrow:
On Sunday, 3 February 2013 at 09:11:59 UTC, Namespace wrote:
Sure, but alloca has the same ugly interface as malloc. :/
You mean that you have to specify how many raw bytes you want, then
cast it to what you need? I never thought alloca
On Tuesday, 5 February 2013 at 15:06:47 UTC, Maxim Fomin wrote:
The root of the problem is in:
struct DAssociativeArray(Key, Value)
{
struct Slot
{
Value value;
}
}
struct RC {
this(this) { }
}
void main()
{
DAssociativeArray!(int, const(RC)) goo;
}
which doesn't co
On Tuesday, 5 February 2013 at 12:35:25 UTC, Dan wrote:
Is it the case that this is a D compiler (or library) problem
and there is no issue with the code? Or is there really a
problem with it that I am not seeing? I gather from the
responses the code looks fine, otherwise any misunderstanding
On Tuesday, 5 February 2013 at 11:51:40 UTC, Maxim Fomin wrote:
On Tuesday, 5 February 2013 at 04:03:06 UTC, Andrej Mitrovic
wrote:
Yeah, it's still not very helpful. And I have no idea where
"Slot" comes from.
This is sub struct inside object.AssociativeArray.
Is it the case that this is a
On Tuesday, 5 February 2013 at 01:15:28 UTC, Dan wrote:
I've seen these type of errors often and usually the cause kind
of jumps out. In this case I'm totally confused. Just trying to
move from 2.06 to 2.061.
The code is: http://dpaste.dzfl.pl/f40e4d6f
and fails with the error in subject line.
On Tuesday, 5 February 2013 at 04:03:06 UTC, Andrej Mitrovic
wrote:
Yeah, it's still not very helpful. And I have no idea where
"Slot" comes from.
This is sub struct inside object.AssociativeArray.
44 matches
Mail list logo
