www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - oop tutorials

reply "Saaa" <empty needmail.com> writes:
I want to make a few (5-10?) D OOP tutorials for dsource.
That way I can learn about oop myself and help D, I hope :)

They should thus focus on people who never programmed in an oop style.

Every tutorial should elaborate on the previous one, but on themselves also 
compile into something interesting||useful.
The filler code (not related to oop but necessary to make it a interesting 
program) should not be too complex.

Anybody any idea which kind of program suits best?
The filler code in a ray tracer might just be a bit too complex.
Mar 03 2008
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Mon, 03 Mar 2008 17:22:02 +0100, Saaa wrote:

 I want to make a few (5-10?) D OOP tutorials for dsource. That way I can
 learn about oop myself and help D, I hope :)
 
 They should thus focus on people who never programmed in an oop style.
 
 Every tutorial should elaborate on the previous one, but on themselves
 also compile into something interesting||useful. The filler code (not
 related to oop but necessary to make it a interesting program) should
 not be too complex.
 
 Anybody any idea which kind of program suits best? The filler code in a
 ray tracer might just be a bit too complex.

I don't have any suggestions for interesting programs, but some ideas of how you may want to cover it. One thing you may want to do is not only build off past examples, but to show improvements with newly introduced tools. ** Start by writing a class. **** Static data of a class ** Then extend the class for more use. **** Keywords private, protected, public should be discussed in their relationship to modules. ** Introduce interfaces, maybe turn the first class into an interface ** Concentrate on function overriding and down/up casting. ** Inner classes ** Operator overloading I don't see templates as part of classes but still might be a good thing to cover.
Mar 03 2008
next sibling parent "Saaa" <empty needmail.com> writes:
Thank you for your suggestions.
 Looking at the list tells me that I need a lot of help (I barely know what 
half of them mean :)

What are the 2/4 asterisks for? Is that how you suggest I should build of 
previous tutorials?
I think the list you gave would work just nice in a build-from-previous 
setup or maybe I just don't understand it enough.

I'll write a class today (after reading about them on digitalmars)

For now I will only use D1 and phobos but its all open for additions 
ofcourse.

**signal & slots

 I don't have any suggestions for interesting programs, but some ideas of
 how you may want to cover it. One thing you may want to do is not only
 build off past examples, but to show improvements with newly introduced
 tools.

 ** Start by writing a class.
 **** Static data of a class
 ** Then extend the class for more use.
 **** Keywords private, protected, public should be discussed in their
 relationship to modules.
 ** Introduce interfaces, maybe turn the first class into an interface
 ** Concentrate on function overriding and down/up casting.
 ** Inner classes
 ** Operator overloading

 I don't see templates as part of classes but still might be a good thing
 to cover. 

Mar 03 2008
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 04 Mar 2008 06:03:48 +0100, Saaa wrote:

 Thank you for your suggestions.
  Looking at the list tells me that I need a lot of help (I barely know
  what
 half of them mean :)
 
 What are the 2/4 asterisks for? Is that how you suggest I should build
 of previous tutorials?
 I think the list you gave would work just nice in a build-from-previous
 setup or maybe I just don't understand it enough.
 
 I'll write a class today (after reading about them on digitalmars)
 
 For now I will only use D1 and phobos but its all open for additions
 ofcourse.
 
 **signal & slots
 
 
 I don't have any suggestions for interesting programs, but some ideas
 of how you may want to cover it. One thing you may want to do is not
 only build off past examples, but to show improvements with newly
 introduced tools.

 ** Start by writing a class.
 **** Static data of a class
 ** Then extend the class for more use. **** Keywords private,
 protected, public should be discussed in their relationship to modules.
 ** Introduce interfaces, maybe turn the first class into an interface
 ** Concentrate on function overriding and down/up casting. ** Inner
 classes
 ** Operator overloading

 I don't see templates as part of classes but still might be a good
 thing to cover.


