Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
pg:172-176.PartA.Interface Design Alternatives, Stroustrup-CPL-3E
19 views
Skip to first unread message
paleywiener
Mar 11, 2012, 12:47:59 PM3/11/12
to
Hi, I don't follow what Stroustrup is saying in pages: 172-176.
I've divided my lack of understanding into sections. This is the
first in a series of questions. If there are other newbies out
there who had difficulty with this section, feel free to just spell
out the whole thing - based on the presumption that great minds think
alike. Anyway, here goes:
On Page 172, why does Stroustrup say:
"compiler doesn't have sufficient information to check the
consistency
of the two definitions of the namespace"
My understanding of that page is this:
He's sticking:
namespace Parser { //interface for users
double expr(bool)
}
in Eg: user.h
and
namespace Parser { //interface for implementers
double prim(bool);
double term(bool);
double expr(bool);
using Lexer::get_token;
<SNIP>
}
in Eg: implementer.h
Now, within parse.cc(parser implementation) he just has to
#include "user.h"
#include "implementer.h"
and presto, consistency checking for both definitions of the
namespace?? Why not?
http://m-net.arbornet.org/users/zener/StroustrupCPL3E.172.png
(for those of you who'd like to view the page. just change to 172,173
etc if required)
More to follow in the next section, once I follow this..
I've divided my lack of understanding into sections. This is the
first in a series of questions. If there are other newbies out
there who had difficulty with this section, feel free to just spell
out the whole thing - based on the presumption that great minds think
alike. Anyway, here goes:
On Page 172, why does Stroustrup say:
"compiler doesn't have sufficient information to check the
consistency
of the two definitions of the namespace"
My understanding of that page is this:
He's sticking:
namespace Parser { //interface for users
double expr(bool)
}
in Eg: user.h
and
namespace Parser { //interface for implementers
double prim(bool);
double term(bool);
double expr(bool);
using Lexer::get_token;
<SNIP>
}
in Eg: implementer.h
Now, within parse.cc(parser implementation) he just has to
#include "user.h"
#include "implementer.h"
and presto, consistency checking for both definitions of the
namespace?? Why not?
http://m-net.arbornet.org/users/zener/StroustrupCPL3E.172.png
(for those of you who'd like to view the page. just change to 172,173
etc if required)
More to follow in the next section, once I follow this..
Francis Glassborow
Mar 11, 2012, 5:51:10 PM3/11/12
to
require that.
The idea is that the user of parser only needs to see the declarations
that are relevant to using it. They do not need to see the clutter of
auxiliary functions that are only useful in the implementation of the
parser.
This has advantages, one of them is that those using the parser will not
be faced with a cascade of recompilation when the implementer decides to
add some extra helper function which is only used in the implementation
of the parser.
This is pretty important in real world applications where code can cover
hundreds of files and hundreds of thousands of lines of code. It is part
of the C++ (inherited from C) design that details are separated out so
that you only need to have the details relevant to your part of the
work. The purpose of re-openable namespaces (i.e. the idea that extra
bits can be added elsewhere( is to support this separation.
Please read the paragraph on page 173 that starts 'Thi interface offered
to implementers...' I think that Bjarne Stroustrup has covered the
ground but it does require thoughtful reading. However note that this
book is not written for inexperienced programmers. It is not an
introduction to C++, it is a comptrehensive text aimed at experienced
programmers who want a reference and tutorial on heavy duty use of C++.
Ulrich Eckhardt
Mar 12, 2012, 5:49:55 AM3/12/12
to
paleywiener wrote:
> On Page 172, why does Stroustrup say:
>
> "compiler doesn't have sufficient information to check the
> consistency of the two definitions of the namespace"
>
> My understanding of that page is this:
> He's sticking:
> namespace Parser { //interface for users
> double expr(bool)
> }
> in Eg: user.h
>
> and
> namespace Parser { //interface for implementers
> double prim(bool);
> double term(bool);
> double expr(bool);
>
> using Lexer::get_token;
> <SNIP>
> }
> in Eg: implementer.h
>
> Now, within parse.cc(parser implementation) he just has to
> #include "user.h"
> #include "implementer.h"
> and presto, consistency checking for both definitions of the
> namespace?? Why not?
Yes, the implementation can and should do that, but the checking of
> On Page 172, why does Stroustrup say:
>
> "compiler doesn't have sufficient information to check the
> consistency of the two definitions of the namespace"
>
> My understanding of that page is this:
> He's sticking:
> namespace Parser { //interface for users
> double expr(bool)
> }
> in Eg: user.h
>
> and
> namespace Parser { //interface for implementers
> double prim(bool);
> double term(bool);
> double expr(bool);
>
> using Lexer::get_token;
> <SNIP>
> }
> in Eg: implementer.h
>
> Now, within parse.cc(parser implementation) he just has to
> #include "user.h"
> #include "implementer.h"
> and presto, consistency checking for both definitions of the
> namespace?? Why not?
consistency only works to a certain extent. If user.h uses things that are
not declared there, you will get a diagnostic. If you have "double
expr(bool);" declared in one place and "float expr(bool);" in another, the
compiler should also give you a diagnostic. However, if you change the
second one to "float expr(int);", then this is just an overload which is
perfectly legal C++.
Uli
paleywiener
Mar 12, 2012, 9:29:37 AM3/12/12
to
many thanks :)
paleywiener
Mar 12, 2012, 9:29:16 AM3/12/12
to
@Francis Glassborow
Hi, I'm also using the HTML version of Bruce Eckel's book: Thinking in
C++, which is excellent, and free (he's covered virtual functions in a
superb manner). I did read that section in C++PL very very carefully,
multiple times, and asked around and bugged everybody i know. Most of
it I'm following, it's just that in parts, Mr.S gets very obscure
which is quite annoying especially since what he's saying seems quite
simple! (it's annoying because there's no sense of satisfaction from
reading a book and leaving out bits - it'll be a half done kind of a
thing..)
Hi, I'm also using the HTML version of Bruce Eckel's book: Thinking in
C++, which is excellent, and free (he's covered virtual functions in a
superb manner). I did read that section in C++PL very very carefully,
multiple times, and asked around and bugged everybody i know. Most of
it I'm following, it's just that in parts, Mr.S gets very obscure
which is quite annoying especially since what he's saying seems quite
simple! (it's annoying because there's no sense of satisfaction from
reading a book and leaving out bits - it'll be a half done kind of a
thing..)
Francis Glassborow
Mar 12, 2012, 3:02:08 PM3/12/12
to
On 12/03/2012 13:29, paleywiener wrote:
> @Francis Glassborow
>
> Hi, I'm also using the HTML version of Bruce Eckel's book: Thinking in
> C++, which is excellent, and free (he's covered virtual functions in a
> superb manner). I did read that section in C++PL very very carefully,
> multiple times, and asked around and bugged everybody i know.
I think you missed the significance of 'Had this interface been for a
> @Francis Glassborow
>
> Hi, I'm also using the HTML version of Bruce Eckel's book: Thinking in
> C++, which is excellent, and free (he's covered virtual functions in a
> superb manner). I did read that section in C++PL very very carefully,
> multiple times, and asked around and bugged everybody i know.
realistically-sized module in a real system...'
Most of
> it I'm following, it's just that in parts, Mr.S gets very obscure
> which is quite annoying especially since what he's saying seems quite
> simple! (it's annoying because there's no sense of satisfaction from
> reading a book and leaving out bits - it'll be a half done kind of a
> thing..)
OK, but that suggests that the people you talked with are also not in
> it I'm following, it's just that in parts, Mr.S gets very obscure
> which is quite annoying especially since what he's saying seems quite
> simple! (it's annoying because there's no sense of satisfaction from
> reading a book and leaving out bits - it'll be a half done kind of a
> thing..)
the target readership. The book is aimed at experienced programmers. In
that context the idea of alternative interfaces for different people is
not a strange idea and the benefits of avoiding a cascade of
recompilation would be understood implicitly.
It is too long to quote here but read the last paragraph of the preface
(the one just before the acknowledgements) and it may help you
understand who the book is written for.
For learning C++, a book such as the C++ Primer 4th edition (Lippman,
Lajoie and Moo) is, IMO, a better choice.
Francis Glassborow
Mar 12, 2012, 3:08:43 PM3/12/12
to
is very specifically writing about the utility of having interfaces that
are restricted to the needs of a programmer. In the example he is
dealing with the needs of a user of a parser versus the needs of the
programmer implementing it.
As he comments in the book, in a real world instance implementers may be
modifying their side quite frequently even though the user interface is
stable and rarely, if ever changes. The point he is addressing is the
way that re-openable namespaces help the users code by avoiding a
compilation cascade when an implementer adds to or tweaks the
implementation side code.
Francis
0 new messages