Bob Bell wrote:

> Steven T. Hatton wrote:

> What has that got to do with C++?

Much. For one thing, the information structure may not be hierarchically
organized if we art talking about C++ code.  If there is an extensive use
of macros, the adjective "organized" is likely to be inaccurate. With
#defines and #includes, changing one value which could be determined by
anything from a patch version for a seemingly unrelated program, to a
compiler option, the entire structure of a translation unit can be
significantly altered.  One cannot simply look at the current context and
understand what the code in front of him or her means.  Even knowing what a
macro /can/ be expanded to doesn't tell you /what/ it will be expanded to.

Resolving such questions takes (wastes) time.  It is not uncommon that
trying to read code written in Cpp, and called C++, requires learning an
entirely new unstructured programming language.

> So you were searching a code base using a tool that was poorly suited
> for the job. How does that support the idea that C++ needs to be
> changed?

It's not a question of whether I can find the source of the non-returning
branch.  I can find it.  The problem is that it exists in the first place.
Read the final paragraph in D&E.

> I don't see the connection between difficulties associated with using a
> web browser to browse code and the idea that use of the preprocessor
> can lead to problems; would the situation be any different if you were
> using a web browser to find an overload of a function? A template
> specialization? A class definition? A free function?

AAMOF, yes, such things are _far_ easier to find and evaluate with, for
example, doxygen output.  I've taken to running Doxygen on all libraries I
happen to be using.  The documentation at the following link is far from
perfect, but it does show the usefulness of the tool

http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/

For the most part, I actually prefer my own Doxygen generated output run
against code representing the declarations in Standard Library to any of
the online documentation of the Standad Library I've seen elswhere.  It has
virtually no commenting.  The infomation it provides is extracted directly
from the source code.

> Don't get me wrong; I'm all for seeing the preprocessor improve. But I
> don't think it's very realistic to hope that it will go away, or be
> replaced by something "better". For one thing, it's just too useful;
> for some of the things it does, there just isn't any better solution.
> (If you haven't already, stop by www.boost.org and have a look at the
> preprocessor metaprogramming library.)

I wasn't blown away by what I saw.  My instincts tell me there are better
ways of accomplishing the same things.

> As for 1), I don't have an answer for it, and in fact I agree with you;
> the preprocessor needs to be used carefully. As for 2), C++ has gone to
> great lengths to provide alternatives to the preprocessor.

I have to confess, I had never considered macro exclusion as a possible
benefit to introducing modules to C++ until I saw Daveed's proposal.  That
relates back to what I'm talking about regarding interfaces.  I didn't
start this thread in order to promote any particular concept, or design of
something called an "interface".  I just thought it would be a good thing
to discuss.

I just realized (remembered) there is another angle on how the abstract
notion of an interface relates the the problem of macros.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

> verec wrote:
>> In other words, tools can only go as far as providing you with
>> information that is *already there* albeit in a non very friendly
>> form, but cannot do much to synthetize out of thin air what isn't.
>
> What information do you think isn't there in a code base that would
> have to be synthesized out of thin air?
>
> Bob
>

Take a look at this:

http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm

I challenge you to write comperable C++.  I also trust the same can be done
with C#, and probably C++/CLI.  I'm not suggesting that C++ should try to
provide all of what the JVM or the CLI will provide, but I am suggesting
these new technologies are worth being aware of when considering
modification or extension to C++.  IMO, the best way to accomplish that
sort of thing with C++ is in ways that do not impact the final compiled
output.  I will even acknowledge that text manipulation such as is
performed by the CPP could have a role in this kind of thing.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:rqGdnQMP2sP3FnXfRVn-qg@speakeasy.net...
.
>> What information do you think isn't there in a code base that would
>> have to be synthesized out of thin air?
>>
>> Bob
>>
>
> Take a look at this:
>
> http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm
>
> I challenge you to write comperable C++.  I also trust the same can be
> done
> with C#, and probably C++/CLI.  I'm not suggesting that C++ should try to
> provide all of what the JVM or the CLI will provide, but I am suggesting
> these new technologies are worth being aware of when considering
> modification or extension to C++.  IMO, the best way to accomplish that
> sort of thing with C++ is in ways that do not impact the final compiled
> output.  I will even acknowledge that text manipulation such as is
> performed by the CPP could have a role in this kind of thing.

I don't know why you say it's impossible to have comparable class browser in
c++. Unless you have something specific in mind I didn't notice from the
example you provided anything that a regular "Class View" and "Object
Browser" in MSVC IDE cannot do. In fact they give much more information and
offer more flexibility in a more palatable way. So much so, that doxigen
doesn't add anything valuable to it.
CPP is a messy side of C++, but your project doesn't have to be. There are a
few legitimate uses of preprocessor that do not create any difficulties,
like include guards, simple debug macros. It's mostly the result of poor
design skills that leads to convoluted macro use. C++ unlike other languages
alows a lot of latitude for developers, but it doesn't mean if you have a
rifle you have to shoot yourself in the foot.

- gene

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> Bob Bell wrote:
>
> > Steven T. Hatton wrote:
>
> > What has that got to do with C++?
>
> Much. For one thing, the information structure may not be hierarchically
> organized if we art talking about C++ code.  If there is an extensive use
> of macros, the adjective "organized" is likely to be inaccurate. With
> #defines and #includes, changing one value which could be determined by
> anything from a patch version for a seemingly unrelated program, to a
> compiler option, the entire structure of a translation unit can be
> significantly altered.  One cannot simply look at the current context and
> understand what the code in front of him or her means.  Even knowing what a
> macro /can/ be expanded to doesn't tell you /what/ it will be expanded to.
>
> Resolving such questions takes (wastes) time.  It is not uncommon that
> trying to read code written in Cpp, and called C++, requires learning an
> entirely new unstructured programming language.

Hmm. I asked about using a web browser to search for information in a
set of web pages and what that says about C++, but your reply doesn't
seem to have anything to do with the question.

> > So you were searching a code base using a tool that was poorly suited
> > for the job. How does that support the idea that C++ needs to be
> > changed?
>
> It's not a question of whether I can find the source of the non-returning
> branch.

(non-returning branch?)

Then why did you ask:

> ...what happens when you are
> examining an SVN repository with a web browser?

> > I don't see the connection between difficulties associated with using a
> > web browser to browse code and the idea that use of the preprocessor
> > can lead to problems; would the situation be any different if you were
> > using a web browser to find an overload of a function? A template
> > specialization? A class definition? A free function?
>
> AAMOF, yes, such things are _far_ easier to find and evaluate with, for
> example, doxygen output.

I didn't ask whether it would be easier to use doxygen to find those
things; I asked about a web browser. Your complaint was about using a
web browser to search a code base. I still don't see what the
deficiencies of using a web browser to search a code base tells us
about the deficiencies of the preprocessor.

> I've taken to running Doxygen on all libraries I
> happen to be using.

If anything, doxygen helps demonstrate my point; it's a tool. It's far
from a perfect tool, but it illustrates my point: that it's possible to
create tools to deal with the things your talking about, rather than
change the language.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> Bob Bell wrote:
>
> > verec wrote:
> >> In other words, tools can only go as far as providing you with
> >> information that is *already there* albeit in a non very friendly
> >> form, but cannot do much to synthetize out of thin air what isn't.
> >
> > What information do you think isn't there in a code base that would
> > have to be synthesized out of thin air?
> >
> > Bob
> >
>
> Take a look at this:
>
> http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm
>
> I challenge you to write comperable C++.  I also trust the same can be done
> with C#, and probably C++/CLI.  I'm not suggesting that C++ should try to
> provide all of what the JVM or the CLI will provide, but I am suggesting
> these new technologies are worth being aware of when considering
> modification or extension to C++.  IMO, the best way to accomplish that
> sort of thing with C++ is in ways that do not impact the final compiled
> output.  I will even acknowledge that text manipulation such as is
> performed by the CPP could have a role in this kind of thing.