I was trying to do bullet points, doing just a single will case bolding to happen (at least for me) and the 4 would be as sub of the 2. Anyway I tried to keep to the building off of the previous, but depending on the project example it may not be possible all the way through, thus needing to start a new example (which would be fine). I figured that it would also serve as a good list of things that you should look for when learning.
Mar 03 2008
parent "Saaa" <empty needmail.com> writes:
 I was trying to do bullet points, doing just a single will case bolding
 to happen (at least for me) and the 4 would be as sub of the 2.

 Anyway I tried to keep to the building off of the previous, but depending
 on the project example it may not be possible all the way through, thus
 needing to start a new example (which would be fine).

 I figured that it would also serve as a good list of things that you
 should look for when learning.

Thanks, I hope my previous post didn't come off too inappreciative. As I said, I barely understand half of the list which shows that I really need the help :)
Mar 03 2008
prev sibling next sibling parent reply Ty Tower <tytower hotmail.com.au> writes:
Saaa Wrote:

 I want to make a few (5-10?) D OOP tutorials for dsource.
 That way I can learn about oop myself and help D, I hope :)
 
 They should thus focus on people who never programmed in an oop style.
 
 Every tutorial should elaborate on the previous one, but on themselves also 
 compile into something interesting||useful.
 The filler code (not related to oop but necessary to make it a interesting 
 program) should not be too complex.
 
 Anybody any idea which kind of program suits best?
 The filler code in a ray tracer might just be a bit too complex.
 
 
 
 

Mar 03 2008
parent reply "Saaa" <empty needmail.com> writes:
Yeah, I never understood the whole foo thingy :)
But I'll just post all of them here first.
btw. I didn't know my english was that bad  :D

 Make sure you get someone who speaks English well and also knows something 
 about the subject to proof read it for you . Most of the problems I find 
 on the web tutorials are related to what you mean when you say "foo" as 
 opposed to what I normally associate with "foo" 

Mar 03 2008
parent reply "Saaa" <empty needmail.com> writes:
I meant: I won't use foo nor bar :)
And I'll at least proofread the tutorials myself (wwhich can't be said of 
any of posts here :D

 Make sure you get someone who speaks English well and also knows 
 something about the subject to proof read it for you . Most of the 
 problems I find on the web tutorials are related to what you mean when 
 you say "foo" as opposed to what I normally associate with "foo"


Mar 03 2008
parent reply "Saaa" <empty needmail.com> writes:
Ok, I'll will use some sort of spelling checking as well. 
Mar 03 2008
parent "Saaa" <empty needmail.com> writes:
LOL. And never use words more times then needed

 Ok, I'll will use some sort of spelling checking as well.
 

Mar 03 2008
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
Could anybody explain what exactly the difference between a class allocator 
and constructor is? 
Mar 04 2008
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
erm..

Class[] className;
className.length=10;
className.function;

results in runtime access violation.
Why? 
Mar 04 2008
parent reply novice2 <sorry noem.ail> writes:
 
 Class[] className;
 className.length=10;
 className.function;

may be this? Class[] className; className.length=10; className[0]=new Class(); className[0].function;
Mar 04 2008
parent reply "Saaa" <empty needmail.com> writes:
 may be this?

 Class[] className;
 className.length=10;
 className[0]=new Class();
 className[0].function;

Yes it is :) What then does Class[] className do exactly? Or, why do I need to use new?
Mar 04 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Saaa" <empty needmail.com> wrote in message 
news:fqjjn5$2jb6$1 digitalmars.com...
 may be this?

 Class[] className;
 className.length=10;
 className[0]=new Class();
 className[0].function;

Yes it is :) What then does Class[] className do exactly? Or, why do I need to use new?

The same reason: Class class; class.function; doesn't work. Because all class variables are references which point to nothing until you use 'new'. A Class[] is an array of references to class instances which is filled with nulls by default. You have to actually initialize the array by creating instances of the class. Class[] arr; foreach(ref c; arr) c = new C;
Mar 04 2008
parent reply "Saaa" <empty needmail.com> writes:
Thanks,
Why isn't it initialized?
I mean, when are these null referenced class pointers useful?

 may be this?

 Class[] className;
 className.length=10;
 className[0]=new Class();
 className[0].function;

