On Wednesday, 28 January 2015 at 11:30:13 UTC, Marc Schütz wrote:
On Wednesday, 28 January 2015 at 09:44:29 UTC, zhmt wrote:
It is boring coding, I want a solution to copy them
automatically:
void copyObj(SRC,DEST)(SRC src,DEST dest)
{
foreach (i, type; typeof(SRC.tupleof)) {
On Wednesday, 14 January 2015 at 16:27:17 UTC, Laeeth Isharc
wrote:
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T :
On Wednesday, 14 January 2015 at 14:54:09 UTC, Laeeth Isharc
wrote:
In the hierarchy example above (c++ hdf hierarchy link), by
using UFCS to implement the shared methods (which are achieved
by multiple inheritance in the c++ counterpart) did you mean
something like this?
// id.d
struct ID
On Tuesday, 13 January 2015 at 18:19:42 UTC, ketmar via
Digitalmars-d-learn wrote:
and then you can go with structures in the first place, i think.
remember that you have that k00l `alias this` trick for them!
Which doesn't always help in case of multiple inheritance :( e.g.
the blasted hdf c++
On Tuesday, 13 January 2015 at 17:08:38 UTC, Laeeth Isharc wrote:
>> I see, thanks! :) I've started liking structs more and
>> more recently as well and been pondering on how to convert
>> a class-based code that looks like this (only the base
>> class has any data):
> it's hard to tell by brie
On Tuesday, 13 January 2015 at 16:43:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 13 Jan 2015 16:17:51 +
aldanor via Digitalmars-d-learn
wrote:
This discussion:
http://forum.dlang.org/thread/bqtcdpsopxmnfbjyr...@forum.dlang.org
-- led me wondering if it would be possible to
On Tuesday, 13 January 2015 at 18:12:45 UTC, aldanor wrote:
On Tuesday, 13 January 2015 at 16:43:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 13 Jan 2015 16:17:51 +
aldanor via Digitalmars-d-learn
wrote:
This discussion:
http://forum.dlang.org/thread/bqtcdpsopxmnfbjyr
ly sort of seems to work at first glance, at least it
seems like it does... But with my D experience being fairly
limited I wonder what the potential pitfalls would be?
Full source code with example and stdout:
https://gist.github.com/aldanor/d5fb5e45ddf3dd2cb642
On Tuesday, 13 January 2015 at 08:33:57 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 22:07:13 +
aldanor via Digitalmars-d-learn
wrote:
I see, thanks! :) I've started liking structs more and more
recently as well and been pondering on how to convert a
class-based
On Monday, 12 January 2015 at 21:54:51 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 21:37:27 +
aldanor via Digitalmars-d-learn
wrote:
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
Digitalmars-d-learn wrote:
> it even has `RefCounted!`, but it doesn't p
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
Digitalmars-d-learn wrote:
it even has `RefCounted!`, but it doesn't play well with
classes yet
(AFAIR).
I wonder if it's possible to somehow make a version of refcounted
that would work with classes (even if limited/restricted in some
cer
On Saturday, 10 January 2015 at 20:55:05 UTC, Laeeth Isharc wrote:
Hi Aldanor.
I wrote a slightly longer reply, but mislaid the file somewhere.
I guess your question might relate to wrapping the HDF5 library
- something that I have already done in a basic way, although I
welcome your project
Hi all,
I was wondering what's the most D-idiomatic way of dealing with a
C library (or rather writing wrappers for a C library) that does
its own GC via reference counting. The objects are identified and
passed around by integer ids only; most functions like "find me
an object foo in object
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby
wrote:
I was just taking a look at the following poll[1] about the
order of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
Is there a way to do something like this while keeping the
destructor nogc?
class Foo {
shared static Foo[id] registry;
int id;
this(int id) {
this.id = id(
registry[id] = this;
}
~this() }. // ideally should be tagged as @nogc
// nasty, memory corrup
On Friday, 26 December 2014 at 15:58:18 UTC, aldanor wrote:
Please ignore the missing "new" keywords in the code and other
minor typos :)
Any opinions please?.. Would be much appreciated.
Thanks!
On Saturday, 27 December 2014 at 10:54:01 UTC, Russel Winder via
Digitalmars-d-learn wrote:
I know much less about R, but the whole Python/NumPy thing
works but
only because it is faster and easier than Python alone. NumPy
performance is actually quite poor. I am finding I can write
Python +
Nu
On Wednesday, 25 September 2013 at 03:41:36 UTC, Jay Norwood
wrote:
I've been playing with the python pandas app enables
interactive manipulation of tables of data in their dataframe
structure, which they say is similar to the structures used in
R.
It appears pandas has laid claim to being a
Please ignore the missing "new" keywords in the code and other
minor typos :)
Hi, I've been wondering if anyone would give some advice on an
OOP-related question. Assume there's an external library (module
c_library) that handles IDs for groups and datasets and we want
to wrap it in a high-level D API. Groups can contain datasets
identified by names, and each dataset has
On Thursday, 25 December 2014 at 02:28:47 UTC, ketmar via
Digitalmars-d-learn wrote:
happy hacking! ;-)
Thanks once again! I think this mostly solves it. Would it be
possible to somehow do the same trick with this()? (I guess due
to having to write Type!() when default template arguments are
I'm wondering how to best implement the following pattern: the
constructor of a class has some required and some optional
arguments; and one of the (optional) arguments also controls if
any additional arguments should be passed.
A hypothetical/simplified example that I came up with: there's a
On Wednesday, 24 December 2014 at 14:11:37 UTC, Adam D. Ruppe
wrote:
auto check(alias func)(int x, string file = __FILE__, size_t
line = __LINE__) {
/* snip */
throw new Exception("%d < 0".format(result), file,
line); // L10
Thanks! I guess that's what my confusion was partially ab
On Wednesday, 24 December 2014 at 13:48:26 UTC, ketmar via
Digitalmars-d-learn wrote:
the `object.Exception@wrap.d` is not a backtrace result, this
is the
result of Exception class constructor:
this (string msg, string file=__FILE__, usize line=__LINE__,
Throwable next=null)
it registering
Imagine there's a template that wraps arbitrary functions and may
throw exceptions depending on their returned values (see a
simplified example below). However, if an exception occurs, the
backtrace is pointing inside the template which is not helpful at
all (especially when many such functions
On Monday, 22 December 2014 at 19:11:13 UTC, Ali Çehreli wrote:
On 12/22/2014 10:06 AM, aldanor wrote:
https://github.com/D-Programming-Language/dmd/pull/4200
Thank you! This fixes a big problem with the contracts in D.
Ali
It's not my PR but I just thought this thread would be hap
https://github.com/D-Programming-Language/dmd/pull/4200
On Monday, 22 December 2014 at 17:28:12 UTC, Iov Gherman wrote:
So, I did some more testing with the one processing in paralel:
--- dmd:
4 secs, 977 ms
--- dmd with flags: -O -release -inline -noboundscheck:
4 secs, 635 ms
--- ldc:
6 secs, 271 ms
--- gdc:
10 secs, 439 ms
I also pushed the ne
On Monday, 22 December 2014 at 10:40:45 UTC, Daniel Kozak wrote:
On Monday, 22 December 2014 at 10:35:52 UTC, Daniel Kozak via
Digitalmars-d-learn wrote:
I run Arch Linux on my PC. I compiled D programs using
dmd-2.066 and used no compile arguments (dmd prog.d)
You should try use some argume
On Monday, 22 December 2014 at 11:11:07 UTC, aldanor wrote:
Just tried it out myself (E5 Xeon / Linux):
D version: 19.64 sec (avg 3 runs)
import core.stdc.math;
void main() {
double s = 0;
foreach (i; 1 .. 1_000_000_000)
s += log(i);
}
// build
On Friday, 19 December 2014 at 10:57:47 UTC, aldanor wrote:
Something about the loop in the first case not depending on n
and the compiler being able to figure it is out and only drop
into recursion once?
That's just a wild guess, but does it get transformed into
something like this?
t
On Friday, 19 December 2014 at 10:41:04 UTC, bearophile wrote:
A case where the usage of ranges (UFCS chains) leads to very
bad performance:
import std.stdio: writeln;
import std.algorithm: map, join;
uint count1, count2;
const(int)[] foo1(in int[] data, in int i, in int max) {
count1++;
I've no idea why the forum decided to wrap all code; anyway:
https://gist.github.com/aldanor/ddc45b2710a2deb9ee2b
I'm trying (hard) to learn D templating, and (thanks to the great
help on this forum) I've been able to solve one of the recent
tasks I've been struggling about for a while. Wonder if anyone
would take a moment to criticize the code so we rookies could
learn?
Could this be done more elegantly
On Wednesday, 17 December 2014 at 12:49:10 UTC, anonymous wrote:
As far as I understand, the string mixin is resolved first, and
then the template mixin takes place. So the progression is
somewhat like this (pseudo code):
mixin makeProperty!(int, "foo", f);
/* Replace "makeProperty" with i
On Wednesday, 17 December 2014 at 02:12:52 UTC, anonymous wrote:
Sure, straight forward:
mixin template makeProperty(T, string name, alias func) {
mixin("T %s() @property { return func();
}".format(name));
}
Indeed... thanks! Just one thing that I find confusing here -- h
On Wednesday, 17 December 2014 at 01:39:07 UTC, anonymous wrote:
But if you want to avoid `p`, just do the substitution:
mixin template makeProperty(T, string name, alias func) {
mixin("enum %s = makeUnnamedProperty!(T,
func);".format(name)); // or alias
}
Thanks, that looks
A partial solution would be something like this:
mixin template makeProperty(T, string name, alias func) {
enum p = makeUnnamedProperty!(T, func);
mixin("enum %s = p;".format(name)); // or alias
}
however now the parent namespace is polluted with "p", is there
any way to
Would something like this be possible at all? A hypothetical
mixin template
mixin template makeProperty(T, string name, alias func) {
...
}
that could be called like this:
makeProperty!(int, "foo", f)
and would generate code like
int @property foo() { return f(); }
T
On Monday, 15 December 2014 at 23:21:05 UTC, anonymous wrote:
On Monday, 15 December 2014 at 23:14:30 UTC, aldanor wrote:
Could someone please explain why the following doesn't compile
with "const" qualifier while it does work without it?
/* test.d */
module test;
mix
Could someone please explain why the following doesn't compile
with "const" qualifier while it does work without it?
/* test.d */
module test;
mixin template Foo() {
mixin("@property int bar() const { return foo; }");
}
int foo = 1;
mixin Foo;
unittest {
assert(foo == bar);
}
rdmd
Personally i wouldn't go this route. I would create foo.d as a
C to D translation only so it can be imported and used like in
C. Then i would create another module which imports this to
create your new OOP API adding features and excepions, etc.
This allows the best of both worlds, keep the C
I'm writing bindings to a rather big C library where the return
values of almost all functions indicate the possibility of an
error (exception).
Assuming there's a C header, "foo.h" with functions "f1", "f2",
etc, I want to have a corresponding D module, "foo.d" which would
provide the "f1",
On Saturday, 21 December 2013 at 21:49:01 UTC, MrSmith wrote:
On Saturday, 21 December 2013 at 00:47:04 UTC, aldanor wrote:
Is there an efficient method to remove elements with multiple
(compile-time-unknown) indices from an array? I currently do
something like
if
On Saturday, 21 December 2013 at 02:52:00 UTC, bearophile wrote:
Do not forget to add the () after the sort, otherwise you call
the deprecated, buggy and slow built-in sort.
reverse is another deprecated built-in, so use "retro".
The first "if" is not much useful, trying to sort an empty
arra
On Saturday, 21 December 2013 at 03:22:22 UTC, H. S. Teoh wrote:
Unfortunately, while std.algorithm.remove does provide a way to
do this
if the number of indices to remove are known beforehand, it
doesn't seem
to be able to remove a dynamic list of indices. Probably an
enhancement
request shou
On Saturday, 21 December 2013 at 02:56:57 UTC, Dicebot wrote:
No. There is no such thing as "suitable compiler warning".
So should this considered a bug then and be filed? (if that will
do any good, lol)
On Saturday, 21 December 2013 at 01:00:48 UTC, bearophile wrote:
aldanor:
it would be nice if the compiler (at least) fired a warning
about this kind of things,
For reasons D doesn't like warnings, they are kept at a
minimum. D prefers errors :-)
Bye,
bearophile
So.. isn't
On Saturday, 21 December 2013 at 01:42:04 UTC, Ali Çehreli wrote:
That's probably a bug, right? The indexes would probably become
off as the array gets shorter.
Note the .reverse there? Which makes sure indices don't get off.
Still, that's probably an inefficient way of doing this...
Is there an efficient method to remove elements with multiple
(compile-time-unknown) indices from an array? I currently do
something like
if (!index.empty)
foreach (i; index.sort.reverse)
a = a.remove(i);
... which looks a
On Friday, 20 December 2013 at 23:17:31 UTC, bearophile wrote:
Right, currently the outcome of that kind of code is not
specified in D. So writing it is a error, and the D compiler
doesn't warn you. Do not write that kind of code in D.
Walter wants to eventually (but when? Five years from now
51 matches
Mail list logo