[ Pobierz całość w formacie PDF ]
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
super.resize(x, y); //the name of the base class is not necessary anymore
//add functionality
int size = x*y;
}
};
class specialRect: public rectangle
{
void resize (int x, int y) //extends base's resize()
{
super.resize(x, y); //calls recatngle::resize()
//add more functionality
}
};
However, super is ambiguous in objects that have multiple base classes. An alternative solution is to add a
different keyword to the language, extensible, that instructs the compiler to insert a call of the base member
function in an overriding member function automatically. For example
class shape
{
public:
extensible void resize();
}
class rectangle: public shape
{
public:
void resize (int x, int y) //extends base's resize()
{ //shape::resize() is implicitly invoked at this point
//add functionality
int size = x*y;
}
};
class specialRect: public rectangle
{
void resize (int x, int y) //extends base's resize()
{ //implicitly calls recatngle::resize()
//...add more functionality
}
};
extensible is a specialized form of virtual, so the latter is unnecessary. Surely, extensible solves the
first problem: If the base class name changes, the implementer of the derived class does not have to change the
definition of the member functions. The second problem is also solved here: After a member function is declared
extensible, the compiler automatically sees that the corresponding member function of a derived class first
invokes the member function of the base class.
Dynamically Linked Libraries
A typical C++ application consists of a statically linked executable that contains all the code and data of the
program. Although static linking is efficient in terms of speed, it's inflexible: Every change in the code requires a
complete rebuild of the executable. When a dynamically linked library is used, the executable does not need to be
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (16 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
rebuilt; the next time the application is run, it automatically picks up the new library version. The advantage of
dynamically linked libraries is a transparent upgrade of new releases of the dynamically linked library. However,
this transparent "drop in" model breaks under the object model of C++ if the data layout of an object changes in the
new release of the library; this is because the size of an object and the offset of its data members are fixed at compile
time. There have been suggestions to extend the object model of C++ so that it can support dynamic shared libraries
better. However, the costs are slower execution speed and size.
Rule-Based Programming
Many commercial databases support triggers. A trigger is a user-defined rule that instructs the system to perform
specific actions automatically whenever a certain data value changes. For example, imagine a database that contains
two tables, Person and Bank Account. Every row in Bank Account is associated with a record in Person. Deleting a
Person record automatically triggers the deletion of all its associated Bank Account records. Rules are the equivalent
of triggers in software systems. William Tepfenhart and other researchers at AT&T Bell Laboratories have extended
C++ to support rules (UML and C++: A Practical Guide to Object-Oriented Development, p. 137). The extended
language is called R++ (the R stands for "rules"). In addition to member functions and data members, R++ defines a
third kind of class member: a rule. A rule consists of a condition and an associated action that is automatically
executed when the condition evaluates to true. In C++, the programmer has to test the condition manually in order
to decide whether the associated action is to be executed, usually by a switch statement or an if statement. In
R++, this testing is automated -- the system monitors the data members listed in the rule's condition, and whenever
the condition is satisfied, the rule "fires" (that is, the associated action is executed). Rule-based programming is
widely used in artificial intelligence, debugging systems, and event-driven systems. Adding this feature to C++
could considerably simplify the design and implementation of such systems.
Conclusions
Language extensions are needed to facilitate the implementation of operations that otherwise might be more difficult
or even impossible. However, there is always a tradeoff involved. To use an analogy, adding an air conditioner to a
car decreases its fuel efficiency and degrades its performance (Principles of Programming Languages: Design,
Evaluation and Implementation, p. 327). Whether it is a beneficial tradeoff depends on various factors, such as the
climate in the region where the car is used, the cost of fuel, the engine's power, and the personal preferences of its
users. Note that the air conditioner can always be turned off to gain more power and increase the fuel efficiency.
Ideally, new language features will not impose a performance penalty of any kind when they are not used. When the
programmer deliberately uses them, they should impose as little overhead as possible or no overhead at all. There is,
however, a notable difference between an air conditioner and language extensions: Extensions interact with one
another. For example, the imaginary keyword super has an undesirable interaction with another language feature,
namely multiple inheritance. A more realistic example is template's template arguments. The space between the left
two angular brackets is mandatory:
Vector msg_que(10);
Otherwise, the >> sequence is parsed as the right shift operator. In other situations, the interaction is much more
complex: Koenig lookup, for instance, can have surprising results under some circumstances (as you read in Chapter
8, "Namespaces").
This chapter has presented three major proposals for language extensions: garbage collection, persistence, and
concurrency. Suggestions for less radical extensions are extensible members and rules. None of these is to be taken
lightly. The complexity involved in standardizing each of these is intensified even further when they interact with
each other. For example, a persistence model becomes even more complicated in a thread-safe environment.
Considering the challenges that the designers of C++ have faced during the past two decades, you can remain
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (17 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
optimistic. If you are familiar with the prestandardized implementations of container classes, RTTI, and exception
handling of several well known frameworks, you are probably aware of how the standardized container classes,
RTTI, and exception handling are much better in every way. This will also be the case if any of the features that are
discussed here become part of the C++ Standard.
Contents
© Copyright 1999, Macmillan Computer Publishing. All rights reserved.
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (18 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook -- Copyright 1999
ANSI/ISO C++ Professional
Programmer's Handbook
Printed Book Copyright
©Copyright 1999, by Que
All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted
by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission
from the publisher. No patent liability is assumed with respect to the use of the information contained
herein. Although every precaution has been taken in the preparation of this book, the publisher and
author assume no responsibility for errors or omissions. Neither is any liability assumed for damages
resulting from the use of the information contained herein.
International Standard Book Number: 0-7897-2022-1
Library of Congress Catalog Card Number: 99-62146 [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl fopke.keep.pl
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
super.resize(x, y); //the name of the base class is not necessary anymore
//add functionality
int size = x*y;
}
};
class specialRect: public rectangle
{
void resize (int x, int y) //extends base's resize()
{
super.resize(x, y); //calls recatngle::resize()
//add more functionality
}
};
However, super is ambiguous in objects that have multiple base classes. An alternative solution is to add a
different keyword to the language, extensible, that instructs the compiler to insert a call of the base member
function in an overriding member function automatically. For example
class shape
{
public:
extensible void resize();
}
class rectangle: public shape
{
public:
void resize (int x, int y) //extends base's resize()
{ //shape::resize() is implicitly invoked at this point
//add functionality
int size = x*y;
}
};
class specialRect: public rectangle
{
void resize (int x, int y) //extends base's resize()
{ //implicitly calls recatngle::resize()
//...add more functionality
}
};
extensible is a specialized form of virtual, so the latter is unnecessary. Surely, extensible solves the
first problem: If the base class name changes, the implementer of the derived class does not have to change the
definition of the member functions. The second problem is also solved here: After a member function is declared
extensible, the compiler automatically sees that the corresponding member function of a derived class first
invokes the member function of the base class.
Dynamically Linked Libraries
A typical C++ application consists of a statically linked executable that contains all the code and data of the
program. Although static linking is efficient in terms of speed, it's inflexible: Every change in the code requires a
complete rebuild of the executable. When a dynamically linked library is used, the executable does not need to be
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (16 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
rebuilt; the next time the application is run, it automatically picks up the new library version. The advantage of
dynamically linked libraries is a transparent upgrade of new releases of the dynamically linked library. However,
this transparent "drop in" model breaks under the object model of C++ if the data layout of an object changes in the
new release of the library; this is because the size of an object and the offset of its data members are fixed at compile
time. There have been suggestions to extend the object model of C++ so that it can support dynamic shared libraries
better. However, the costs are slower execution speed and size.
Rule-Based Programming
Many commercial databases support triggers. A trigger is a user-defined rule that instructs the system to perform
specific actions automatically whenever a certain data value changes. For example, imagine a database that contains
two tables, Person and Bank Account. Every row in Bank Account is associated with a record in Person. Deleting a
Person record automatically triggers the deletion of all its associated Bank Account records. Rules are the equivalent
of triggers in software systems. William Tepfenhart and other researchers at AT&T Bell Laboratories have extended
C++ to support rules (UML and C++: A Practical Guide to Object-Oriented Development, p. 137). The extended
language is called R++ (the R stands for "rules"). In addition to member functions and data members, R++ defines a
third kind of class member: a rule. A rule consists of a condition and an associated action that is automatically
executed when the condition evaluates to true. In C++, the programmer has to test the condition manually in order
to decide whether the associated action is to be executed, usually by a switch statement or an if statement. In
R++, this testing is automated -- the system monitors the data members listed in the rule's condition, and whenever
the condition is satisfied, the rule "fires" (that is, the associated action is executed). Rule-based programming is
widely used in artificial intelligence, debugging systems, and event-driven systems. Adding this feature to C++
could considerably simplify the design and implementation of such systems.
Conclusions
Language extensions are needed to facilitate the implementation of operations that otherwise might be more difficult
or even impossible. However, there is always a tradeoff involved. To use an analogy, adding an air conditioner to a
car decreases its fuel efficiency and degrades its performance (Principles of Programming Languages: Design,
Evaluation and Implementation, p. 327). Whether it is a beneficial tradeoff depends on various factors, such as the
climate in the region where the car is used, the cost of fuel, the engine's power, and the personal preferences of its
users. Note that the air conditioner can always be turned off to gain more power and increase the fuel efficiency.
Ideally, new language features will not impose a performance penalty of any kind when they are not used. When the
programmer deliberately uses them, they should impose as little overhead as possible or no overhead at all. There is,
however, a notable difference between an air conditioner and language extensions: Extensions interact with one
another. For example, the imaginary keyword super has an undesirable interaction with another language feature,
namely multiple inheritance. A more realistic example is template's template arguments. The space between the left
two angular brackets is mandatory:
Vector msg_que(10);
Otherwise, the >> sequence is parsed as the right shift operator. In other situations, the interaction is much more
complex: Koenig lookup, for instance, can have surprising results under some circumstances (as you read in Chapter
8, "Namespaces").
This chapter has presented three major proposals for language extensions: garbage collection, persistence, and
concurrency. Suggestions for less radical extensions are extensible members and rules. None of these is to be taken
lightly. The complexity involved in standardizing each of these is intensified even further when they interact with
each other. For example, a persistence model becomes even more complicated in a thread-safe environment.
Considering the challenges that the designers of C++ have faced during the past two decades, you can remain
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (17 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook - Chapter 14 - Concluding Remarks and Future Directions
optimistic. If you are familiar with the prestandardized implementations of container classes, RTTI, and exception
handling of several well known frameworks, you are probably aware of how the standardized container classes,
RTTI, and exception handling are much better in every way. This will also be the case if any of the features that are
discussed here become part of the C++ Standard.
Contents
© Copyright 1999, Macmillan Computer Publishing. All rights reserved.
file:///D|/Cool Stuff/old/ftp/1/1/ch14/ch14.htm (18 von 18) [12.05.2000 14:46:48]
ANSI/ISO C++ Professional Programmer's Handbook -- Copyright 1999
ANSI/ISO C++ Professional
Programmer's Handbook
Printed Book Copyright
©Copyright 1999, by Que
All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted
by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission
from the publisher. No patent liability is assumed with respect to the use of the information contained
herein. Although every precaution has been taken in the preparation of this book, the publisher and
author assume no responsibility for errors or omissions. Neither is any liability assumed for damages
resulting from the use of the information contained herein.
International Standard Book Number: 0-7897-2022-1
Library of Congress Catalog Card Number: 99-62146 [ Pobierz całość w formacie PDF ]