Yes it is :) What then does Class[] className do exactly? Or, why do I need to use new?

The same reason: Class class; class.function; doesn't work. Because all class variables are references which point to nothing until you use 'new'. A Class[] is an array of references to class instances which is filled with nulls by default. You have to actually initialize the array by creating instances of the class. Class[] arr; foreach(ref c; arr) c = new C;

Mar 04 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Saaa" <empty needmail.com> wrote in message 
news:fqjknh$2lrm$1 digitalmars.com...
 Thanks,
 Why isn't it initialized?
 I mean, when are these null referenced class pointers useful?

The same time any null pointer is useful - when you want to use it as a sentinel for some reason. D is certainly not unique in this regard. In all the languages I've ever used or seen, not one will automatically allocate an object when you declare a reference or pointer to one. Maybe you're getting confused by C++ (I don't know your background) where: Class c; c.foo(); is legal, but something entirely different is happening here. This is more like a D struct, where the class is allocated on the stack, not the heap. In D: struct Struct { void foo() {} } ... Struct s; s.foo(); The D code: Class c = new Class; c.foo(); Translates to: Class* c = new Class(); c->foo(); in C++. Again, C++ will not automatically allocate a new class if you just write "Class* c".
Mar 04 2008
parent reply "Saaa" <empty needmail.com> writes:
I'm sorry, I've never used a null pointer (as far as I know) nor programmed 
in any oo style before.
I just thought that it would work like structures and if I wanted to have a 
nullpointer you could do something like:

Class[] className=void;

As I thought that most of the time you just want an instance and not just a 
reference to nothing.
Thats why I asked why other people wanted this null pointer.



 The same time any null pointer is useful - when you want to use it as a 
 sentinel for some reason.

 D is certainly not unique in this regard.  In all the languages I've ever 
 used or seen, not one will automatically allocate an object when you 
 declare a reference or pointer to one.

 Maybe you're getting confused by C++ (I don't know your background) where:

 Class c;
 c.foo();

 is legal, but something entirely different is happening here.  This is 
 more like a D struct, where the class is allocated on the stack, not the 
 heap. In D:

 struct Struct
 {
    void foo() {}
 }

 ...
 Struct s;
 s.foo();

 The D code:

 Class c = new Class;
 c.foo();

 Translates to:

 Class* c = new Class();
 c->foo();

 in C++.  Again, C++ will not automatically allocate a new class if you 
 just write "Class* c".
 

Mar 04 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
What is Class doesn't have a default constructor, or has many?

Saaa wrote:
 I'm sorry, I've never used a null pointer (as far as I know) nor programmed 
 in any oo style before.
 I just thought that it would work like structures and if I wanted to have a 
 nullpointer you could do something like:
 
 Class[] className=void;
 
 As I thought that most of the time you just want an instance and not just a 
 reference to nothing.
 Thats why I asked why other people wanted this null pointer.
 
 
 
 The same time any null pointer is useful - when you want to use it as a 
 sentinel for some reason.

 D is certainly not unique in this regard.  In all the languages I've ever 
 used or seen, not one will automatically allocate an object when you 
 declare a reference or pointer to one.

 Maybe you're getting confused by C++ (I don't know your background) where:

 Class c;
 c.foo();

 is legal, but something entirely different is happening here.  This is 
 more like a D struct, where the class is allocated on the stack, not the 
 heap. In D:

 struct Struct
 {
    void foo() {}
 }

 ...
 Struct s;
 s.foo();

 The D code:

 Class c = new Class;
 c.foo();

 Translates to:

 Class* c = new Class();
 c->foo();

 in C++.  Again, C++ will not automatically allocate a new class if you 
 just write "Class* c".


Mar 04 2008
parent reply "Saaa" <empty needmail.com> writes:
 What is Class doesn't have a default constructor, or has many?