I don't have any idea what this has to do with the question I asked. I
don't even know what the point is. Are you saying that the example code
on that page is an example of amazing Java code that could only be
reproduced in C++ with great difficulty? Are you saying that the
example code web page, with the nice picture at the top and all the
links to other examples, somehow shows that C++ is deficient in some
way? I really don't understand your point at all.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> Bob Bell wrote:
.
> > What information do you think isn't there in a code base that would
> > have to be synthesized out of thin air?
> >
> > Bob
> >
>
> Take a look at this:
>
> http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm
>
> I challenge you to write comperable C++.  I also trust the same can be done

You're being too vague, again. Try to be more specific. It's a big
program, with a lot of capabilities. Which ones are you thinking of,
specifically?

Writing [a?] comparable [program for?] C++ would be a big task, and of
course it would never have exactly the same functionality; even if C++
were better in every possible way from java, and even if C++lassBrowser
were better in every way than ClassBrowser, it wouldn't perform exactly
the same tasks. So the question is, what are the differences that are
relevant to your claim?

If you're certain it can't be done, there must be many different
specific and valuable capabilities of ClassBrowser that you think can't
be provided for C++ code, using the lanuage as it's currently defined.
Could you please identify just one of those capabilities, so we have
some idea what you're talking about.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:

> Steven T. Hatton wrote:
>> Bob Bell wrote:
> .
>> > What information do you think isn't there in a code base that would
>> > have to be synthesized out of thin air?
>> >
>> > Bob
>> >
>>
>> Take a look at this:
>>
>> http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm
>>
>> I challenge you to write comperable C++.  I also trust the same can be
>> done
>
> You're being too vague, again. Try to be more specific. It's a big
> program, with a lot of capabilities. Which ones are you thinking of,
> specifically?

Do you really thing that's a big program?  I condirer it tiny.  That last
two methods demonstrate the core principle being exhibited

> Writing [a?] comparable [program for?] C++ would be a big task, and of
> course it would never have exactly the same functionality; even if C++
> were better in every possible way from java, and even if C++lassBrowser
> were better in every way than ClassBrowser, it wouldn't perform exactly
> the same tasks. So the question is, what are the differences that are
> relevant to your claim?

What claim?  I'm not aware of having made any claim.

> If you're certain it can't be done, there must be many different
> specific and valuable capabilities of ClassBrowser that you think can't
> be provided for C++ code, using the lanuage as it's currently defined.
> Could you please identify just one of those capabilities, so we have
> some idea what you're talking about.

The word I used was comperable, not identical.  Having spent some time
working on a comperable C++ application, I am very certain it is a
non-trivial undertaking.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

> "Steven T. Hatton" wrote:
>> Bob Bell wrote:

> Hmm. I asked about using a web browser to search for information in a
> set of web pages and what that says about C++, but your reply doesn't
> seem to have anything to do with the question.

The reasoning was implicit.  Regardless of the tool, the structure of the
program matters.  I don't believe there is any fundamental problem with
using such tools as lxr, Doxygen.  If I failed to provide that answer you
wanted, or expected, that is probably because I don't accept the premiss
from which you formulated the question.


> Then why did you ask:

For obvious reasons.

>> AAMOF, yes, such things are _far_ easier to find and evaluate with, for
>> example, doxygen output.
>
> I didn't ask whether it would be easier to use doxygen to find those
> things; I asked about a web browser. Your complaint was about using a
> web browser to search a code base. I still don't see what the
> deficiencies of using a web browser to search a code base tells us
> about the deficiencies of the preprocessor.

My observation was about the general nature of finding information.  I have
no idea if your tools do what you assert they do.  I have no way to find
out.  My experience has been that the reality often exceeds the description
when people tell me they have a tool that solves all the problems I
mention.

>> I've taken to running Doxygen on all libraries I
>> happen to be using.
>
> If anything, doxygen helps demonstrate my point; it's a tool. It's far
> from a perfect tool, but it illustrates my point: that it's possible to
> create tools to deal with the things your talking about, rather than
> change the language.

Regardless of whether there are tools to find information within a poorly
structured information base, the fact remains that such disorganization
will lead to inefficiency in by programmer productivity, and program
execution.  Having participated in the development of the kinds of tools
you are talking about, I know that there are significant problems produced
by unstructured use of C++.

My reasons for discussion the general topic of interfaces are multifold.
One of the primary reasons is because I see C++ being replaced in areas
where it should be virtually unchallenged.  I suspect it is possible to add
certain features which would both add useful functionality in their own
right, and support the practices of structured programming.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:96udnaThdd8_KXTfRVn-1Q@speakeasy.net...
.
> My observation was about the general nature of finding information.  I
> have
> no idea if your tools do what you assert they do.  I have no way to find
> out.

Oh, yes, you have. It's not all happening in the corner, you know. Here is
just one example http://lab.msdn.microsoft.com/express/visualc/default.aspx
. Grab a free copy and experiment with it. I think you will find Class View
and Object Browser have all the information you may want. "Goto Definition"
and "Goto Declaration" and other navigation features make all the problems
you mentioned non-existent. Cpp macros, etc. still present a big challenge
for the reader to understand and unravel the spaghetti, but it's not a
challenge for development tools.
.
> My reasons for discussion the general topic of interfaces are multifold.
> One of the primary reasons is because I see C++ being replaced in areas
> where it should be virtually unchallenged.  I suspect it is possible to
> add
> certain features which would both add useful functionality in their own
> right, and support the practices of structured programming.

I agree that well defined interfaces may improve the quality of the design,
ease of reading, reduce errors, but they may only marginally improve the
abilities of the development tools to provide pertinent information or
increase compilation speed or produce faster code.

- gene

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> Bob Bell wrote:
>
> > "Steven T. Hatton" wrote:
> >> Bob Bell wrote:
>
> > Hmm. I asked about using a web browser to search for information in a
> > set of web pages and what that says about C++, but your reply doesn't
> > seem to have anything to do with the question.
>
> The reasoning was implicit.  Regardless of the tool, the structure of the
> program matters.  I don't believe there is any fundamental problem with
> using such tools as lxr, Doxygen.  If I failed to provide that answer you
> wanted, or expected, that is probably because I don't accept the premiss
> from which you formulated the question.

My premise was that a web browser is an inappropriate tool for
searching a C++ code base. Is that the premise you don't accept, or do
you mean something else?

I've gone back and reread what you wrote on this topic several times
now, trying to see if I've missed something. But it looks like you
said:

-- I used a web browser to examine an SVN repository of C++ code,
looking for something
-- it was hard
-- therefore, there's something wrong with C++

This seems entirely unreasonable to me. I've tried to question you
about it to see if that is indeed what you meant, but at this point, I
can't tell if you're dissembling or if there really is some
misunderstanding on my part.

> > Then why did you ask:
>
> For obvious reasons.

If they were obvious reasons, I wouldn't have asked why. Perhaps you
should be more explicit instead of expecting me to read your mind.

