On 2012-07-18 06:51, Konstantin J. Chernov wrote:
Hello. When I'm trying to create a class object by using a dlsym-ed
function, I'm getting a segmentation fault after execution of program.
However, if I'm deleting that object before 'return 0' in main (by using
'delete b'), everything is going
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud philippe.sig...@gmail.com:
On Sunday, July 15, 2012 05:30:55 Jay Norwood wrote:
I see from this other discussions that it looks like 2.059 ( or
maybe 2.060) does support something like 3.cm(). Not sure from
the discussion if
What am I doing wrong here? Is there any way to do what I'm
trying to do
right way?
Dynamic libraries aren't properly supported by the runtime.
That's terrible:(
It's so nice to make an interface, and create classes that
inherit this interface dynamically, without linking...
Maybe
Run this code:
class PP {}
void what(T)(T val)
{
static if (is(T == int)) writeln (T == int);
static if (is(T == const(int))) writeln (T == const(int));
static if (is(T : int)) writeln (T : int);
static if (is(T == PP)) writeln (T == PP);
static if (is(T
Andrea Fontana:
const(int) : int -- true
const(PP) : PP -- false
Is this behaviour correct?
I think it's correct, and it's caused by the difference between
value types and reference types.
And how can I check if T is of a certain class ignoring consts
(and avoiding double checks)?
Konstantin J. Chernov:
testclass.di:
class testclass
{
this(const wstring loadmsg);
~this();
wstring foo();
};
And usually you don't need to write .di files in D.
Bye,
bearophile
On 2012-07-18 10:17, Konstantin J. Chernov wrote:
What am I doing wrong here? Is there any way to do what I'm trying to do
right way?
Dynamic libraries aren't properly supported by the runtime.
That's terrible:(
It's so nice to make an interface, and create classes that inherit this
It seems to works (but i use Unqual!T directly)
Thank you :)
Il giorno mer, 18/07/2012 alle 11.13 +0200, bearophile ha scritto:
Andrea Fontana:
const(int) : int -- true
const(PP) : PP -- false
Is this behaviour correct?
I think it's correct, and it's caused by the difference
On Wednesday, July 18, 2012 10:43:23 Andrea Fontana wrote:
So:
const(int) : int -- true
const int is implicitly convertible to int, because it's a value type, and
assigning a const int to an int (or vice versa) makes a copy.
const(PP) : PP -- false
const PP is not implicitly convertible
On 18-07-2012 06:51, Konstantin J. Chernov wrote:
Hello. When I'm trying to create a class object by using a dlsym-ed
function, I'm getting a segmentation fault after execution of program.
However, if I'm deleting that object before 'return 0' in main (by using
'delete b'), everything is going
Thank you for your replies!
I've found a working solution - all I needed is to change wstring
to const wstring, and pass it not as func(something), but as
wstring tmp = something; func(tmp);
That's really odd, because I don't understand, how those changes
made segfault disappear.
Here's
On Monday, 16 July 2012 at 23:18:10 UTC, Adam D. Ruppe wrote:
I'm another who is /vehemently/ against the utter
idiocy that is the -property switch.
Arguments! Yay!
On Wednesday, 18 July 2012 at 07:30:10 UTC, Marco Leise wrote:
Am Sun, 15 Jul 2012 19:17:11 +0200
schrieb Philippe Sigaud philippe.sig...@gmail.com:
[…]
auto distance = 100.km;
auto speed = 120.km/hour;
auto timeToDestination = distance/speed; // timeToDest is a
time (seconds)
The version
On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote:
On 07/11/2012 04:25 AM, ixid wrote:
in some way it sees global immutables almost as enums
This seems like a bad idea. Consistency of behaviour would
seem to be a
good principle to expect of a language.
You are right; this is a
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
Arguments! Yay!
I've gone over this a dozen times on the group and on
bugzilla, and I'm kinda sick of repeating it.
-property breaks craploads of code. That's a huge negative,
and nobody has even come close to countering that.
On Wednesday, 18 July 2012 at 12:30:46 UTC, Adam D. Ruppe wrote:
2) -property doesn't even get that right anyway. Not kidding,
try it. -property might as well be renamed -break-my-code-and-
give-me-ABSOLUTELY-NOTHING-in-return.
Why, why would we ever consent to having that standard?
I
On Wednesday, 18 July 2012 at 12:15:52 UTC, Lemonfiend wrote:
On Wednesday, 11 July 2012 at 02:30:47 UTC, Timon Gehr wrote:
On 07/11/2012 04:25 AM, ixid wrote:
in some way it sees global immutables almost as enums
This seems like a bad idea. Consistency of behaviour would
seem to be a
good
18.07.2012 8:00, Mike Parker пишет:
Destructors are unreliable. There is no guarantee that a destructor will
be called before the garbage collector is terminated. When the program
exits, the runtime will call gc_term which will then call destructors on
any objects that haven't yet been cleaned
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
I just know how to do this:
string s
That being said, I have never used CRTP in D so far, since template
mixins seem to be the better choice in almost all situations.
FWIW, CRTP is the main reason I used classes in Pegged, to allow grammar
rules to refer to themselves. My earlier attempts with structs did not work.
So, given a
Yes I did it using Variant and it works fine
Il giorno mer, 18/07/2012 alle 16.42 +0200, Philippe Sigaud ha scritto:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
First:
Why is opDot not listed here:
http://dlang.org/operatoroverloading.html ?
How much other operators exists which are not listed there?
And:
Is opDot the same as alias this? I think so.
This code
[code]
class Foo {
public:
void echo() const {
writeln(Foo);
Also, UFCS makes no sense on overloaded operators, because they
don't get
called with ., and all UFCS is is changing obj.func(params)
to func(obj,
params).
- Jonathan M Davis
Ok, that's basically what I was wondering. I had assumed
foreach(e; someThing) {} could possibly have been converted
On Tue, 17 Jul 2012 15:23:05 +0100, bearophile bearophileh...@lycos.com
wrote:
Andrea Fontana:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose
On Wed, 18 Jul 2012 16:58:34 +0200, Namespace rswhi...@googlemail.com
wrote:
First:
Why is opDot not listed here: http://dlang.org/operatoroverloading.html ?
How much other operators exists which are not listed there?
I believe it's being deprecated. As far as I know, no other operators are
Probably you mean the same problem that is described in the thread
avobe, see using GC needs particular skills?
Every time after execution my code I got very frustating access
violation and the problem was misunderstanding garbage collector because
I've never used it before.
On 07/18/2012 08:21 AM, Mike L. wrote:
Also, UFCS makes no sense on overloaded operators, because they
don't get
called with ., and all UFCS is is changing obj.func(params) to
func(obj,
params).
- Jonathan M Davis
Ok, that's basically what I was wondering. I had assumed foreach(e;
On Wednesday, July 18, 2012 16:58:34 Namespace wrote:
First:
Why is opDot not listed here:
http://dlang.org/operatoroverloading.html ?
How much other operators exists which are not listed there?
And:
Is opDot the same as alias this? I think so.
opDot is going to be deprecated and really
Only for correctness:
If i allocate memory on the GC Heap in e.g. a struct and don't
free the memory in the DTor, then the GC free the memory
automatically?
Understand.
Many thanks to you both.
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact
that
conditional compilation relies on state that doesn't exist yet.
It's messed up
to be checking whether an object defines something when you're
in the middle of
On 07/18/2012 11:08 PM, monarch_dodra wrote:
On Tuesday, 17 July 2012 at 23:38:04 UTC, Jonathan M Davis wrote:
It's not that it makes the compiler's life hard. It's the fact that
conditional compilation relies on state that doesn't exist yet. It's
messed up
to be checking whether an object
On 07/18/2012 01:37 AM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 23:11:43 Timon Gehr wrote:
This issue is unrelated to CRTP. (also, you probably want to negate
that static if condition, otherwise the code is valid and poses no
challenge to a compiler.)
It's not that it makes the
Timon Gehr:
You are right; this is a bug.
This discussion is not about an obscure language detail, it's a
common situation. So if you think this is a bug, then please
Timon file it in Bugzilla.
Bye,
bearophile
On Wednesday, July 18, 2012 20:37:50 Namespace wrote:
Only for correctness:
If i allocate memory on the GC Heap in e.g. a struct and don't
free the memory in the DTor, then the GC free the memory
automatically?
You don't normally _ever_ free memory from the GC heap. That's the GC's job.
On 07/19/2012 12:42 AM, bearophile wrote:
Timon Gehr:
You are right; this is a bug.
This discussion is not about an obscure language detail, it's a common
situation.
FWIW, I have never run across it before.
So if you think this is a bug, then please Timon file it in
Bugzilla.
Usually
On 7/18/2012 5:30 AM, Adam D. Ruppe wrote:
On Wednesday, 18 July 2012 at 11:37:43 UTC, David Nadlinger wrote:
Arguments! Yay!
I've gone over this a dozen times on the group and on
bugzilla, and I'm kinda sick of repeating it.
-property breaks craploads of code. That's a huge negative,
On Thursday, 19 July 2012 at 02:57:05 UTC, Brad Roberts wrote:
The clear argument for me is that it must be trivial to take an
existing member variable and change it to a property
function pair _and vice versa_.
I can see some value in that.
The other bits about non-@property
functions is
Hi all,
it's been a while since this question, and I don't know how to solve
it either. The following code passes all the test using the last
version of dmd (2.059).
import std.container, std.algorithm;
//non const case
void assertequal(T)(SList!(T) l, int[] r) {
assert(equal(l[], r));
}
On Thursday, July 19, 2012 04:39:26 Francisco Soulignac wrote:
So, my question is how can I (correctly) traverse a const SList,
const DList, etc?
Right now? I'm pretty sure that that's impossible. Hopefully that will change,
but getting const and ranges to work together can be rather
40 matches
Mail list logo