What is the difference between `first only having a reference and then allocating` or `direct allocation` in those two cases? Or can't the instance be allocated in those cases? If they can't then what is the use of having only a reference to them?
Mar 04 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Saaa wrote:
 What is Class doesn't have a default constructor, or has many?

What is the difference between `first only having a reference and then allocating` or `direct allocation` in those two cases? Or can't the instance be allocated in those cases? If they can't then what is the use of having only a reference to them?

Interesting. I suppose there's no real reason, just inertia from C++. And the Principle of Least Surprise implies that potentially incurring a large cost with zero lines of code is a bad thing.
Mar 04 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Saaa wrote:
 Thanks,
 Why isn't it initialized?
 I mean, when are these null referenced class pointers useful?
 

Two things. First, a null reference is free to set up, whereas instantiating a class is not free. Second: --- class Bicycle { Human owner; } auto bike = new Bicycle(); --- The bike doesn't have an owner. Do you want to create a Human object that refers to nobody? Well, maybe, for some purposes, but not necessarily. That would probably alter your definition of Human.
Mar 04 2008
parent "Saaa" <empty needmail.com> writes:
 Two things.
 First, a null reference is free to set up, whereas instantiating a class 
 is not free.

But always writing an extra line isn't free and if nobody would use null references that would be kind of stupid. ^^ thats what I thought (^_^)
 Second:

 ---
 class Bicycle {
    Human owner;
 }

 auto bike = new Bicycle();
 ---
 The bike doesn't have an owner. Do you want to create a Human object that 
 refers to nobody? Well, maybe, for some purposes, but not necessarily. 
 That would probably alter your definition of Human.

bike would only hold a reference to an Human, right? and you say this is bad? Sorry, I read it as having only a reference is bad .. I must read this wrong :/
Mar 04 2008
prev sibling parent reply "Saaa" <empty needmail.com> writes:
Could anybody give a simple example of unallocated class reference use?
I think that would explain it all to me :)
Mar 04 2008
next sibling parent reply "Saaa" <empty needmail.com> writes:
 Could anybody give a simple example of unallocated class reference use?
 I think that would explain it all to me :)

Class className; // This will create a reference className=new Class(); // This will allocate an instance of Class Why do I need to name the class twice? Is there a shortcut? And, could I do: Class className; className=new Class_2(); I know some of my questions might be interpreted as being rhetorical, when they really aren't. I am that unknowing :)
Mar 04 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 04 Mar 2008 17:38:31 +0100, Saaa <empty needmail.com> wrote:

 Could anybody give a simple example of unallocated class reference us=


 I think that would explain it all to me :)

Class className; // This will create a reference className=3Dnew Class(); // This will allocate an instance of Class Why do I need to name the class twice? Is there a shortcut?

Class className =3D new Class(); should work, as should auto className =3D new Class();
 And, could I do:

 Class className;
 className=3Dnew Class_2();

Depending on whether or not Class_2 is inherited from Class, this might = = work. i.e, this works class Foo{} class Bar : Foo{} Foo f =3D new Bar(); And this does not: class FooBar{} class BarFoo{} FooBar f =3D new BarFoo();
 I know some of my questions might be interpreted as being rhetorical, =

 when
 they really aren't.
 I am that unknowing :)

Hey, we all started out knowing nothing. :p -- Simen
Mar 04 2008
parent "Saaa" <empty needmail.com> writes:
Thanks ;) 
Mar 05 2008
prev sibling parent lutger <lutger.blijdestijn gmail.com> writes:
Saaa wrote:

 Could anybody give a simple example of unallocated class reference use?
 I think that would explain it all to me :)


I'll try to give a few examples. 1. Error checking: Class theObject = tryToMakeTheObjectInASpecialWay(); if (theObject is null) throw new Exception("could not make the object!"); 2. Conditional construction, this isn't really a good way to do it but that doesn't matter for this example: Car myCar; if (winLottery == true) myCar = new Porsche(); else myCar = new Ford(); 3. Composition. It is common that objects holds references to other objects that are allocated at a later stage than that the 'parent' object is allocated. A classical example is a linked list: class List(T) { T data; List!(T) next; }
 Class className; // This will create a reference
 className=new Class(); // This will allocate an instance of Class
 
 Why do I need to name the class twice?
 Is there a shortcut?