> >> AAMOF, yes, such things are _far_ easier to find and evaluate with, for
> >> example, doxygen output.
> >
> > I didn't ask whether it would be easier to use doxygen to find those
> > things; I asked about a web browser. Your complaint was about using a
> > web browser to search a code base. I still don't see what the
> > deficiencies of using a web browser to search a code base tells us
> > about the deficiencies of the preprocessor.
>
> My observation was about the general nature of finding information.  I have
> no idea if your tools do what you assert they do.  I have no way to find
> out.

What stops you from getting ahold of the tool and trying it out?

> My experience has been that the reality often exceeds the description
> when people tell me they have a tool that solves all the problems I
> mention.

Then I'm afraid I'm not one of those people; I never said I have a tool
that solves all the problems you mention. You would be justified in
your skepticism if I had.

This whole subthread started because I disagreed with your claim that a
C++ source base cannot be searched deterministically or effectively. I
pointed out at least one tool that does quite a good job at it. (Note:
not a perfect job, and not a job that solves all of your problems.) If
you don't want to accept that, there's nothing I can do about it. Your
points about the preprocessor are taken, but don't really invalidate my
point. If you think they do, perhaps you have misunderstood what I'm
saying.

There's nothing that stops the compiler (including the preprocessor)
from emitting any data it wants that describes which definitions of
what programming entities are used where. The Metrowerks IDE does this.
That means that after a compile I can do things like right-click on the
name of a class, function, or macro and be taken to the corresponding
definition. You can have multiple targets, each with a different set of
predefined macro definitions implying totally different conditional
compilation branches. And in each target, right-clicking on the name of
something takes me to the right place, taking into account all of the
conditional compilation of that branch.

All of this can be done today with the existing language definition;
Metrowerks (and others) has done these kinds of things for years.

If you still think that changing the language is a better approach,
consider that a new version of the standard isn't likely for 4 or 5
years. Assuming you succeed in getting everything you think C++ needs
into the standard, how many more years after that do you think you'll
have to wait before seeing it all implemented?

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> kuyper@wizard.net wrote:
>
> > Steven T. Hatton wrote:
> >> Bob Bell wrote:
> > .
> >> > What information do you think isn't there in a code base that would
> >> > have to be synthesized out of thin air?
> >> >
> >> > Bob
> >> >
> >>
> >> Take a look at this:
> >>
> >> http://www.java2s.com/ExampleCode/Swing-JFC/ClassBrowser.htm
> >>
> >> I challenge you to write comperable C++.  I also trust the same can be
> >> done
> >
> > You're being too vague, again. Try to be more specific. It's a big
> > program, with a lot of capabilities. Which ones are you thinking of,
> > specifically?
>
> Do you really thing that's a big program?  I condirer it tiny.  That last
> two methods demonstrate the core principle being exhibited

I'm sorry. At the time I wrote that message I hadn't looked at it
closely yet. When you don't bother being sufficiently specific about
what you're point is, it's hard for me to justify the time needed to
figure out what it is you've failed to specify.

When you suggested that it was doing something that would be difficult
or impossible to do in C++, I just assumed it was big and complicated.
Could you please identify the core principle that you're referring to,
and what makes it difficulat or impossible to implement for C++ code?

> > Writing [a?] comparable [program for?] C++ would be a big task, and of
> > course it would never have exactly the same functionality; even if C++
> > were better in every possible way from java, and even if C++lassBrowser
> > were better in every way than ClassBrowser, it wouldn't perform exactly
> > the same tasks. So the question is, what are the differences that are
> > relevant to your claim?
>
> What claim?  I'm not aware of having made any claim.

The claim that you made which led down to this point was:

> Of course these features are used extensively.  Nonetheless, because the
> Java source code is more coherently organized by specification (or at least
> recommendation and convention), and also because Java specifies a great
> many infrastructure mechanism to facilitate locating resources, the Java
> resource base can be searched much more effectively and deterministically
> than can a C++ code base.

Bob Bell disagreed with that assertion, saying that doing the same
thing for C++ is just a matter of building the right tool; no changes
to C++ are needed to make the searching just as effective and
deterministic as it is for java.

Verec pointed out, correctly, that a tool can't make use of information
that isn't there. In context, by making that statement, he was implying
that C++ fails to provide some of the relevant information that java
does provide. This is really the claim that I was thinking about; but
it wasn't your claim, so I apologize for making that misattribution. On
the other hand, that claim seems to underlie the other things you have
said, so I think it's a claim you would support; am I wrong?

Bob Bell asked Verc to identify the missing information.

You responded by pointing to a java tool which you challenged us to
duplicate in C++. You failed to identify what feature the tool
possesses that you think would make it difficult to write comparable
C++ code, or why pointing at such a tool could be considered as
constituting an answer to Bob Bell's question.

> The word I used was comperable, not identical.  Having spent some time
> working on a comperable C++ application, I am very certain it is a
> non-trivial undertaking.

Then you should be in an excellent position to explain what features
C++ possesses, or fails to possess, that make it a non-trivial
undertaking, and why the presence (or absence) of those features has
that effect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

> "Steven T. Hatton" wrote:
>> kanze@gabi-soft.fr wrote:
>>
>> > "Steven T. Hatton" wrote:
>> >> People can argue that there are mechanisms for locating such
>> >> definitions without a great deal of effort.  It may only take
>> >> a minute. Do that 60 times, and it takes an hour.  The
>> >> arrangement of different code bases makes this more difficult
>> >> than it would be if there were a formal mechanism for
>> >> organizing resources(as in Java).
>> >
>> > I don't know.  I've found it just as difficult to locate
>> > definitions in Java as in C++.  More difficult, in fact, because
>> > the definitions are always embedded in a mess of implementation
>> > details.
>>
>> With the exception of interfaces and abstract classes, Java doesn't have
>> any distinction between "declaration" and "definition" (that I can thing
>> of.)
>> Of course these features are used extensively.  Nonetheless, because the
>> Java source code is more coherently organized by specification (or at
>> least recommendation and convention), and also because Java specifies a
>> great many infrastructure mechanism to facilitate locating resources, the
>> Java resource base can be searched much more effectively and
>> deterministically than can a C++ code base.
>
> As far as I can tell, this simply isn't true; at least, searching for
> definitions in a C++ code base does not have to be inefficient or
> non-deterministic. Modern IDEs accomplish this quite handily; the
> Metrowerks IDE can quickly take me to the definitions of macros,
> functions, classes, typedefs, etc.
>
> In other words, the ability to search a code base is a tools issue, not
> a language issue.
>
> Bob

Well, my original reply seems to have gone too far off topic for the
moderators to accept, so here's the best response I can give.  It was
included in my original reply.  I'm hoping this is topical enough.

Please see this article titled "An empirical analysis of C preprocessor
use":

http://pag.csail.mit.edu/~mernst/pubs/c-preprocessor-tse2002-abstract.html

"Abstract:
This is the first empirical study of the use of the C macro preprocessor,
Cpp. To determine how the preprocessor is used in practice, this paper
analyzes 26 packages comprising 1.4 million lines of publicly available C
code. We determine the incidence of C preprocessor usage ? whether in macro
definitions, macro uses, or dependences upon macros ? that is complex,
potentially problematic, or inexpressible in terms of other C or C++
language features. We taxonomize these various aspects of preprocessor use
and particularly note data that are material to the development of tools
for C or C++, including translating from C to C++ to reduce preprocessor
usage. Our results show that while most Cpp usage follows fairly simple
patterns, an effective program analysis tool must address the preprocessor.

