Hello everybody,
we had a conversation with Ali Cehreli about the right ways of
hashing values / objects. This is related to the D language when
using associative arrays but applies for any language as well.
One of the points was, we have the following class:
==
class Student // class repres
The DLL page on the main D site is out of date in its example,
importing module std.gc, which doesn't exist. Has connecting to
DLLs become easier, harder, or just plain different? And in what
ways should I go about doing so? My personal requirement is
dynamic loading, so any help would be much
On Tuesday, November 06, 2012 22:52:53 Dan wrote:
> Later on another response is: "A huge difference between *in* and
> *const ref* which you don't cover at all is the fact that *const
> ref* must take an lvalue, whereas *in* doesn't have to"
>
> Why is this benefit huge? Is it just the convenienc
On Tuesday, 6 November 2012 at 18:34:04 UTC, Ali Çehreli wrote:
Because in the case of cs, T is 'const(S)', matching the
following two instantiations:
1) ref const(S) i
2) const ref const(S) i
The second line has a redundant const. So, they end up having
the same signature.
Ali
Oh - that
Googling to see differences between *in* and *const ref* I found
detailed explanation here:
http://stackoverflow.com/questions/8515579/difference-between-const-ref-and-in
One response is: "If you have identified the copying as a
bottleneck and you want to optimize, using *const ref* is a good
On 6.11.2012 21:59, Ali Çehreli wrote:
On 11/06/2012 12:00 PM, luka8088 wrote:
> Yes, but it seems that we can in general say that the following code
> will never fail... or am I wrong ?
>
> import core.memory;
>
> class a {
> static int totalRefCount = 0;
> this () { totalRefCount++; }
On Nov 6, 2012, at 12:59 PM, Ali Çehreli wrote:
>
> I can't come up with an example but the spec is clear on that issue:
>
> http://dlang.org/class.html#destructors
>
> "The garbage collector is not guaranteed to run the destructor for all
> unreferenced objects. Furthermore, the order in whi
On 6.11.2012 18:02, thedeemon wrote:
On Tuesday, 6 November 2012 at 11:27:25 UTC, luka8088 wrote:
Hello everyone,
I was writing some unit tests and I also wanted to test that in
certain cases object references are properly removed everywhere so
that GC can collect them in order to make sure the
On 6.11.2012 18:00, Ali Çehreli wrote:
On 11/06/2012 03:27 AM, luka8088 wrote:
> I was writing some unit tests and I also wanted to test that in certain
> cases object references are properly removed everywhere so that GC can
> collect them in order to make sure there is no memory leak. While
On Tuesday, 6 November 2012 at 18:28:04 UTC, Ali Çehreli wrote:
On 11/06/2012 10:13 AM, PlatisYialos wrote:
> On Tuesday, 6 November 2012 at 17:48:55 UTC, PlatisYialos
wrote:
>
> To really give a stark example:
>
> ---
> void compiles() {
> immutable(char)[][immutable(
On Tuesday, 6 November 2012 at 18:25:46 UTC, Ali Çehreli wrote:
On 11/06/2012 09:48 AM, PlatisYialos wrote:
On Tuesday, 6 November 2012 at 17:23:41 UTC, PlatisYialos
wrote:
Errmm! Here's a better example, but with the same results:
module test;
void noparens() {
On 11/06/2012 09:18 AM, Dan wrote:
Why does g(cs) compile but not G(cs)?
Thanks,
Dan
struct S{}
void g(ref S i) {}
void g(const ref S i) {}
void G(T)(ref T i) {}
void G(T)(const ref T i) {}
void main() {
S s;
const(S) cs;
g(s);
g(cs);
G(s);
// Error: template p.G matches more than one templat
On 11/6/12, Simen Kjaeraas wrote:
> In addition to Dan's answer, let me present a general solution:
>
> template InstantiationInfo( T ) {
> static if ( is( T t == U!V, alias U, V... ) ) {
> alias U Template;
> alias V Parameters;
> } else {
> static assert(fals
On 11/05/2012 06:14 PM, Simen Kjaeraas wrote:
std.typecons.Tuple does a bit of magic behind the scenes. This includes
ridding itself of non-type parameters.
Simply put, you can imagine inserting the type tuple directly into the
function definition:
void add(ID id, size_t arg0, real arg1, "
On 11/06/2012 09:48 AM, PlatisYialos wrote:
On Tuesday, 6 November 2012 at 17:23:41 UTC, PlatisYialos wrote:
Errmm! Here's a better example, but with the same results:
module test;
void noparens() {
immutable char[char] aMap;
char a = 'a';
immutable char b = 'b';
a
On 11/06/2012 10:13 AM, PlatisYialos wrote:
> On Tuesday, 6 November 2012 at 17:48:55 UTC, PlatisYialos wrote:
>
> To really give a stark example:
>
> ---
> void compiles() {
> immutable(char)[][immutable(char)[]] aMap;
[...]
> Does the compiler give special treatment
On Tuesday, 6 November 2012 at 17:48:55 UTC, PlatisYialos wrote:
To really give a stark example:
---
void compiles() {
immutable(char)[][immutable(char)[]] aMap;
immutable(char)[] a = ['a'];
immutable(char)[] b = ['b'];
aMap[a] = b;
}
void doesnotcompile() {
On Tuesday, 6 November 2012 at 17:23:41 UTC, PlatisYialos wrote:
Errmm! Here's a better example, but with the same results:
module test;
void noparens() {
immutable char[char] aMap;
char a = 'a';
immutable char b = 'b';
aMap[a] = b;
}
void withparens() {
Here's a test file, with the compiler messages obtained. I also
tried introducing an alias with similar results to the second
attempt below.
1module test;
2
3void noparens() {
4 immutable char[char] aMap;
5 aMap['a'] = 'b';
6
7 /* Compiler error messages
8 ./src/
Why does g(cs) compile but not G(cs)?
Thanks,
Dan
struct S{}
void g(ref S i) {}
void g(const ref S i) {}
void G(T)(ref T i) {}
void G(T)(const ref T i) {}
void main() {
S s;
const(S) cs;
g(s);
g(cs);
G(s);
// Error: template p.G matches more than one template
declaration, /p.d(5):
On Tuesday, 6 November 2012 at 11:27:25 UTC, luka8088 wrote:
Hello everyone,
I was writing some unit tests and I also wanted to test that in
certain cases object references are properly removed everywhere
so that GC can collect them in order to make sure there is no
memory leak. While trying
On 11/06/2012 03:27 AM, luka8088 wrote:
> I was writing some unit tests and I also wanted to test that in certain
> cases object references are properly removed everywhere so that GC can
> collect them in order to make sure there is no memory leak. While trying
> to achieve this I learned that ob
On Tue, Nov 06, 2012 at 04:20:34PM +0100, Joseph Rushton Wakeling wrote:
> Suppose that I have two struct templates which take identical
> parameter lists:
>
> struct Foo(T1, T2, T3)
> {
> ...
> }
>
> struct Bar(T1, T2, T3)
> {
> ...
> }
>
> Now suppose th
On 2012-11-06, 16:20, Joseph Rushton Wakeling wrote:
Suppose that I have two struct templates which take identical parameter
lists:
struct Foo(T1, T2, T3)
{
...
}
struct Bar(T1, T2, T3)
{
...
}
Now suppose that I have a Foo which has been inst
On 11/06/2012 04:34 PM, Dan wrote:
Would something like this be what you are after?
Yes! I actually had tested something similar, but as I was using the variable
name when trying to extract the parameter, it didn't work.
Thanks very much!
On 11/06/2012 04:25 PM, Joseph Rushton Wakeling wrote:
Look at the is() expression in the language spec.
I didn't get it to work with a template constraint, because the pattern
matched parameter are out of scope in the function body.
struct A(T1, T2)
{
}
struct B(B1, B2) {}
void foo(T)
On Tuesday, 6 November 2012 at 15:20:43 UTC, Joseph Rushton
Wakeling wrote:
Of course the f.T1 notation is my fiction, but it gives the
idea of what is needed -- is there a means to extract and use
template parameters in this way? I assume something from
std.traits but it's not entirely clear
On 11/06/2012 04:20 PM, Joseph Rushton Wakeling wrote:
The use-case I'm thinking of is a function something like this (somewhat
pseudo-code-y):
auto fooToBar(FooInstance f)
{
Bar!(f.T1, f.T2, f.T3) b;
// set values etc.
return b;
}
Of course the f.T1 no
Suppose that I have two struct templates which take identical parameter lists:
struct Foo(T1, T2, T3)
{
...
}
struct Bar(T1, T2, T3)
{
...
}
Now suppose that I have a Foo which has been instantiated with a given set of
parameters. Is there any way for m
Hello everyone,
I was writing some unit tests and I also wanted to test that in certain
cases object references are properly removed everywhere so that GC can
collect them in order to make sure there is no memory leak. While trying
to achieve this I learned that objects are not always collecte
30 matches
Mail list logo