In this case you don't, it's better to write: Class className = new Class(); or with type inference: auto className = new Class();
 And, could I do:
 
 Class className;
 className=new Class_2();

Yes, but only if Class_2 can be downcast to Class: class Class_2 : Class { } Again, you could also write Class className = new Class_2();
Mar 05 2008
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 04 Mar 2008 16:56:15 +0100, Saaa wrote:

 Could anybody give a simple example of unallocated class reference use?
 I think that would explain it all to me :)

class Bike { Human owner; this(Human o) { owner = o; } public void newOwner(Human o) { owner = o; } } class Human { Bike bike; char[] name; public: this(char[] n) { name = n; } void ride() { if(bike !is null) { writefln("%s is riding his bike", name); } } void purchase(Bike b) { b.newOwner(this); } } void main() { auto store = new Bike[10]; store[] = new Bike(null); Human joe = new Human("Joe"); joe.ride(); // Joe buys a new bike joe.purchase(store[4]); } you will notice that the bike requires an owner, but I provided none during creation. Also note that a Human does not have to own a bike, would you want to force a creation of bike even though he has not purchased one? I didn't test the code, but I hope it works. One of the things that happens as that you want a reference to an object type, but not create a new one, because later you will be getting the reference from somewhere else. Feel free to use what I have given you.
Mar 04 2008
next sibling parent reply "Saaa" <empty needmail.com> writes:
Thanks.

Why did you use:
    auto store = new Bike[10];
    store[] = new Bike(null);
iso:
    Bike[10] store;
    store[] = new Bike(null);

At first I thought that:
    auto store = new Bike[10];
would allocate the instances as well.


 class Bike {
    Human owner;

    this(Human o) {
         owner = o;
    }
    public void newOwner(Human o) {
         owner = o;
    }
 }

 class Human {
    Bike bike;
    char[] name;

 public:
   this(char[] n) { name = n; }

    void ride() {
         if(bike !is null) {
             writefln("%s is riding his bike", name);
         }
    }

    void purchase(Bike b) {
         b.newOwner(this);
    }
 }

 void main() {
    auto store = new Bike[10];
    store[] = new Bike(null);

    Human joe = new Human("Joe");
    joe.ride();

    // Joe buys a new bike
    joe.purchase(store[4]);
 }

 you will notice that the bike requires an owner, but I provided none
 during creation. Also note that a Human does not have to own a bike,
 would you want to force a creation of bike even though he has not
 purchased one? I didn't test the code, but I hope it works.

 One of the things that happens as that you want a reference to an object
 type, but not create a new one, because later you will be getting the
 reference from somewhere else. Feel free to use what I have given you. 

Mar 04 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jesse Phillips" <jessekphillips gmail.com> wrote in message 
news:fqkejg$1vkn$1 digitalmars.com...
 Just so you can ask that question, no not really but I'll tell you the
 difference.

 auto store = new Bike[10];

 Allocates memory on the heap, which means the function can return it.

 Bike[10] store;

 will allocate memory on the stack thus will not exist when the function
 returns. I had no reason not to use this, I just ended up not.

 And both arrays are static, thus there length will not change.

Nope. new Bike[10] allocates a new dynamically-sized array of length 10; the type of that expression is Bike[], not Bike[10]. It's really sugar for new Bike[](10). Thus its length can change. It's not actually possible to allocate a statically-sized array on the heap directly. You have to use a templated struct and allocate that.
Mar 04 2008
next sibling parent "Saaa" <empty needmail.com> writes:
Thanks all, I'll post the first three tutorials the moment I've finished 
them. 
Mar 05 2008
prev sibling parent reply Ty Tower <tytower hotmail.com.au> writes:
Jarrett Billingsley Wrote:

 "Jesse Phillips" <jessekphillips gmail.com> wrote in message 
 news:fqkejg$1vkn$1 digitalmars.com...
 Just so you can ask that question, no not really but I'll tell you the
 difference.