"The intimate connection between the C programming language and Cpp, and
Cpp's unstructured transformations of token streams, often hinder
programmer understanding of C programs and tools built to engineer C
programs, such as compilers, debuggers, call graph extractors, and
translators. Most tools make no attempt to analyze macro usage, but simply
preprocess their input, which results in a number of negative consequences;
an analysis that takes Cpp into account is preferable, but building such
tools requires an understanding of actual usage. Differences between the
semantics of Cpp and those of C can lead to subtle bugs stemming from the
use of the preprocessor, but there are no previous reports of the
prevalence of such errors. Use of C++ can reduce some preprocessor usage,
but such usage has not been previously measured. Our data and analyses shed
light on these issues and others related to practical understanding or
manipulation of real C programs. The results are of interest to language
designers, tool writers, programmers, and software engineers. "

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:
> "Steven T. Hatton" wrote:
>
>>kanze@gabi-soft.fr wrote:
>>
>>
>>>"Steven T. Hatton" wrote:
>>>
>>>>People can argue that there are mechanisms for locating such
>>>>definitions without a great deal of effort.  It may only take
>>>>a minute. Do that 60 times, and it takes an hour.  The
>>>>arrangement of different code bases makes this more difficult
>>>>than it would be if there were a formal mechanism for
>>>>organizing resources(as in Java).
>>>
>>>I don't know.  I've found it just as difficult to locate
>>>definitions in Java as in C++.  More difficult, in fact, because
>>>the definitions are always embedded in a mess of implementation
>>>details.
>>
>>With the exception of interfaces and abstract classes, Java doesn't have any
>>distinction between "declaration" and "definition" (that I can thing of.)
>>Of course these features are used extensively.  Nonetheless, because the
>>Java source code is more coherently organized by specification (or at least
>>recommendation and convention), and also because Java specifies a great
>>many infrastructure mechanism to facilitate locating resources, the Java
>>resource base can be searched much more effectively and deterministically
>>than can a C++ code base.
>
>
> As far as I can tell, this simply isn't true; at least, searching for
> definitions in a C++ code base does not have to be inefficient or
> non-deterministic. Modern IDEs accomplish this quite handily; the
> Metrowerks IDE can quickly take me to the definitions of macros,
> functions, classes, typedefs, etc.
>
I would be very interested to know what would happen if you tried to
feed Metrowerks some evil C++, like say Boost's metatemplate programming
library :)

Also, while it's easy to find the "base definition" of a template, I can
imagine it would be hard if not impossible for an IDE to show you the
"correct" template overload for a particular situation.

I'm not saying C++ shouldn't support these things, but it makes it very
hard to write anything in an IDE which doesn't have to use heuristics to
some degree.

Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

chris jefferson wrote:
> Bob Bell wrote:
> > As far as I can tell, this simply isn't true; at least, searching for
> > definitions in a C++ code base does not have to be inefficient or
> > non-deterministic. Modern IDEs accomplish this quite handily; the
> > Metrowerks IDE can quickly take me to the definitions of macros,
> > functions, classes, typedefs, etc.
> >
> I would be very interested to know what would happen if you tried to
> feed Metrowerks some evil C++, like say Boost's metatemplate programming
> library :)
>
> Also, while it's easy to find the "base definition" of a template, I can
> imagine it would be hard if not impossible for an IDE to show you the
> "correct" template overload for a particular situation.

Just like it's hard but not impossible to show the correct function
overload.

> I'm not saying C++ shouldn't support these things, but it makes it very
> hard to write anything in an IDE which doesn't have to use heuristics to
> some degree.

The more information the IDE can get from the compiler, the less it has
to rely on heuristics. When compiling a piece of text, the compiler can
feed any information it wants back to the IDE, such as which template
instantiation is actually used at a particular place in the code.

Whether any compiler/IDE actually goes that far is a different
question. My point is that there is nothing about the language
definition that precludes this sort of interaction; tools can be
written to address this needs. One may argue that tools of this sort
are hard to create, and that's fair; they _are_ hard.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
>
> I'm wondering if there would be any advantage in attempting to formalize the
> notion of an interface as it relates to the #include directive.  I'm
> thinking that something along the lines of the OMG's IDL might serve as a
> starting point in designing such a feature.  I acknowledge that it might
> also serve as an example of why such a feature should *not* be introduced
> into C++.  One thing that is not clear to me is /what/, exactly, the term
> "interface" should mean in C++.  Is there any potential practical advantage
> to introducing a formal language construct called an "interface"?  What
> would that construct consist of?

C++ implementations of Microsoft's COM model do this successfully.
The interfaces are written in IDL. The interface importer program
converts this into a bunch of header files containing ABCs (abstract
base classes), one for each interface.

When you want to design a class implementing those interfaces, you
simply multiply derive from those ABCs.

IMHO, C++ is flexible enough to allow good implementation/interface
separation already. But it does not try and shove programming
principles down the coder's throat like Java does.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

> chris jefferson wrote:
[...]
>> Also, while it's easy to find the "base definition" of a template, I can
>> imagine it would be hard if not impossible for an IDE to show you the
>> "correct" template overload for a particular situation.
>
> Just like it's hard but not impossible to show the correct function
> overload.

There are some limitations to what can be done with templates, that are not
encountered in more concrete code.  Try to get the IDE to find a list of
"pure abstractions" of some template related behavior or structure.  I see
templates moving toward a formalization of what I call meta-types. The same
kinds of problems that led to the creation of strong typing in the first
place, are now presenting themselves at the next higher level of
abstraction.

>> I'm not saying C++ shouldn't support these things, but it makes it very
>> hard to write anything in an IDE which doesn't have to use heuristics to
>> some degree.
>
> The more information the IDE can get from the compiler, the less it has
> to rely on heuristics. When compiling a piece of text, the compiler can
> feed any information it wants back to the IDE, such as which template
> instantiation is actually used at a particular place in the code.
>
> Whether any compiler/IDE actually goes that far is a different
> question.

I'm not completely sure what you mean here, but KDevelop certainly uses the
object code, and/or, intermediate code to provide some of this code
completion and error detection.  Tools such a JBuilder are clearly doing
this same kind of thing with Java.  For example, certain error detection
features only work after part of the code is compiled, or fail to adapt
immediately to changes made in the the source.

> My point is that there is nothing about the language
> definition that precludes this sort of interaction; tools can be
> written to address this needs. One may argue that tools of this sort
> are hard to create, and that's fair; they _are_ hard.

In many cases the things we want an IDE to do for us are things we would
otherwise do by hand.  I'm convinced that something that is difficult to
automate is usually difficult to accomplish in the first place.

I know in my experience with C++, most of my time is spent dealing with
preprocessor, or linking related problems.  The amount of time I've spent
actually writing code is less than the time I've spent on problems related
to file name extensions, arcane and obscure preprocessor definition
conflicts, and simple preprocessor macro demangling.  You can say your IDE
will automate the location of #defines, but what happens when you are
examining an SVN repository with a web browser?  This is something that
came up just yesterday for me.  I was looking at code that had the
namespaces #defined.  Other than brute force searches, and lucky guessing,
there is no way to properly understand the code you're looking at.

The particular code base I'm talking about is one of the best organized C++
projects I've seen.  There are places where things are far worse.  Many of
the worst examples of deranged C++ project and program structure are really
badly written C programs with some C++ classes mixed in.  This is not to
say C projects cannot be well organized and coherent.  I'm currently
studying the libelf package.  For the most part, it seems quite well
organized, and doesn't go too far into the typical C macro madness.

