By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,052 Members | 1,249 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,052 IT Pros & Developers. It's quick & easy.

Code getting Crashed( C++)

P: n/a
#include<iostream.h>
#include<memory.h>
#include<string.h>
// product
class Pizza
{
private :
std::string Topping;
std::string Sauce;
std::string Dough;

public :
Pizza(){}
~Pizza(){}

void SetTopping(const std::string t) { Topping = t; }
void SetSauce(const std::string s){ Sauce = s; }
void SetDough(const std::string d){ Dough = d; }

void ShowPizza()
{
std::cout <<"What a Pizza"<<std::endl
<<"Topping is "<<Topping
<<"Sauce is "<<Sauce
<<"Dough is "<<Dough
<<"! ! !"<<'\n';
}

};
// Abstract Builder
class PizzaBuilder
{
protected :
std::auto_ptr<Pizzapizza;

public :
PizzaBuilder(){}
virtual ~PizzaBuilder(){}

std::auto_ptr<PizzaGetPizza(){return pizza;}

virtual void BuildTopping() = 0;
virtual void BuildSauce() = 0;
virtual void BuildDough() = 0;

std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }

/*********** code getting crashed here ***************/

};

// concrete Pizza Builder 1
class Hawian_PizzaBuilder : public PizzaBuilder
{

public :
Hawian_PizzaBuilder():PizzaBuilder(){ }
~Hawian_PizzaBuilder(){ }
void BuildTopping() { pizza->SetTopping(" Hawian_PizzaBuilder
Topping ");}
void BuildSauce() { pizza->SetSauce("Hawian_PizzaBuilder
Sauce ");}
void BuildDough() { pizza->SetDough("Hawian_PizzaBuilder
Dough ");}

};

// concrete Pizza Builder 2
class Spicy_PizzaBuilder : public PizzaBuilder
{

public :
Spicy_PizzaBuilder():PizzaBuilder(){}
~Spicy_PizzaBuilder(){}
void BuildTopping() { pizza->SetTopping("Spicy_PizzaBuilder Topping
"); }
void BuildSauce() { pizza->SetSauce("Spicy_PizzaBuilder
Sauce "); }
void BuildDough() { pizza->SetDough("Spicy_PizzaBuilder
Dough "); }

};
// Director
class waiter
{
private :
PizzaBuilder * pizza_builder;
public :
waiter(): pizza_builder(NULL){}
~waiter(){}

void SetPizzaBuilder(PizzaBuilder * b){ pizza_builder = b ;}
std::auto_ptr<PizzaGetPizza(){ return pizza_builder-
>GetPizza();}
void ConstructPizza()
{
pizza_builder->CreateNew_PizzaProduct();
pizza_builder->BuildDough();
pizza_builder->BuildSauce();
pizza_builder->BuildTopping();
}
};
// user
int main()
{

waiter waiter_1;

Spicy_PizzaBuilder spicyPizzaBuilder;
waiter_1.SetPizzaBuilder(&spicyPizzaBuilder);

waiter_1.ConstructPizza(); // code getting Crashed here

std::auto_ptr<Pizzapizza = waiter_1.GetPizza();
pizza->ShowPizza();

return 0;
}
Aug 7 '08 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On Aug 7, 5:39 am, Pallav singh <singh.pal...@gmail.comwrote:
#include<iostream.h>
#include<memory.h>
#include<string.h>
#include<iostream>
#include<memory>
#include<string>

if your teacher or book doesn't require the above, they shouldn't be
teaching or be read.
Welcome to the 21st century.
>
// product
class Pizza
{
private :
std::string Topping;
std::string Sauce;
std::string Dough;

public :
Pizza(){}
~Pizza(){}

void SetTopping(const std::string t) { Topping = t; }
void SetSauce(const std::string s){ Sauce = s; }
void SetDough(const std::string d){ Dough = d; }

void ShowPizza()
{
std::cout <<"What a Pizza"<<std::endl
<<"Topping is "<<Topping
<<"Sauce is "<<Sauce
<<"Dough is "<<Dough
<<"! ! !"<<'\n';
}

};

// Abstract Builder
class PizzaBuilder
{
protected :
std::auto_ptr<Pizzapizza;

public :
PizzaBuilder(){}
virtual ~PizzaBuilder(){}

std::auto_ptr<PizzaGetPizza(){return pizza;}

virtual void BuildTopping() = 0;
virtual void BuildSauce() = 0;
virtual void BuildDough() = 0;

std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }
aren't you reseting the private member auto_ptr?
why does the function signature indicate a return type and yet no
return is supplied?
try:
void CreateNew_PizzaProduct() { ... }
>
/*********** code getting crashed here ***************/
Your compiler should have detected the above anomaly, perhaps you need
to take a look at the compiler options. Thats off topic here.
>
};

// concrete Pizza Builder 1
class Hawian_PizzaBuilder : public PizzaBuilder
{

public :
Hawian_PizzaBuilder():PizzaBuilder(){ }
~Hawian_PizzaBuilder(){ }
void BuildTopping() { pizza->SetTopping(" Hawian_PizzaBuilder
Topping ");}
void BuildSauce() { pizza->SetSauce("Hawian_PizzaBuilder
Sauce ");}
void BuildDough() { pizza->SetDough("Hawian_PizzaBuilder
Dough ");}

};

// concrete Pizza Builder 2
class Spicy_PizzaBuilder : public PizzaBuilder
{

public :
Spicy_PizzaBuilder():PizzaBuilder(){}
~Spicy_PizzaBuilder(){}
void BuildTopping() { pizza->SetTopping("Spicy_PizzaBuilder Topping
"); }
void BuildSauce() { pizza->SetSauce("Spicy_PizzaBuilder
Sauce "); }
void BuildDough() { pizza->SetDough("Spicy_PizzaBuilder
Dough "); }

};

// Director
class waiter
{
private :
PizzaBuilder * pizza_builder;
public :
waiter(): pizza_builder(NULL){}
~waiter(){}

void SetPizzaBuilder(PizzaBuilder * b){ pizza_builder = b ;}
std::auto_ptr<PizzaGetPizza(){ return pizza_builder-
GetPizza();}

void ConstructPizza()
{
pizza_builder->CreateNew_PizzaProduct();
pizza_builder->BuildDough();
pizza_builder->BuildSauce();
pizza_builder->BuildTopping();
}

};

// user
int main()
{

waiter waiter_1;

Spicy_PizzaBuilder spicyPizzaBuilder;
waiter_1.SetPizzaBuilder(&spicyPizzaBuilder);

waiter_1.ConstructPizza(); // code getting Crashed here

std::auto_ptr<Pizzapizza = waiter_1.GetPizza();
pizza->ShowPizza();

return 0;

}
Aug 7 '08 #2

P: n/a
On 2008-08-07 11:39, Pallav singh wrote:
#include<iostream.h>
#include<memory.h>
#include<string.h>
Drop the .h, it is pre-standard C++ (10 years old).

// Abstract Builder
class PizzaBuilder
{
protected :
std::auto_ptr<Pizzapizza;

public :
PizzaBuilder(){}
virtual ~PizzaBuilder(){}

std::auto_ptr<PizzaGetPizza(){return pizza;}

virtual void BuildTopping() = 0;
virtual void BuildSauce() = 0;
virtual void BuildDough() = 0;

std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }
Actually I'm surprised your code crashes, because it should not even
compile. In the above function you forgot to return a value. It might be
possible (though it should not happen) that your compiler returns some
default value which is somehow converted to std::auto_ptr<Pizzawhich
causes a crash when CreateNew_PizzaProduct is called in ConstructPizza.

--
Erik Wikström
Aug 7 '08 #3

P: n/a
On Aug 7, 4:00 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-08-07 11:39, Pallav singh wrote:
#include<iostream.h>
#include<memory.h>
#include<string.h>

Drop the .h, it is pre-standard C++ (10 years old).
// Abstract Builder
class PizzaBuilder
{
protected :
std::auto_ptr<Pizzapizza;
public :
PizzaBuilder(){}
virtual ~PizzaBuilder(){}
std::auto_ptr<PizzaGetPizza(){return pizza;}
virtual void BuildTopping() = 0;
virtual void BuildSauce() = 0;
virtual void BuildDough() = 0;
std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }

Actually I'm surprised your code crashes, because it should not even
compile. In the above function you forgot to return a value. It might be
possible (though it should not happen) that your compiler returns some
default value which is somehow converted to std::auto_ptr<Pizzawhich
causes a crash when CreateNew_PizzaProduct is called in ConstructPizza.

--
Erik Wikström
Thanks
Pallav
Aug 7 '08 #4

P: n/a
On Aug 7, 11:00 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-08-07 11:39, Pallav singh wrote:
std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }

Actually I'm surprised your code crashes, because it should not even
compile. In the above function you forgot to return a value.
The above code need not generate a compiler
diagnostic. Furthermore, no code 'should not
compile' unless it contains a #error directive.

The behaviour is undefined if the function is actually called.
Aug 8 '08 #5

P: n/a
On Aug 7, 1:00 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-08-07 11:39, Pallav singh wrote:
std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }
Actually I'm surprised your code crashes, because it should
not even compile. In the above function you forgot to return a
value.
Which is undefined behavior, and doesn't require a diagnostic.
It would be nice if the compiler issued a warning, but the code
is perfectly legal if a) the function is never actually called,
or b) the expression "new Pizza()" always threw an exception, or
failed to return normally for some other reason.

This is even useful, in some admittedly rare cases, e.g.:

SomeType
Derived::f()
{
// The base class imposes pre-conditions which can
// never be met in this derived class, so...
assert( 0, "pre-conditions not met" ) ;
abort() ;
}
It might be possible (though it should not happen) that your
compiler returns some default value which is somehow converted
to std::auto_ptr<Pizzawhich causes a crash when
CreateNew_PizzaProduct is called in ConstructPizza.
More likely, his compiler supposes that no code flow will ever
result in falling off the end, and doesn't do anything. So the
calling code ends up using uninitialized memory as an auto_ptr.
(Note that even if the calling code doesn't use the return value
explicitly, it will call the destructor on it.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aug 8 '08 #6

P: n/a
On 2008-08-07 21:34:45 -0400, Old Wolf <ol*****@inspire.net.nzsaid:
>
Furthermore, no code 'should not
compile' unless it contains a #error directive.
That's the rule in C. In C++ a #error directive makes the code
ill-formed, so only requires a diagnostic.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Aug 8 '08 #7

P: n/a
"James Kanze" <ja*********@gmail.comwrote in message news:66**********************************@m73g2000 hsh.googlegroups.com...
On Aug 7, 1:00 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-08-07 11:39, Pallav singh wrote:
>> std::auto_ptr<PizzaCreateNew_PizzaProduct()
{ pizza.reset(new Pizza()); }
>Actually I'm surprised your code crashes, because it should
not even compile. In the above function you forgot to return a
value.
Which is undefined behavior, and doesn't require a diagnostic.
It would be nice if the compiler issued a warning, but the code
is perfectly legal if a) the function is never actually called,
or b) the expression "new Pizza()" always threw an exception, or
failed to return normally for some other reason.

This is even useful, in some admittedly rare cases, e.g.:

SomeType
Derived::f()
{
// The base class imposes pre-conditions which can
// never be met in this derived class, so...
assert( 0, "pre-conditions not met" ) ;
abort() ;
}
From a purist perspective, should Derived really inherit from the base class in question in this case? (I realise that there can sometimes be occasions when pragmatism is necessary - just wondering whether this is in principle best avoided?) I remember reading somewhere (and it makes sense to me) that an overridden function should have preconditions which are no stronger than than those of the base function it overrides (i.e. it accepts anything the base function would), and postconditions which are no weaker than those of the base function (i.e. it makes at least the same guarantees that the base function does). If the overridden function can't be made to accept something the base function would, then should the inheritance relationship between the containing classes really exist?
>It might be possible (though it should not happen) that your
compiler returns some default value which is somehow converted
to std::auto_ptr<Pizzawhich causes a crash when
CreateNew_PizzaProduct is called in ConstructPizza.
More likely, his compiler supposes that no code flow will ever
result in falling off the end, and doesn't do anything. So the
calling code ends up using uninitialized memory as an auto_ptr.
(Note that even if the calling code doesn't use the return value
explicitly, it will call the destructor on it.)
Aug 8 '08 #8

P: n/a
On Aug 8, 3:33 pm, "Stuart Golodetz"
<sgolod...@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
"James Kanze" <james.ka...@gmail.comwrote in
messagenews:66**********************************@m 73g2000hsh.googlegroups..com...
[...]
This is even useful, in some admittedly rare cases, e.g.:
SomeType
Derived::f()
{
// The base class imposes pre-conditions which can
// never be met in this derived class, so...
assert( 0, "pre-conditions not met" ) ;
abort() ;
}
From a purist perspective, should Derived really inherit from
the base class in question in this case?
It depends. It depends on the contract of the base class, and
on the implementation of the derived class. It's not
unreasonable to imagine functions in the base class that can
only be called in a specific sequence, or a function f() that
can only be called if g() has successfully been called first.
If the implementation of the derived class is such that such
conditions can never occur, then yes, it's reasonable. I don't
think that the case occurs very often, but it can occur.

Most of the time such cases occur, of course; they are the
result of a compromise: the base class declares all possibly
supported functionality in a single interfaces, rather than have a
hierarchy of interfaces: say SeekableInputSource which derives
from InputSource. But I don't think that this is always the
case (although I can't think of any really good examples off
hand).
(I realise that there can sometimes be occasions when
pragmatism is necessary - just wondering whether this is in
principle best avoided?) I remember reading somewhere (and it
makes sense to me) that an overridden function should have
preconditions which are no stronger than than those of the
base function it overrides (i.e. it accepts anything the base
function would), and postconditions which are no weaker than
those of the base function (i.e. it makes at least the same
guarantees that the base function does). If the overridden
function can't be made to accept something the base function
would, then should the inheritance relationship between the
containing classes really exist?
The overriding class can strengthen post-conditions and
invariants. What if the pre-condition involves a post-condition
or invariant which the overriding class has excluded? E.g. a
very artificial example:

class Base
{
public:
virtual int f() ; // post: return value >= 0 and < 100
virtual void g() ; // pre: f() has been called, and
// returned a value 10
} ;

class Derived : public Base
{
public:
virtual int f() ; // post: return value >= 0 and < 10
virtual void g() ; // ???
} ;

I'm pretty sure I've encountered such cases once or twice (in
close to 20 years C++, so they aren't that common), although I
can't remember any details off hand.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aug 9 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.