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.

Thanks ;)

Thanks all, I'll post the first three tutorials the moment I've finished them.

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();

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.
> 
> 
I notice good old Jesse doesn't answer when someone corrects him. No thanks either 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

>    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

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);

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);
Runs fine with the bottom line in