The degree to which the Cpp is used to undermine the good order of C++ is
one of the primary motivations I have for exploring different possible
language directions.  Two things need to happen. 1) People need to become
aware that Cpp programming really does cause problems.  2) alternatives
need to be provided so that the bad practices can be replaced with better
ones.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:
> Bob Bell wrote:
> > My point is that there is nothing about the language
> > definition that precludes this sort of interaction; tools can be
> > written to address this needs. One may argue that tools of this sort
> > are hard to create, and that's fair; they _are_ hard.
>
> In many cases the things we want an IDE to do for us are things we would
> otherwise do by hand.  I'm convinced that something that is difficult to
> automate is usually difficult to accomplish in the first place.
>
> I know in my experience with C++, most of my time is spent dealing with
> preprocessor, or linking related problems.  The amount of time I've spent
> actually writing code is less than the time I've spent on problems related
> to file name extensions, arcane and obscure preprocessor definition
> conflicts, and simple preprocessor macro demangling.  You can say your IDE
> will automate the location of #defines, but what happens when you are
> examining an SVN repository with a web browser?

Let me see if I can rephrase the question: "What happens if you're
using a web browser to peruse a large number of hierarchically
organized web pages, looking for some piece of information you know is
on one of the pages?" Unless the web pages have some kind of search
functionality built in to them, your only resort is brute force
searches and lucky guessing.

What has that got to do with C++?

> This is something that
> came up just yesterday for me.  I was looking at code that had the
> namespaces #defined.  Other than brute force searches, and lucky guessing,
> there is no way to properly understand the code you're looking at.
> The particular code base I'm talking about is one of the best organized C++
> projects I've seen.

So you were searching a code base using a tool that was poorly suited
for the job. How does that support the idea that C++ needs to be
changed?

I don't see the connection between difficulties associated with using a
web browser to browse code and the idea that use of the preprocessor
can lead to problems; would the situation be any different if you were
using a web browser to find an overload of a function? A template
specialization? A class definition? A free function?

> There are places where things are far worse.  Many of
> the worst examples of deranged C++ project and program structure are really
> badly written C programs with some C++ classes mixed in.  This is not to
> say C projects cannot be well organized and coherent.  I'm currently
> studying the libelf package.  For the most part, it seems quite well
> organized, and doesn't go too far into the typical C macro madness.
>
> The degree to which the Cpp is used to undermine the good order of C++ is
> one of the primary motivations I have for exploring different possible
> language directions.  Two things need to happen. 1) People need to become
> aware that Cpp programming really does cause problems.  2) alternatives
> need to be provided so that the bad practices can be replaced with better
> ones.

Don't get me wrong; I'm all for seeing the preprocessor improve. But I
don't think it's very realistic to hope that it will go away, or be
replaced by something "better". For one thing, it's just too useful;
for some of the things it does, there just isn't any better solution.
(If you haven't already, stop by www.boost.org and have a look at the
preprocessor metaprogramming library.)

As for 1), I don't have an answer for it, and in fact I agree with you;
the preprocessor needs to be used carefully. As for 2), C++ has gone to
great lengths to provide alternatives to the preprocessor.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> The degree to which the Cpp is used to undermine the good order of
> C++ is one of the primary motivations I have for exploring different
> possible language directions.  Two things need to happen. 1) People
> need to become aware that Cpp programming really does cause problems.

No.  You (and others) need to be aware that there are various ways that the
preprocessor can be used, and that some of them are good and some of them are
bad.  This is exactly the same scenario as in the underlying language (and in
all languages for that matter).  It is not the preprocessor that causes
problems, it is *some* of the ways that it is used.  In other words, you're
taking the lazy road by making broad generalizations (which are not generally
correct) instead of nailing down specific classes of usage that cause problems.

Regards,
Paul Mensonides


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-07-25 20:13:37 +0100, "Bob Bell" <belvis@pacbell.net> said:

>> With the exception of interfaces and abstract classes, Java doesn't have any
>> distinction between "declaration" and "definition" (that I can thing of.)
>> Of course these features are used extensively.  Nonetheless, because the
>> Java source code is more coherently organized by specification (or at least
>> recommendation and convention), and also because Java specifies a great
>> many infrastructure mechanism to facilitate locating resources, the Java
>> resource base can be searched much more effectively and deterministically
>> than can a C++ code base.
>
> As far as I can tell, this simply isn't true; at least, searching for
> definitions in a C++ code base does not have to be inefficient or
> non-deterministic. Modern IDEs accomplish this quite handily; the
> Metrowerks IDE can quickly take me to the definitions of macros,
> functions, classes, typedefs, etc.

And allows you to
- browse by (possibly nested) namespaces ?
- browse by containment (X's contain Y's that contain Z's ...) ?
- browse by call chain (AKA sequence diagrams) ?
- browse by template specialization ?

> In other words, the ability to search a code base is a tools issue, not
> a language issue.

That's a tool issue ... too. But if the language provides some help
for tool implementors, that can't be a nuisance, can it?

Like the fact that, in real life, Java does provide, in its class files
a ready to use (modulo some not too hard to overcome technicalities :)
symbol table for each class whereas, in the C++ world, the said symbol
table is only transient _while the compiler runs_ and totally absent
otherwise.

Like the fact that, being designed for large scale, Java has been
modularized, categorized and organized into dozens of packages (java.io
java,lang, java.net, java,util, etc...) whereas the best C++ could
agree to standardize was .... namespace std ...

In other words, tools can only go as far as providing you with
information that is *already there* albeit in a non very friendly
form, but cannot do much to synthetize out of thin air what isn't.
--
JFB

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul Mensonides wrote:

> Steven T. Hatton wrote:
>
>> The degree to which the Cpp is used to undermine the good order of
>> C++ is one of the primary motivations I have for exploring different
>> possible language directions.  Two things need to happen. 1) People
>> need to become aware that Cpp programming really does cause problems.
>
> No.  You (and others) need to be aware that there are various ways that
> the preprocessor can be used, and that some of them are good and some of
> them are
> bad.  This is exactly the same scenario as in the underlying language (and
> in
> all languages for that matter).  It is not the preprocessor that causes
> problems, it is *some* of the ways that it is used.  In other words,
> you're taking the lazy road by making broad generalizations (which are not
> generally correct) instead of nailing down specific classes of usage that
> cause problems.
>
> Regards,
> Paul Mensonides
>
Consider the following:

Go To Statement Considered Harmful
Edsger W. Dijkstra

http://www.acm.org/classics/oct95/

$ pwd
/download/edu/stanford/cweb
$ grep goto * | wc -l
89
grep Knuth * | wc -l
45
$ cd /usr/src/linux/kernel
$ grep goto * | wc -l
291

As I've alread stated, the CPP constructs are analogous to a goto statement.
As you can see above, some programmers who are highly regarded, /do/ use
the goto construct.  But it has fortunately been banished from the realm of
everyday code.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

verec wrote:
> In other words, tools can only go as far as providing you with
> information that is *already there* albeit in a non very friendly
> form, but cannot do much to synthetize out of thin air what isn't.

What information do you think isn't there in a code base that would
have to be synthesized out of thin air?

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

    [...]
> I'm wondering if there would be any advantage in attempting to
> formalize the notion of an interface as it relates to the
> #include directive.  I'm thinking that something along the
> lines of the OMG's IDL might serve as a starting point in
> designing such a feature.

