www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - return string from inside if block => Segmentation Fault: 11

reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jun 01 2015
next sibling parent reply "Alex Parrill" <initrd.gz gmail.com> writes:
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.
Jun 01 2015
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jun 01 2015
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Jun 01 2015
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jun 01 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jun 01 2015
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
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
Jun 02 2015
parent "Kapps" <opantm2+spam gmail.com> writes:
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).
Jun 02 2015
prev sibling parent "Alex Parrill" <initrd.gz gmail.com> writes:
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.
Jun 01 2015