 auto store = new Bike[10];

 Allocates memory on the heap, which means the function can return it.

 Bike[10] store;

 will allocate memory on the stack thus will not exist when the function
 returns. I had no reason not to use this, I just ended up not.

 And both arrays are static, thus there length will not change.

Nope. new Bike[10] allocates a new dynamically-sized array of length 10; the type of that expression is Bike[], not Bike[10]. It's really sugar for new Bike[](10). Thus its length can change. It's not actually possible to allocate a statically-sized array on the heap directly. You have to use a templated struct and allocate that.

There is a definate problem So Tango version module Bike; import tango.io.Stdout; class Bike { Human owner; this(Human o) { owner = o; } public void newOwner(Human o) { owner = o; } } class Human { Bike bike; char[] name; public: this(char[] n) { name = n; } void ride() { if(bike !is null) { Stdout(name,"is now riding his new bike").newline; } else { Stdout("This guy has to walk at first").newline;} } void purchase(Bike b) { b.newOwner(this); bike=b; } } void main() { auto store = new Bike[10]; store[] = new Bike(null); Human joe = new Human("Joe"); joe.ride(); // Joe buys a new bike joe.purchase(store[4]); joe.ride(); } /* you will notice that the bike requires an owner, but I provided none during creation. Also note that a Human does not have to own a bike, would you want to force a creation of bike even though he has not purchased one? I didn't test the code, but I hope it works. One of the things that happens as that you want a reference to an object type, but not create a new one, because later you will be getting the reference from somewhere else. Feel free to use what I have given you. */ Interesting -thanks to all three of you
Mar 06 2008
parent reply "Saaa" <empty needmail.com> writes:
    auto store = new Bike[10];
    store[] = new Bike(null);

Would anything change if I would replace those two lines with: Bike[10] store; (It compiles, runs and outputs the same) Because I read those two lines as:
 Allocate memory for 10 bikes
 free the memory 

Mar 06 2008
parent Ty Tower <tytower hotmail.com.au> writes:
Jesse Phillips Wrote:

 On Fri, 07 Mar 2008 07:11:48 +0100, Saaa wrote:
 
    auto store = new Bike[10];
    store[] = new Bike(null);

Would anything change if I would replace those two lines with: Bike[10] store; (It compiles, runs and outputs the same) Because I read those two lines as:
 Allocate memory for 10 bikes
 free the memory


umm, yes. The first line is allocating the memory to store Bikes on to the heap. Your suggested line will do the same, but on the stack. Where the problem comes is if you remove the second line. Here's a modification to show that. Try it with and without the line, I'll explain below. class Bike { Human owner; char[] type; this(Human o, char[] t) { owner = o; type = t; } public void newOwner(Human o) { owner = o; } public void ride() { writefln("riding his new %s bike", type); } } class Human { Bike bike; char[] name; public: this(char[] n) { name = n; } void ride() { if(bike !is null) { writef("%s is", name); bike.ride(); } } void purchase(Bike b) { b.newOwner(this); bike = b; } } void main() { Bike[10] store; store[] = new Bike(null, "street"); Human joe = new Human("Joe"); joe.ride(); // Joe buys a new bike joe.purchase(store[4]); } assuming I didn't mess up again, if you try to run it without the second line in main you should get either a segfault as I don't recall D having the nullPointerExceptions. Anyway, the second line is filling the array of Bike with instances of Bike. You may want to try but I don't think it will work. Bike[10] store = new Bike(null, "street);

Mar 07 2008
prev sibling parent "Saaa" <empty needmail.com> writes:
Joe doesn't seem to get his bike :/

Is this how you meant it?

void purchase(Bike b) {
   b.newOwner(this);
   bike=b;
}


 class Bike {
    Human owner;

    this(Human o) {
         owner = o;
    }
    public void newOwner(Human o) {
         owner = o;
    }
 }

 class Human {
    Bike bike;
    char[] name;

 public:
   this(char[] n) { name = n; }

    void ride() {
         if(bike !is null) {
             writefln("%s is riding his bike", name);
         }
    }

    void purchase(Bike b) {
         b.newOwner(this);
    }
 }

 void main() {
    auto store = new Bike[10];
    store[] = new Bike(null);

    Human joe = new Human("Joe");
    joe.ride();

    // Joe buys a new bike
    joe.purchase(store[4]);
 }

 you will notice that the bike requires an owner, but I provided none
 during creation. Also note that a Human does not have to own a bike,
 would you want to force a creation of bike even though he has not
 purchased one? I didn't test the code, but I hope it works.

 One of the things that happens as that you want a reference to an object
 type, but not create a new one, because later you will be getting the
 reference from somewhere else. Feel free to use what I have given you. 

Mar 04 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
Just so you can ask that question, no not really but I'll tell you the 
difference.

auto store = new Bike[10];

Allocates memory on the heap, which means the function can return it.

Bike[10] store;

will allocate memory on the stack thus will not exist when the function 
returns. I had no reason not to use this, I just ended up not.

And both arrays are static, thus there length will not change.

A note to your other reply, you are correct, that was what I meant.

On Tue, 04 Mar 2008 18:19:47 +0100, Saaa wrote:

 Thanks.
 
 Why did you use:
     auto store = new Bike[10];
     store[] = new Bike(null);
 iso:
     Bike[10] store;
     store[] = new Bike(null);
 
 At first I thought that:
     auto store = new Bike[10];
 would allocate the instances as well.
 
 
 class Bike {
    Human owner;

    this(Human o) {
         owner = o;
    }
    public void newOwner(Human o) {
         owner = o;
    }
 }

 class Human {
    Bike bike;
    char[] name;

 public:
   this(char[] n) { name = n; }

    void ride() {
         if(bike !is null) {
             writefln("%s is riding his bike", name);
         }
    }

    void purchase(Bike b) {
         b.newOwner(this);
    }
 }

 void main() {
    auto store = new Bike[10];
    store[] = new Bike(null);

    Human joe = new Human("Joe");
    joe.ride();

    // Joe buys a new bike
    joe.purchase(store[4]);
 }

 you will notice that the bike requires an owner, but I provided none
 during creation. Also note that a Human does not have to own a bike,
 would you want to force a creation of bike even though he has not
 purchased one? I didn't test the code, but I hope it works.

 One of the things that happens as that you want a reference to an
 object type, but not create a new one, because later you will be
 getting the reference from somewhere else. Feel free to use what I have
 given you.


Mar 04 2008
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 07 Mar 2008 07:11:48 +0100, Saaa wrote:

    auto store = new Bike[10];
    store[] = new Bike(null);

Would anything change if I would replace those two lines with: Bike[10] store; (It compiles, runs and outputs the same) Because I read those two lines as:
 Allocate memory for 10 bikes
 free the memory


umm, yes. The first line is allocating the memory to store Bikes on to the heap. Your suggested line will do the same, but on the stack. Where the problem comes is if you remove the second line. Here's a modification to show that. Try it with and without the line, I'll explain below. class Bike { Human owner; char[] type; this(Human o, char[] t) { owner = o; type = t; } public void newOwner(Human o) { owner = o; } public void ride() { writefln("riding his new %s bike", type); } } class Human { Bike bike; char[] name; public: this(char[] n) { name = n; } void ride() { if(bike !is null) { writef("%s is", name); bike.ride(); } } void purchase(Bike b) { b.newOwner(this); bike = b; } } void main() { Bike[10] store; store[] = new Bike(null, "street"); Human joe = new Human("Joe"); joe.ride(); // Joe buys a new bike joe.purchase(store[4]); } assuming I didn't mess up again, if you try to run it without the second line in main you should get either a segfault as I don't recall D having the nullPointerExceptions. Anyway, the second line is filling the array of Bike with instances of Bike. You may want to try but I don't think it will work. Bike[10] store = new Bike(null, "street);
Mar 06 2008