I think that part of the problem you perceive is purely
pragmatic.  Ideally, we'd all like to put the "interface", and
only the interface, in the header, and everything else in the
implementation files.  From the very beginning, however, C++ has
struck a pragmatic compromize -- there are very practical
reasons why class definitions must contain the specification of
the private members, even though they aren't part of the
"interface".  Similarly, "export" has a long and complex
history, due to conflicting requirements from those trying to
implement templates in a robust manner, and those trying to use
them without ending up with too many dependancies.  (The fact
that there were idiots like myself who continually opened their
big mouth when they didn't know what they were talking about
didn't help much either.)

> I acknowledge that it might also serve as an example of why
> such a feature should *not* be introduced into C++.  One thing
> that is not clear to me is /what/, exactly, the term
> "interface" should mean in C++.  Is there any potential
> practical advantage to introducing a formal language construct
> called an "interface"?  What would that construct consist of?

Personnally, I would oppose any proposal which used the key word
interface, simply because the Java (mis-)implementation of it
has caused too much confusion around it.  Other than that, I do
think that C++ would benefit by a cleaner concept of modules,
what is exported, what not, etc.  But it isn't quite obvious
what.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

> Steven T. Hatton wrote:
>
>     [...]
>> I'm wondering if there would be any advantage in attempting to
>> formalize the notion of an interface as it relates to the
>> #include directive.  I'm thinking that something along the
>> lines of the OMG's IDL might serve as a starting point in
>> designing such a feature.
>
> I think that part of the problem you perceive is purely
> pragmatic.  Ideally, we'd all like to put the "interface", and
> only the interface, in the header, and everything else in the
> implementation files.  From the very beginning, however, C++ has
> struck a pragmatic compromize -- there are very practical
> reasons why class definitions must contain the specification of
> the private members, even though they aren't part of the
> "interface".

Understood.  I believe this is so the compiler can allocate memory for the
member fields.  I'm not sure that "problem" needs to be solved for all
classes.  My objection to the #include directive is that it is external to
the language, and its behavior is not based on program structure.  One of
the most frustrating aspects of C++ is trying to figureout where some
macro, or other symbol in the current scope originated.  This is due mostly
to the nesting of #includes.

People can argue that there are mechanisms for locating such definitions
without a great deal of effort.  It may only take a minute. Do that 60
times, and it takes an hour.  The arrangement of different code bases makes
this more difficult than it would be if there were a formal mechanism for
organizing resources(as in Java).

The places where exposing internal structure to the compiler seems most
important are between "modules".  I base that comment on my understanding
of the writings of acknowledged experts, not personal experience.

> Similarly, "export" has a long and complex
> history, due to conflicting requirements from those trying to
> implement templates in a robust manner, and those trying to use
> them without ending up with too many dependancies.  (The fact
> that there were idiots like myself who continually opened their
> big mouth when they didn't know what they were talking about
> didn't help much either.)

What is attractive to me about `export' is the idea that I can treat
templates and classes in congruent ways.

>> I acknowledge that it might also serve as an example of why
>> such a feature should *not* be introduced into C++.  One thing
>> that is not clear to me is /what/, exactly, the term
>> "interface" should mean in C++.  Is there any potential
>> practical advantage to introducing a formal language construct
>> called an "interface"?  What would that construct consist of?
>
> Personnally, I would oppose any proposal which used the key word
> interface, simply because the Java (mis-)implementation of it
> has caused too much confusion around it.

What are your objections to Java's interfaces?  They are very much the same
as pure abstract base classes.

> Other than that, I do
> think that C++ would benefit by a cleaner concept of modules,
> what is exported, what not, etc.  But it isn't quite obvious
> what.

I'm thinking the topics discussed in this article have relevance to the
concepts of interface, and how they might be supported in C++

http://en.wikipedia.org/wiki/Software_library

One example where the concept of interfaces has been successfully used in
C++ development is with IBM's XPCOM.  Part of using XPCOM involves an OMG
IDL-like stub generation process which I don't believe is, in itself,
viable for inclusion in the C++ Standard.

What I'm thinking is that there is often a conceptual mapping between such
entities as shared object libraries and certain programming constructs.
Though C++ should not dictate how linking and loading are achieved, there
may be certain things which could be formalized to clarify this
relationship.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

'Suspect I finish reading this before I say much more:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> kanze@gabi-soft.fr wrote:

> > Steven T. Hatton wrote:

> >     [...]
> >> I'm wondering if there would be any advantage in attempting
> >> to formalize the notion of an interface as it relates to
> >> the #include directive.  I'm thinking that something along
> >> the lines of the OMG's IDL might serve as a starting point
> >> in designing such a feature.

> > I think that part of the problem you perceive is purely
> > pragmatic.  Ideally, we'd all like to put the "interface",
> > and only the interface, in the header, and everything else
> > in the implementation files.  From the very beginning,
> > however, C++ has struck a pragmatic compromize -- there are
> > very practical reasons why class definitions must contain
> > the specification of the private members, even though they
> > aren't part of the "interface".

> Understood.  I believe this is so the compiler can allocate
> memory for the member fields.  I'm not sure that "problem"
> needs to be solved for all classes.  My objection to the
> #include directive is that it is external to the language, and
> its behavior is not based on program structure.  One of the
> most frustrating aspects of C++ is trying to figureout where
> some macro, or other symbol in the current scope originated.
> This is due mostly to the nesting of #includes.

I don't think you're alone in not liking includes.

> People can argue that there are mechanisms for locating such
> definitions without a great deal of effort.  It may only take
> a minute. Do that 60 times, and it takes an hour.  The
> arrangement of different code bases makes this more difficult
> than it would be if there were a formal mechanism for
> organizing resources(as in Java).

I don't know.  I've found it just as difficult to locate
definitions in Java as in C++.  More difficult, in fact, because
the definitions are always embedded in a mess of implementation
details.

Or are you referring to the fact that some Java implementations
require that the directory structure be consistent with the
package structure.  But even then, unless you know what
CLASSPATH is set to...

    [...]
> >> I acknowledge that it might also serve as an example of why
> >> such a feature should *not* be introduced into C++.  One
> >> thing that is not clear to me is /what/, exactly, the term
> >> "interface" should mean in C++.  Is there any potential
> >> practical advantage to introducing a formal language
> >> construct called an "interface"?  What would that construct
> >> consist of?

> > Personnally, I would oppose any proposal which used the key
> > word interface, simply because the Java (mis-)implementation
> > of it has caused too much confusion around it.

> What are your objections to Java's interfaces?  They are very
> much the same as pure abstract base classes.

They are almost exactly the same as a C++ class with no
functions other than pure virtual, and no data other than static
const.  And nothing private or protected.  In sum, a perfectly
arbitrary set of conditions.

Java apparently needed as second something, since its classes
lacked essential features like multiple inheritance.  C++ has no
need for it.

And of course, the real problem is the enormous amount of
confusion that using the word "interface" as a keyword has
created, given that Java interfaces represent only a very small
subset of what we normally mean by interface.

> > Other than that, I do think that C++ would benefit by a
> > cleaner concept of modules, what is exported, what not, etc.
> > But it isn't quite obvious what.

> I'm thinking the topics discussed in this article have
> relevance to the concepts of interface, and how they might be
> supported in C++

> http://en.wikipedia.org/wiki/Software_library

Yet another Wiki entry which seems to miss most of the
essential, and wander down more or less unrelated side paths.
But I don't see the relevance to the C++ language anywhere.

> One example where the concept of interfaces has been
> successfully used in C++ development is with IBM's XPCOM.
> Part of using XPCOM involves an OMG IDL-like stub generation
> process which I don't believe is, in itself, viable for
> inclusion in the C++ Standard.

Corba uses a concept of interfaces.  In so far as Corba goes
beyond C++, allowing calls across the network to functions
written in another language, it's use of the word may be
justified.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.fr wrote:

> "Steven T. Hatton" wrote:
>> kanze@gabi-soft.fr wrote:

>> Understood.  I believe this is so the compiler can allocate
>> memory for the member fields.  I'm not sure that "problem"
>> needs to be solved for all classes.  My objection to the
>> #include directive is that it is external to the language, and
>> its behavior is not based on program structure.  One of the
>> most frustrating aspects of C++ is trying to figureout where
>> some macro, or other symbol in the current scope originated.
>> This is due mostly to the nesting of #includes.
>
> I don't think you're alone in not liking includes.

When one file holds #defined constans and is indirectly #included in another
file #defining function-like macros which depend on the #defined constants,
and that file is in turn indirectly #included in a user source file which
uses the function like macros, you end up with non-returning branches at
compile time that make a goto look tame.

I'm describing a real C++ program with a significant user base in the above
description.  The Doxygen file dependencies really /do/ look like
spaghetti.

>> People can argue that there are mechanisms for locating such
>> definitions without a great deal of effort.  It may only take
>> a minute. Do that 60 times, and it takes an hour.  The
>> arrangement of different code bases makes this more difficult
>> than it would be if there were a formal mechanism for
>> organizing resources(as in Java).
>
> I don't know.  I've found it just as difficult to locate
> definitions in Java as in C++.  More difficult, in fact, because
> the definitions are always embedded in a mess of implementation
> details.

With the exception of interfaces and abstract classes, Java doesn't have any
distinction between "declaration" and "definition" (that I can thing of.)
Of course these features are used extensively.  Nonetheless, because the
Java source code is more coherently organized by specification (or at least
recommendation and convention), and also because Java specifies a great
many infrastructure mechanism to facilitate locating resources, the Java
resource base can be searched much more effectively and deterministically
than can a C++ code base.

Some of this goes beyond what should be considered for C++ (although I
believe it is being provided with C++/CLI).  It seems, however, that C++
makes the process of locating resources unnecessarily difficult.  I believe
the biggest contributor to the problem of resolving definitions is due to
the practically non-deterministic nature of the Cpp.

> Or are you referring to the fact that some Java implementations
> require that the directory structure be consistent with the
> package structure.  But even then, unless you know what
> CLASSPATH is set to...

It is seldom a problem to find what the classpath is set to.  I really don't
know what other C++ implementations use, but with GCC, there are several
factors which go into determining what gets included, and in what order, at
compile time.  And that just addresses the source code, not the library
resources. $LD_LIBRARY_PATH, $LIBRARY_PATH, /etc/ld.so.conf, etc...

As for whether Java implementations store their resources in a directory
structure reflecting the package structure, and public class names; Java,
as I understand _The Java Language Specification_, requires that such a
structure be recoverable if, for example, resources are stored in a
database.  The use of jar files to hold Java resources is practically
identical to using a directory structure, and many tools actually support
browsing a jar file as if it were an ordinary directory.

>> What are your objections to Java's interfaces?  They are very
>> much the same as pure abstract base classes.
>
> They are almost exactly the same as a C++ class with no
> functions other than pure virtual, and no data other than static
> const.

I believe you cannot actually get a Java array to enforce constness on its
elements.

> And nothing private or protected.  In sum, a perfectly
> arbitrary set of conditions.

This is what Bjarne calls a "pure interface", and he strongly advises using
them.

> Java apparently needed as second something, since its classes
> lacked essential features like multiple inheritance.  C++ has no
> need for it.

Bill Venners: "I programmed almost exclusively in C++ for about five years,
1991 to 1996. In those days, I thought the sole purpose of multiple
inheritance was to let me inherit data and functions, both virtual and
implemented, from multiple superclasses. I never imagined using what's now
called an interface in Java, an abstract class that has no data and only
pure virtual functions. I just never thought about using multiple
inheritance that way, and neither did the C++ programmers with whom I
worked. These days you seem to be recommending abstract classes a lot. Was
the usefulness of multiply inheriting pure interfaces something that was
discovered with experience, or did we just somehow miss the message about"
abstract classes?

Bjarne Stroustrup: "I had a lot of problems explaining that to people and
never quite understood why it was hard to understand. From the first days
of C++, there were classes with data and classes without data. The emphasis
in the old days was building up from a root with stuff in it, but there
were always abstract base classes. In the mid to late eighties, they were
commonly called ABCs (Abstract Base Classes): classes that consisted only
of virtual functions. In 1987, I supported pure interfaces directly in C++
by saying a class is abstract if it has a pure virtual function, which is a
function that must be overridden. Since then I have consistently pointed
out that one of the major ways of writing classes in C++ is without any"
state, that is, just an interface.

"From a C++ view there's no difference between an abstract class and an
interface. Sometimes we use the phrase "pure abstract class," meaning a
class that exclusively has pure virtual functions (and no data). It is the
most common kind of abstract class. When I tried to explain this I found I
couldn't effectively get the idea across until I introduced direct language
support in the form of pure virtual functions. Since people could put data
in the base classes, they sort of felt obliged to do so...."

http://www.artima.com/intv/modern.html

> And of course, the real problem is the enormous amount of
> confusion that using the word "interface" as a keyword has
> created, given that Java interfaces represent only a very small
> subset of what we normally mean by interface.

Actually, the confusion might be comming from the other direction.  People
do use the expression "interface" when talking about all the public members
of a Java class.  But the use of the term in that context is usually
qualified as a "class interface".  In C++ the term interface has many
different connotations.  It would probably be wise to adopt a practice of
using specific language when talking about interfaces in C++.  E.g., "pure
interface", and "protected interface" are meaningful terms to me.

>> > Other than that, I do think that C++ would benefit by a
>> > cleaner concept of modules, what is exported, what not, etc.
>> > But it isn't quite obvious what.
>
>> I'm thinking the topics discussed in this article have
>> relevance to the concepts of interface, and how they might be
>> supported in C++
>
>> http://en.wikipedia.org/wiki/Software_library
>
> Yet another Wiki entry which seems to miss most of the
> essential, and wander down more or less unrelated side paths.
> But I don't see the relevance to the C++ language anywhere.

What I'm thinking is that a module, similar to what has been proposed in
this document:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
could be thought of as an interface similar to what is used in CORBA, XPCom,
DCOP, etc. I don't want to dictate that they must be used in that way, but
I would highly recommend their being so used.

Which makes me wonder if they should expose any member fields directly.  It
may even be worth considering making them pure virtual.

>> One example where the concept of interfaces has been
>> successfully used in C++ development is with IBM's XPCOM.
>> Part of using XPCOM involves an OMG IDL-like stub generation
>> process which I don't believe is, in itself, viable for
>> inclusion in the C++ Standard.
>
> Corba uses a concept of interfaces.  In so far as Corba goes
> beyond C++, allowing calls across the network to functions
> written in another language, it's use of the word may be
> justified.

That is exactly what I am trying to formalize, with the exception that I am
not trying to specify something that is /intentionally/ language-neutral. I
have, however, suggested that something like this would facilitate
inter-language communication (or linkage?).
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> kanze@gabi-soft.fr wrote:
>
> > "Steven T. Hatton" wrote:
> >> People can argue that there are mechanisms for locating such
> >> definitions without a great deal of effort.  It may only take
> >> a minute. Do that 60 times, and it takes an hour.  The
> >> arrangement of different code bases makes this more difficult
> >> than it would be if there were a formal mechanism for
> >> organizing resources(as in Java).
> >
> > I don't know.  I've found it just as difficult to locate
> > definitions in Java as in C++.  More difficult, in fact, because
> > the definitions are always embedded in a mess of implementation
> > details.
>
> With the exception of interfaces and abstract classes, Java doesn't have any
> distinction between "declaration" and "definition" (that I can thing of.)
> Of course these features are used extensively.  Nonetheless, because the
> Java source code is more coherently organized by specification (or at least
> recommendation and convention), and also because Java specifies a great
> many infrastructure mechanism to facilitate locating resources, the Java
> resource base can be searched much more effectively and deterministically
> than can a C++ code base.

As far as I can tell, this simply isn't true; at least, searching for
definitions in a C++ code base does not have to be inefficient or
non-deterministic. Modern IDEs accomplish this quite handily; the
Metrowerks IDE can quickly take me to the definitions of macros,
functions, classes, typedefs, etc.

In other words, the ability to search a code base is a tools issue, not
a language issue.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:dfadnU0KIovHJkbfRVn-3Q@speakeasy.net...
> In TC++PL(SE) there are many different constructs given the designation of
> "interface".  I'm confident that opinions vary as to what /does/
> constitute
> an interface.  I'm also confident that the term can be meaningfully
> applied
> to many different aspects of a program with significant diversity in
> connotation.
>

Look at gcc extensions (#pragma interface/implementation)
http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Interface.html for one
example.
I would rather prefer interface/implementation keywords, which would create
a namespace and all the namespace rules be also applied to
interface/implementation blocks.

interface foo
{
    void f();
    void g() { ... } // implemented in interface: same as "inline void g()"
    template<class T> void h(); // it's ok to have implementation even in
another file
    // because compiler knows that implementation name is the same as
interface name
}

implementation foo
{
    void f() { ... }
    template<class T> void h() {...}     // template implementation
}

in another file:
implementation bar
{
    using interface foo;
    void g() { f(); } // or foo::f()
}

It requires more smarts from the compiler to know where to find interfaces
and include them only once and where to find implementations and compile
them also once and include template implementation with interface, etc.
There are probably some other complications with this scheme that I haven't
thought about, but on the surface it looks feasible.

- gene

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gene Bushuyev wrote:

> "Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
> news:dfadnU0KIovHJkbfRVn-3Q@speakeasy.net...
>> In TC++PL(SE) there are many different constructs given the designation
>> of
>> "interface".  I'm confident that opinions vary as to what /does/
>> constitute
>> an interface.  I'm also confident that the term can be meaningfully
>> applied
>> to many different aspects of a program with significant diversity in
>> connotation.
>>
>
> Look at gcc extensions (#pragma interface/implementation)
> http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Interface.html for one
> example.

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15815

> I would rather prefer interface/implementation keywords, which would
> create a namespace and all the namespace rules be also applied to
> interface/implementation blocks.

> interface foo
> {
>     void f();
>     void g() { ... } // implemented in interface: same as "inline void
>     g()" template<class T> void h(); // it's ok to have implementation
>     even in
> another file
>     // because compiler knows that implementation name is the same as
> interface name
> }
>
> implementation foo
> {
>     void f() { ... }
>     template<class T> void h() {...}     // template implementation
> }
>
> in another file:
> implementation bar
> {
>     using interface foo;
>     void g() { f(); } // or foo::f()
> }
>
> It requires more smarts from the compiler to know where to find interfaces
> and include them only once and where to find implementations and compile
> them also once and include template implementation with interface, etc.
> There are probably some other complications with this scheme that I
> haven't thought about, but on the surface it looks feasible.
>
> - gene

It seems to me we are simply asking the computer (C++PP?) to automate the
steps the programmer has traditionally performed by hand with #include
directives.  Would simply giving the `interface' the same functionallity we
get from "#include guards" suffice?  The notion of doing that with a
preprocessor bothers me bacause `interface' not a preprocessor directive in
your example. Doing it with the compiler would probably entail a new way of
viewing what a compiler does.  I'll need to think on this somemore.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In TC++PL(SE) there are many different constructs given the designation of
"interface".  I'm confident that opinions vary as to what /does/ constitute
an interface.  I'm also confident that the term can be meaningfully applied
to many different aspects of a program with significant diversity in
connotation.

To my mind, perhaps the most elementary notion of interface in C++ is
expressed by the simple forward declaration of a function. The C concept of
a pointer to a function also seems to satisfy some essential property
justifying its designation as an interface.  One view of the role of
so-called 'header files' in C++ is that they provide a means of declaring
an interface.  The definition of a class is often said to define its
interface(s).  The closest thing to a formal definition of an interface
that exists in C++ is the abstract base class with nothing but pure virtual
functions.

Last year I came to C++ (other than a brief exposure in the early '90s) from
a Java and systems engineering background.  The ideas I had formed about
how C++ was or should be used were heavily influenced by applications built
using formal interface definition tools[*], as well as Java's notion of an
interface (which is really, more or less, just a formalization of the C++
abstract base class). Also worth mentioning are my exposure to
Mathematica's package system, as well as extensive hardware experience.

One of the most cumbersome aspects of C++ programming for me to adjust to
has been the use of header files.  Since my Java, and other experience made
me think in terms of strictly confining all programming constructs to
classes (no global nor namespace local variables or functions-a requirement
I have since abandoned), the hardest thing for me to grasp was the full
advantage of separating class definitions (in "header files") from
implementations (in "source files").  I was assured (rather forcefully) by
many experienced C++ programmers that this is a good practice.

I have since learned that this is not a universal practice, and it is often
implemented in a mixed style with some member functions defined in-place,
and others in a separate source file, or inlined and included in the header
file where the class definition resides.  It's worth mentioning that
templates have added significantly to the confusion in so much as the C++
implementations I've been using have not consistently honored the /export/
keyword.

For the most part, the above discussion of header files deals with issues of
programming style, rather than necessity.  There are, however, some purely
technical reasons for putting some code in "header files" and other code in
"source files".  These have to do with the ODR (One Definition Rule).
These issues of style and ODR often complement eachother, but sometimes
seem to be in conflict.  There are also times when concepts such as
"compilation unit" can be rather nebulous. For instance, when discussing
dynamically linked libraries.

I've recently come to understand that not all C++ programmers share the
strong concepts of interface which I had taken as ubiquitous throughout the
C++ culture.  There seems to be a difference of opinion as to the real
value and purpose of the #include directive.  There appear to be two
fundamentally different uses for this CPP feature.  One has to do with the
stylistic notion of an interface, and the other to do with the pragmatic
need to organize code so that the ODR is not violated.

I'm wondering if there would be any advantage in attempting to formalize the
notion of an interface as it relates to the #include directive.  I'm
thinking that something along the lines of the OMG's IDL might serve as a
starting point in designing such a feature.  I acknowledge that it might
also serve as an example of why such a feature should *not* be introduced
into C++.  One thing that is not clear to me is /what/, exactly, the term
"interface" should mean in C++.  Is there any potential practical advantage
to introducing a formal language construct called an "interface"?  What
would that construct consist of?

[*]I did read a fair amount of C++ code through the years, but didn't write
any significant amount.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]