On 2/6/20 10:11 AM, Steven Schveighoffer wrote
b.step(); // virtual call, calls B.step
I meant, calls A.step;
-Steve
On 2/6/20 8:05 AM, Mihail Lorenko wrote:
On Thursday, 6 February 2020 at 12:37:01 UTC, Adam D. Ruppe wrote:
On Thursday, 6 February 2020 at 12:15:17 UTC, Mihail Lorenko wrote:
B* b;
A pointer to a class is a rare thing in B since they are already
automatic references. Just use `B b;` and
On Thursday, 6 February 2020 at 12:37:01 UTC, Adam D. Ruppe wrote:
On Thursday, 6 February 2020 at 12:15:17 UTC, Mihail Lorenko
wrote:
B* b;
A pointer to a class is a rare thing in B since they are
already automatic references. Just use `B b;` and ten `b = a`
will just work.
Thanks for
On Thursday, 6 February 2020 at 12:15:17 UTC, Mihail Lorenko
wrote:
B* b;
A pointer to a class is a rare thing in B since they are already
automatic references. Just use `B b;` and ten `b = a` will just
work.
On 12/4/17 3:43 PM, Dirk wrote:
Hi!
I defined an interface:
interface Medoid {
float distance( Medoid other );
uint id() const @property;
}
and a class implementing that interface:
class Item : Medoid {
float distance( Item i ) {...}
uint id() const @property {...}
}
The
On Monday, 4 December 2017 at 20:43:27 UTC, Dirk wrote:
Hi!
I defined an interface:
interface Medoid {
float distance( Medoid other );
uint id() const @property;
}
and a class implementing that interface:
class Item : Medoid {
float distance( Item i ) {...}
uint id() const @pr
On Tuesday, 5 December 2017 at 07:47:32 UTC, Dirk wrote:
The distance function is implementation dependend and can only
be computed between two objects of the same class (in this
example the class is Item).
Just don't put it in the interface. Leave it in the individual
classes with the strict
On Tuesday, 5 December 2017 at 08:08:55 UTC, Daniel Kozak wrote:
You can do something like this:
interface Medoid(T) {
float distance( T other );
uint id() const @property;
}
class Item : Medoid!(Item) {
float distance( Item m ) { return 0.;}
uint id() const @property { return 1
You can do something like this:
interface Medoid(T) {
float distance( T other );
uint id() const @property;
}
class Item : Medoid!(Item) {
float distance( Item m ) { return 0.;}
uint id() const @property { return 1; }
}
class MedoidClassification {
this(T:Medoid!T)(T[] list)
On Tuesday, 5 December 2017 at 07:47:32 UTC, Dirk wrote:
What would be a good way to implement this?
Did you tried to use introspection?
The distance function is implementation dependend and can only be
computed between two objects of the same class (in this example
the class is Item).
My goal is to write a module for a k-medoids clustering
algorithm. The class MedoidClassification shall be able to
partition a list of objects
On Monday, 4 December 2017 at 20:43:27 UTC, Dirk wrote:
Hi!
float distance( Medoid other );
float distance( Item i ) {...}
The two signatures need to be the same. I think this is true of
most OOP languages. Have them both be:
float distance( Medoid other );
On 2017-12-04 21:43, Dirk wrote:
Hi!
I defined an interface:
interface Medoid {
float distance( Medoid other );
uint id() const @property;
}
and a class implementing that interface:
class Item : Medoid {
float distance( Item i ) {...}
uint id() const @property {...}
}
The
On Monday, 4 December 2017 at 20:43:27 UTC, Dirk wrote:
Hi!
I defined an interface:
interface Medoid {
float distance( Medoid other );
uint id() const @property;
}
and a class implementing that interface:
class Item : Medoid {
float distance( Item i ) {...}
uint id() const @pr
On Monday, 4 December 2017 at 20:43:27 UTC, Dirk wrote:
interface Medoid {
float distance( Medoid other );
uint id() const @property;
}
and a class implementing that interface:
class Item : Medoid {
float distance( Item i ) {...}
uint id() const @property {...}
}
The compiler s
On Thursday, 5 March 2015 at 19:51:09 UTC, Max Klyga wrote:
If you really need the actual pointer to object data you can
use `*cast(void**)&myObject`. Compiler cannot cast object
reference to `void*` but we can trick it ;)
It can, actually. A class can define its own cast(void*) though,
so th
On Thursday, 5 March 2015 at 20:08:08 UTC, Chris Sperandio wrote:
Is it clean to write this code below ?
yup. Though remember all the downsides of null - if you try to
use a null object like accessing a member, the program will be
terminated.
Ok... So, in D when I work with Object, it's like if I work with
only pointers.
Thus, I can return null from a function which returns an Item
instance.
Is it clean to write this code below ?
static Item nullReturn(Item item)
{
// ...
// and for some cases
return null;
}
On Thursday, March 05, 2015 19:35:34 Chris Sperandio via Digitalmars-d-learn
wrote:
> Hi,
>
> I'm a developer coming from C and I've a question about class
> instance as method or function parameter.
> In the book "The D Programming Language", I read the instance was
> passed by reference to funct
Below the code:
module item;
import std.stdio;
class Item
{
ulong count;
static void call1(Item item)
{
writeln("(call1) Addr: ", &item);
}
static void call2(ref Item item)
{
writeln("(call2) Addr: ", &item);
}
static Item call3(Item item)
{
writeln("(call3) Add
On 2015-03-05 19:35:34 +, Chris Sperandio said:
Hi,
I'm a developer coming from C and I've a question about class instance
as method or function parameter.
In the book "The D Programming Language", I read the instance was
passed by reference to functions (in the opposite of structures). I
On Thursday, 5 March 2015 at 19:35:35 UTC, Chris Sperandio wrote:
Hi,
I'm a developer coming from C and I've a question about class
instance as method or function parameter.
In the book "The D Programming Language", I read the instance
was passed by reference to functions (in the opposite of
On 09/10/14 22:06, Dicebot wrote:
I think this is an issue with the import resolution, not module system.
The way it is implemented right now DMD stops searching for object.d /
object.di once it has found one. So while your module name is not
interpreted as "object" _original_ object.di does not
I think this is an issue with the import resolution, not module
system. The way it is implemented right now DMD stops searching
for object.d / object.di once it has found one. So while your
module name is not interpreted as "object" _original_ object.di
does not get imported and you get lot of
Michael,
thank you for these links.
Regards, Florian.
Additional discussions
http://forum.dlang.org/thread/jpl93e$1mns$1...@digitalmars.com
and
http://forum.dlang.org/thread/l3dj7b$2tvc$1...@digitalmars.com
Jonathan,
Dicebot,
thank you very much for your response. So you are confirming my
conclusion, that finalizers/destructors in D work pretty much
like in C++ and there is no way to do Java/C#/Managed C++-like
finalization.
For the records, since Dicebot asked: I am using DMD32 v2.063.2
on De
On Tuesday, 12 November 2013 at 22:40:26 UTC, Florian wrote:
The example below prints the following output:
~Connection
~Session
segmentation fault
Same example prints this for me (no segfault):
~Session
shutdown
~Connection
2.064.2 @ linux-64
What is your system / compiler? Outp
On Tuesday, 12 November 2013 at 23:18:11 UTC, Jonathan M Davis
wrote:
You can't do that in
finalizer, because the GC can choose to free it before the
finalizer even runs
(this avoids issues with circular references).
Ah, damn, have forgotten about it. Disregard previous post.
On Wednesday, November 13, 2013 00:07:12 Florian wrote:
> I understood very well, that the garbage collector is not
> guaranteed to run. However, it does not explain the segmentation
> fault in my example, does it?
You're getting a segfault, because you're using something which is on the GC
heap
I understood very well, that the garbage collector is not
guaranteed to run. However, it does not explain the segmentation
fault in my example, does it?
On Tuesday, November 12, 2013 23:40:24 Florian wrote:
> it would be possible to move the shutdown() sequence into the
> destructor of the "Connection" class.
Classes in D do not have destructors. Only structs to. ~this is a destructor
in a struct, but it's a finalizer in a class. Finalizers are n
On Tuesday, 12 November 2013 at 20:29:13 UTC, Dicebot wrote:
On Tuesday, 12 November 2013 at 20:15:02 UTC, Florian wrote:
I played around a little and figured out, that destructors in
D work quite similarily to destructors in C++. They are
invoked, after the members of the instance being destru
On Tuesday, 12 November 2013 at 20:15:02 UTC, Florian wrote:
I played around a little and figured out, that destructors in D
work quite similarily to destructors in C++. They are invoked,
after the members of the instance being destructed have been
destroyed themselfes (or at least have been br
10.11.2013 23:22, Benjamin Thaut пишет:
Am 10.11.2013 17:06, schrieb Alexandr Druzhinin:
Because in D Classes are reference types. That means the code you wrote
is equivalent to the following C++ source:
class Foo
{
public:
Foo(Object* o)
{
printf("%x\n", &this); // print a Foo**
Am 10.11.2013 17:06, schrieb Alexandr Druzhinin:
Could somebody explain why this http://dpaste.dzfl.pl/248262b9 return this:
Foo:
7FBFD59A50
7FBFD59A80
Bar:
7FBFD59A58
7FBFD59A88
Why this value in ctor is different from this value out of ctor if ctor
gets an argument?
Because in D Classes are r
On Sunday, 10 November 2013 at 16:06:40 UTC, Alexandr Druzhinin
wrote:
Could somebody explain why this http://dpaste.dzfl.pl/248262b9
return this:
Foo:
7FBFD59A50
7FBFD59A80
Bar:
7FBFD59A58
7FBFD59A88
Why this value in ctor is different from this value out of ctor
if ctor gets an argument?
Th
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.
T
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?
On Monday, July 16, 2012 10:31:11 Namespace wrote:
> I'm just experiement with D, that's all. ;)
> Most of my questions here are just out of curiosity.
>
> I have now this construct:
>
> [code]
> class smart_ptr {
> private:
> A* _ptr;
>
> public:
> this(A* ptr) {
> voi
I'm just experiement with D, that's all. ;)
Most of my questions here are just out of curiosity.
I have now this construct:
[code]
class smart_ptr {
private:
A* _ptr;
public:
this(A* ptr) {
void* buffer = GC.malloc(A.sizeof);
memcpy(buffer, ptr, A
On Monday, July 16, 2012 09:33:42 Namespace wrote:
> Yes. I want a Pointer of Foo's reference, you're right. I think i
> have to move the reference to the heap?
If you don't want it to point to a local variable and cause problems when it
goes out of scope, then yeah, though I don't know if it's p
You cannot have pointers to classes. The language does not
support it. You can
have pointers to class references, and you can have pointers to
structs or the
built-in types, but if Foo is a class, then what you can't have
a pointer to
it. The closest that you can get is that I believe that you c
On Monday, July 16, 2012 00:47:27 Namespace wrote:
> Is something like this possible?
>
> Foo* create_ptr(Foo f) {
> assert(f !is null);
> // ...
> }
>
> Foo* fp = create_ptr(new Foo());
>
> with "ref Foo f" of course, there is no limitation.
You cannot have pointers to classes. The l
Seems to me that you achieved the your first purpose. Do you
need more help?
Kenji Hara
I think i'm finished. Or have you any tip for me, related to the
code?
On Thursday, 21 June 2012 at 21:32:57 UTC, Namespace wrote:
Works in dmd 2.059 too.
Oh, good.
[code]
T template_cast(T : Object, U : Object)(U value) {
// try to convert
T val = cast(T) value;
// if convert was successful, return
if (val !is null) {
Works in dmd 2.059 too.
[code]
T template_cast(T : Object, U : Object)(U value) {
// try to convert
T val = cast(T) value;
// if convert was successful, return
if (val !is null) {
return val;
}
// if cast fails it
On Thursday, 21 June 2012 at 10:33:41 UTC, Namespace wrote:
To solve the problem of converting a Object to a specific
template class i wrote this little function.
But the mixin disturbs me. How i can get the type (in this
example Vector2D) without to mix a mixin and T.stringof?
[code]
T object
dcoder wrote:
> Hello.
>
> I'm probably not looking hard enough, but Do we have any
> standard d-library for serializing an object/object tree into
> -for example- an xml file?
>
> thanks.
You have following
- Orange
- Thrift implementation
- BSON (http://vibed.org)
Probably wrappers or bi
Al 24/04/12 18:45, En/na David Nadlinger ha escrit:
> On Tuesday, 24 April 2012 at 16:42:19 UTC, dcoder wrote:
>> I'm probably not looking hard enough, but Do we have any standard
>> d-library for serializing an object/object tree into -for example- an xml
>> file?
>
> There is no standard l
On 2012-04-24 23:30, sclytrack wrote:
Does it automatically pick everything to serialize?
Yes.
How would you make it more selective?
It depends on what you want to do.
struct Me
{
int x;
int y;
}
serialize x but not y.
In this simple case you can do like this:
struct Me
{
int x;
On 04/24/2012 08:50 PM, Jacob Carlborg wrote:
On 2012-04-24 18:42, dcoder wrote:
Hello.
I'm probably not looking hard enough, but Do we have any standard
d-library for serializing an object/object tree into -for example- an
xml file?
thanks.
You can have a look at Orange:
https://github
On 2012-04-24 18:42, dcoder wrote:
Hello.
I'm probably not looking hard enough, but Do we have any standard
d-library for serializing an object/object tree into -for example- an
xml file?
thanks.
You can have a look at Orange:
https://github.com/jacob-carlborg/orange
Tutorials:
http://
On Tuesday, 24 April 2012 at 16:42:19 UTC, dcoder wrote:
I'm probably not looking hard enough, but Do we have any
standard d-library for serializing an object/object tree into
-for example- an xml file?
There is no standard library support yet, but you might want to
look at Orange (full f
I see mm
Thanks for the info!
"Jonathan M Davis" wrote in message
news:mailman.866.1307943671.14074.digitalmars-d-le...@puremagic.com...
Object is not currently const-correct:
http://d.puremagic.com/issues/show_bug.cgi?id=1824
As a result, a number of basic functions do not currently
On 2011-06-12 22:37, Jonathan M Davis wrote:
> On 2011-06-12 22:25, Lloyd Dupont wrote:
> > I have problem with "Object"
> >
> > for example this doesn't compile:
> > ===
> > Object o;
> > o = "";
> > ===
> > with error: cannot implicitly convert expression ("") of type string to
> > object.Object
On 2011-06-12 22:25, Lloyd Dupont wrote:
> I have problem with "Object"
>
> for example this doesn't compile:
> ===
> Object o;
> o = "";
> ===
> with error: cannot implicitly convert expression ("") of type string to
> object.Object
Object is the base class of all classes. Nothing which is not a
On Thu, 07 Oct 2010 07:50:49 -0400, Vasileios Anagnostopoulos
wrote:
What is the purpose of object.di? where can I learn more?
http://www.digitalmars.com/d/2.0/dmd-linux.html#interface_files
I believe the purpose for object.di is to hide the runtime implementation
from the importer.
== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
> strtr wrote:
> >
> > void externalFunc(){}
> >
> > class C
> > {
> > ..
> > int index_;
> > int yay;
> > void removeMe()
> > {
> > //remove last reference to this object
> > objects[_index] = null;
> >
> > //ot
strtr wrote:
void externalFunc(){}
class C
{
..
int index_;
int yay;
void removeMe()
{
//remove last reference to this object
objects[_index] = null;
//other critical code
memberFunc();
externalFunc();
}
void memberFunc(){yay++}
}
Is there anything unsafe a
Hi,
Shouldn't be as 'this' will keep the object alive as long as necessary.
Mark
On Sat, Jan 10, 2009 at 6:39 AM, downs wrote:
> Jarrett Billingsley wrote:
>> On Sat, Jan 10, 2009 at 12:30 AM, Jarrett Billingsley
>> wrote:
>>> On Sat, Jan 10, 2009 at 12:18 AM, yes wrote:
Does Phobos also do threadpools?
>>> From what I understand, not without modification. At least, no
Jarrett Billingsley wrote:
> On Sat, Jan 10, 2009 at 12:30 AM, Jarrett Billingsley
> wrote:
>> On Sat, Jan 10, 2009 at 12:18 AM, yes wrote:
>>> Does Phobos also do threadpools?
>> From what I understand, not without modification. At least, not
>> efficiently. Downs has implemented such a thing
On Sat, Jan 10, 2009 at 12:18 AM, yes wrote:
> Does Phobos also do threadpools?
>From what I understand, not without modification. At least, not
efficiently. Downs has implemented such a thing in scrapple.tools,
but it requires a patch to Phobos to make it run at a reasonable
speed.
> Somehow
On Sat, Jan 10, 2009 at 12:30 AM, Jarrett Billingsley
wrote:
> On Sat, Jan 10, 2009 at 12:18 AM, yes wrote:
>> Does Phobos also do threadpools?
>
> From what I understand, not without modification. At least, not
> efficiently. Downs has implemented such a thing in scrapple.tools,
> but it requi
Does Phobos also do threadpools?
Somehow I liked the idea of an Object like agent smith, just duplicate yourself
when the task is too big. ( ^_^ )
>
>
> Hm... I guess I understand now, you need a task parallelization, right?
>
> In order to do this, you usually separate the task into several
On Sat, 10 Jan 2009 07:32:43 +0300, yes wrote:
What does this code do? It looks like a ThreadPool use case but I might
be wrong.
I tried to recursively make an object distribute its calculations.
The calculations should take at least a minute.
Hm... I guess I understand now, you need
>
> What does this code do? It looks like a ThreadPool use case but I might be
> wrong.
>
I tried to recursively make an object distribute its calculations.
The calculations should take at least a minute.
On Sat, 10 Jan 2009 05:44:20 +0300, yes wrote:
How bad is the following idea?
class Calc
{
void addThread()
{
Data data;
data = new Data();
}
void run()
{
if ( hardware threads > current threadcount)
{
addThread();
}
//wait for some signal
//run calculations on data / threads
}
}
Cal
69 matches
Mail list logo
