I'm a bit confused... I have the following class:

class foo : superFoo {
aFoo spec;
aFoo lvars;
aFoo bdy;

 override string toString(){
   if(spec.isEmpty() && lvars.isEmpty()){
     return "does spec";
   }

   if(lvars.isEmpty()){
     return "funct spec";
   }

   return "function spec";
 }
}

The thing is, as soon as one if the IFs is true and the return statement is executed I get a seg-fault: 11

If I comment the IFs it works. But I can't see any differences in returning from inside the if vs. the return at the end of the function.

Any idea?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 1 June 2015 at 16:52:30 UTC, Robert M. Münch wrote:
> I'm a bit confused... I have the following class:
>
> class foo : superFoo {
> aFoo spec;
> aFoo lvars;
> aFoo bdy;
>
>  override string toString(){
>    if(spec.isEmpty() && lvars.isEmpty()){
>      return "does spec";
>    }
>
>    if(lvars.isEmpty()){
>      return "funct spec";
>    }
>
>    return "function spec";
>  }
> }
>
> The thing is, as soon as one if the IFs is true and the return statement is executed I get a seg-fault: 11
>
> If I comment the IFs it works. But I can't see any differences in returning from inside the if vs. the return at the end of the function.
>
> Any idea?

Are you sure that it's not the calls to `isEmpty`? Check if spec, lvars, or anything that `isEmpty` uses are null.

On Monday, 1 June 2015 at 16:52:30 UTC, Robert M. Münch wrote:
> I'm a bit confused... I have the following class:
>
> class foo : superFoo {
> aFoo spec;
> aFoo lvars;
> aFoo bdy;
>
>  override string toString(){
>    if(spec.isEmpty() && lvars.isEmpty()){
>      return "does spec";
>    }
>
>    if(lvars.isEmpty()){
>      return "funct spec";
>    }
>
>    return "function spec";
>  }
> }
>
> The thing is, as soon as one if the IFs is true and the return statement is executed I get a seg-fault: 11
>
> If I comment the IFs it works. But I can't see any differences in returning from inside the if vs. the return at the end of the function.
>
> Any idea?

Chances are very good that it's the code within the if statement, classes are null by default, you're checking if null isEmpty, thus getting a segfault.

On 2015-06-01 17:06:27 +0000, Kapps said:

> Chances are very good that it's the code within the if statement, classes are null by default, you're checking if null isEmpty, thus getting a segfault.

Isn't the construtor of the contained types run when the class is constructed? Or do I need to explicitly initialize the contained types on my own?

(haven't touched the OO part of D yet so much)

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On 6/1/15 1:19 PM, Robert M. Münch wrote:
> On 2015-06-01 17:06:27 +0000, Kapps said:
>
>> Chances are very good that it's the code within the if statement,
>> classes are null by default, you're checking if null isEmpty, thus
>> getting a segfault.
>
> Isn't the construtor of the contained types run when the class is
> constructed? Or do I need to explicitly initialize the contained types
> on my own?

No, you must explicitly intialize. Classes are ALL reference types in D, no in-situ placement of classes (without a lot of heavy lifting):

class C
{
}

class D
{
   C c; // this is a *reference* to a C object, equivalent to C* c if you were using C++
   this()
   {
      assert(c is null); // not yet initialized!
      c = new C; // now the ctor is run.
   }
}

Note that c is initialized, to null :) So an initialization does happen, but not what you expected. This whole thing avoids the requirement of initialization of members before the ctor runs (like in C++).

-Steve

On Monday, 1 June 2015 at 17:19:50 UTC, Robert M. Münch wrote:
>
> Isn't the construtor of the contained types run when the class is constructed? Or do I need to explicitly initialize the contained types on my own?
>
> (haven't touched the OO part of D yet so much)

Classes are not automatically created; they default to null.

On 2015-06-01 16:54:58 +0000, Alex Parrill said:

> Are you sure that it's not the calls to `isEmpty`? Check if spec, lvars, or anything that `isEmpty` uses are null.

Yep, I was confused by my own naming. I don't have to check against isEmpty but instead "... is null" ...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On 2015-06-01 17:29:08 +0000, Steven Schveighoffer said:

> No, you must explicitly intialize. Classes are ALL reference types in D, no in-situ placement of classes

Ok, thanks. Still to much C++ logic in my head ;-) I'm getting rid of it step-by-step.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Tuesday, 2 June 2015 at 07:18:33 UTC, Robert M. Münch wrote:
> On 2015-06-01 17:29:08 +0000, Steven Schveighoffer said:
>
>> No, you must explicitly intialize. Classes are ALL reference types in D, no in-situ placement of classes
>
> Ok, thanks. Still to much C++ logic in my head ;-) I'm getting rid of it step-by-step.

Note that if they were structs, they would be default initialized without having to new, similar in a way to C++ (but with a defined init value).