Why code completion and early error checking are needed

[Petec]

There's really no reason for C++ to have such limitations except for
the bloody C preprocessor, and the fragmented naming scheme using
both headers and namespaces.

But, I'm not just talking about command and control code, or whatever
you want to call GUI code this week.

Please, stop trying to turn C++ into Java. There's a reason I use C++
instead of Java, because I absolutely hate the Java way of doing things.
If C++ loses its preprocessor, etc in C++ 20xx, I'm sticking with the last
real C++.

I have no idea what you are talking about. You seem to be using
refactoring in a very different way than it is used in the
professional literature: http://www.laputan.org/mud/mud.html

The term has come to mean something specific in the area of IDE
functionality. To put it in C++ terms, it means I could select all
the code in one namespace and move it to another namespace with one
command.

I'm not merely wishing C++ were different, I'm actually trying to
find a way to support the functionality I've been describing in an
IDE currently under development.

The language is not the IDE. It's perfectly possible to do what you wish in
an IDE for C++ in its current state. Again, I don't know why you insist on
ignoring VC++, but it demonstrates quite nicely that what you want is
possible.

- Pete

 

[Steven T. Hatton]

frankly what you feel, what i feel, and what anyone else feels is
irrelevant. if you have a case to present, please present that case on
its own merits. am i correct in assuming that your thesis is that one of
the guiding principles in the evolution of the c++ language should be
the ease with which machines can deduce code given partial samples?

No. You are incorrect.

the problem with this is that ide must first be able to assume
intention. even in more simplified cases, such as java, a lot of
information is needed to make safe assumptions. for example, on first
appearance of a type name, the compiler has to search all known
libraries to find the type declaration. this is a tedious but trivial
process if there is only one matching type, but what if there are
duplicated type names?

Google only takes a few seconds to search the entire internet. It shouldn't
be that hard to build useful indexes of the available resources. Currently
it is not possible to rely on the implementation providing interface
declarations for the Standard Libraries.

for example, i type "Vector". does that mean the standard vector
container, int namespace java.util? or my own 3d vector class in
indi.math?

If you type std::vector that means the one from the Standard. If you have a
using declaration in your code for indi::math::vector and nothing else to
inject the name vector, then it means your vector. If there is ambiguity,
then you need to resolve it manually.

in java's simplified world the solution to such a problem is simply to
offer a choice of all candidates. but c++ has special challenges. in
java, the required header to import is well-defined and can be easily
extrapolated from the type name, or even better, from the
fully-qualified typename. you want "Vector" in "java.util"? it doesn't
take a complicated algorithm to generate "import java.util.Vector".

And that demonstrates what is wrong with C++'s fragmented naming system.

but in c++ the header to import is not well-known, not only because no
part of it can be deduced from the type name, but because the possiblity
of nesting includes within other includes. for example, consider
std::string. obviously the correct include in this case is <string>, but
indulge me momentarily. imagine you have thousands of headers for
classes that use strings internally. how is the compiler to know that
you specifically want <string> and do not wish to come by string by some
other means?

it cannot be argued that programmers will only want to include the
actual base declaration header for a type. it may be by design that
<string> is not included directly, for several reasons, including
precompiled headers and the potential to transparently replace usage of
std::string in the library with something_else::string at some future
date.

I don't see how this has any bearing on the subject. Are you suggesting
names should be introduced into your program through indirect inclusion?

furthermore it may be that while "some_type" is actually declared in
"some_type.h", the intention was that "some_type.h" should never be
included in client code directly. take the classic case of <windows.h>.
the definition of type LPTSTR is given a default value in <windows.h>
that can be overidden by the use of precompiler macros. across the scope
of a project it would be expected that the definition is consistent, but
this may not be the case if <windows.h> is included directly instead of
"windows_includer.h".

I can't prevent bad design. But there is certainly room in what I am
proposing for the identification of exported headers to be included by
users of the library, and internal headers intended for use only by library
developers. That actually strengthens my position.

you could argue that programmer oversight would properly direct the
ide's assumptions, but if the programmer has to read the documentation
and determine the proper include files themself, what gain is there in
having the ide attempt a guess? the cost is the time spent parsing what
may be a massive source pool (or the disk-space cost if it is
pre-parsed), the pros are.... what? forcing the programmer to read
documention he should be reading anyway?

I believe you are demonstrating what is wrong with the current C++ standard.
There is nothing valuable gained by this incoherence, and much lost.

so the ide will have a job of it. well then, maybe changes are needed
elsewhere, right?

even if it were possible to correct this problem by a reasonable
revision to the language standard (which i doubt), i do not believe that
it should be applied. it would be limiting to the power and flexibility
of the language to have certain naming and declaration standards
imposed. unlike a language such as java, c++ is multi-platform capable -
the task of writing portable code demands the ability to be flexible
with type declarations.

Specifying a standard means of providing an interface to libraries including
the Standard Library should not preclude any of these porting mechanisms.

within a given coding team you could enforce standards that facilitate
easy machine analysis, and project leaders are welcome to do so.
personally, i am opposed to tying programmers hands with more rules than
are absolutely necessary - it limits efficiency to have to conform to
potentially unnatural rules, stifles creativity, and may preclude some
powerful problem solutions.

I have never driven on the streets of Rome Italy. I believe, however, the
city provides a good example of what happens when there are very few
restrictions on how people drive. I base this on what my Italian doctor
told me while performing out patient surgery.

so the onus is back on the ide to somehow handle this. i don't pretend
it will be easy - c++ is a two-pass parsed language with a one
definition rule, but no one declaration rule. can it be done? oh most
probably. but it should be done by the ide, not by limiting the power
and flexibility of the language, or by hampering the programmers trying
to use it.

If anything, I believe the exercise of specifying how this interface
mechanism can be provided will reveal many things that should and can be
changed for the better without negatively impacting the language.

the c++ exception specification mechanism is sadly broken. it is also
difficult to fix, even if one was inclined to rewrite the standard.

There will be future modifications to the standard which can include such
changes. I believe such things can be corrected if people are willing to
drop some legacy code from the support requirements.

in my mind, this and complications due to inheritance preclude changes
to the language directly, so the task for implementing this feature will
fall at the feet of the ide writer.

I am inclined to believe the difficulties presented to IDE developers reveal
defects in the language. I'm also of the opinion that there are probably
some key points where changes to a certain part of the language will lead
to the solution of many problems.

well now, you've opened up a whole new kettle of fish here. i
deliberately avoided mentioning functions when i was discussing
including the correct headers for types because the problem is even
worse there. even within the bounds of the standard library, there can
be several answers to the question of which file to include given a
specific function signature.

now that you're talking about considering not only multiple declarations
of a single function, but also potentially multiple signature for
multiple overloads, the complexity is increasing by leaps and bounds.

I'm not sure what your getting at here. I'm not suggesting the IDE solve
all ambiguities without user intervention. I also expect some things
involving templates will need to be taken step by step.

those are the kinds of design questions you would expect to see in the
development of an ide, not a language.

The question was about an IDE. I was trying to determine if any IDEs
currently provide the kind of functionality I'm interested in. If they do,
then at least I know it's possible.

i feel your pain. i am a lone wolf developer and hobbyist c++ coder. i
do not have the luxury of being a programmer that can choose to
specialize in one library, or even one aspect of program development. i
agree that the size of many libraries is daunting, and expecting anyone
to know all the capabilities and gotchas associated with any particular
api is ludicrous.

but these are not problems with the standard, they are concerns of the
library writer. even if the language were to make it laughably simple to
maniuplate huge libraries, the question remains as to whether making a
huge library is a good thing. a good library would be simple and
modular, so that for any given problem you would know where to look for
the solution set, and the size of that solution set is manageable.

the argument that c++ should have built-in facilities to support huge,
cumbersome libraries because they exist and must be used is no more or
less valid than the argument that built-in facilities to support huge,
monolithic should not be added to the c++ language because the c++
language is the way it is and must be used as is.

I don't believe you are getting my point. It should provide a standard
means of structure libraries of any size. I don't believe this is all the
compicated.

and there is no rational argument that i can imagine for why they should
not be developed and used - or at least available. the only question
here is where the burden for the development of these feature should be
placed.

If changes in the language specification can make the task significantly
easier then they should be made there.

you make a good point. my argument exists only of glaring generalities.
but then, no-one has provided a valid proposal for how these
requirements could be met on any given c++ implementation, let alone all
of them. i will provide a reasoned, objective rationale for why the
proposed support would significantly impact c++ - positively, negatively
or both - when you provide a reasonable proposal of what this support
will be.

That's fair enough. I never said I had all the solutions.

that being said, this is hardly the forum to do that. comp.lang.c++
discusses *using* the c++ language, not designing, changing or improving
it.

The FAQ specifically states that the newsgroup is open to discussion of
"future directions" for C++.

 

[Steven T. Hatton]

Please, stop trying to turn C++ into Java. There's a reason I use C++
instead of Java, because I absolutely hate the Java way of doing things.
If C++ loses its preprocessor, etc in C++ 20xx, I'm sticking with the last
real C++.

Why did Stroustrup suggest that the preprocesor should be replaced?

The language is not the IDE. It's perfectly possible to do what you wish
in an IDE for C++ in its current state. Again, I don't know why you insist
on ignoring VC++, but it demonstrates quite nicely that what you want is
possible.

I'm not sure it really does provide what I've described. I gave you a list
of questions asking if it provided the features described therein, and you
did not address the questions.

 

[Petec]

Why did Stroustrup suggest that the preprocesor should be replaced?

I don't know, but I disagree with him.

I'm not sure it really does provide what I've described. I gave you
a list of questions asking if it provided the features described
therein, and you did not address the questions.

It is up to the IDE, not the language, to do the things you described. VC++
does /some/ of them, proving that such things are possible. I suspect, but
have not tried, that VS.NET add-ins could fill in most of the others.

- Pete

 

[Carl Ribbegaardh]

Carl Ribbegaardh wrote:


Yes, I meant to put "Your operating system of choice's tools *may* have
not...".
I haven't used Linux except for one month, after which I promptly discarded
it in favor of Windows, due to the fact that I like neither the open-source
philosophy or the style of tools.

- Pete

It was meant more as an extension of your post, targeted at the OP.


Personally I prefer Windows and VC++ as I'm used to it and I work much
faster there, but Eclipse looks/feels very good.

/Carl

 

[Steven T. Hatton]

It was meant more as an extension of your post, targeted at the OP.


Personally I prefer Windows and VC++ as I'm used to it and I work much
faster there, but Eclipse looks/feels very good.

I know the feeling. I'm in the same situation regarding switching from
JBuilder to C++. Since the best thing going for C++ IDEs for Linux is
KDevelop, I am learning to program in C++ on builds of the latest CVS. It
can prove interesting.

As regards Eclipse CDT, I haven't looked at Eclipse since September,
according to the dates on my files. The CDT wasn't working with the
Eclipse I was using back then. I just fetched it. They prettied up the
interface a bit, but it seems to have a few 'issues'. Personally, I'll
stick with the IDE written in C++. http://www.kdevelop.org

 

[Julie]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication <snip>

All of what you want and more can be easily provided if the source is (parsed
and) stored in a _database_ as opposed to the ancient file-based structure
currently used.

So, my recommendation is to look at changing the fundamental storage unit, and
the other stuff comes naturally. Otherwise, it come at a very high price w/
file-based code.

 

[Phlip]

Please, stop trying to turn C++ into Java.

Man, that's such a great way to say it.

The language is not the IDE. It's perfectly possible to do what you wish in
an IDE for C++ in its current state. Again, I don't know why you insist on
ignoring VC++, but it demonstrates quite nicely that what you want is
possible.

To do such an IDE, you'd need to re-write a compiler front-end from
scratch. Its object model and algorithms would support event-driven
queries from the IDE about program structure.

Legacy compilers are tuned for batch-mode, not on-demand mode.

Nobody's going to develop two compilers, one for the editor and
another for the production build. And nobody is going to throw away a
legacy compiler just to ship one that bonds with an IDE. Such a
project would destroy an entire customer base, when the compiler
delivered different bugs than the ones all our code has grown use to.

And these points are all peripheral. Coding is not about entering
statements hand-over-fist, or automating that. Coding is about
designing a minimal set of methods to support a maximal set of
requirements. That requires emmendment and thought, not ammendment and
rote.

Java and its editors, by demonstrating advanced automated support for
writing code statements, are revealing how broken a language can be
(not that C++ any better here). If a lowly editor can predict our next
statement, then why should the vaunted compiler force us write it?

 

[E. Robert Tisdale]

All of what you want and more can be easily provided
if the source is (parsed and) stored in a _database_
as opposed to the ancient file-based structure currently used.

So, my recommendation is
to look at changing the fundamental storage unit
and the other stuff comes naturally.
Otherwise, it come at a very high price w/file-based code.

No it doesn't.
Everything that Steven T. Hatton has proposed and more
can be and is being done now with plain text source code files.

 

[Phlip]

There's really no reason for C++ to have such limitations except for the
bloody C preprocessor, and the fragmented naming scheme using both headers
and namespaces.

I fear C++ the way a farmer fears dieties who affect weather and biology.

You show insufficient respect for the difficulties C++ provides. It's not
just the preprocessor. That's symbolic of an entire range of thorny issues -
Koenig lookup, global constructor orders, typenames, partial template
instantiation, exception specifiers, the one definition rule, template
instantiation locations, the sizes of basic types, pointers to virtual
methods, etc.

Bringing all of that within reach of an IDE's autocomplete feature would be
a Sisyphean effort.

 

[Phlip]

Steven T. Hatton wrote;

Phlip wrote:

There's really no reason for C++ to have such limitations except for the
bloody C preprocessor, and the fragmented naming scheme using both headers
and namespaces.

But, I'm not just talking about command and control code, or whatever you
want to call GUI code this week.

You have a lot to learn. Let's start with architecture.

GUI code is supposed to be as thin as possible, with its controllers pulled
out into GUI-free layers.

The bulk of the code out there is the logic between the database and the
GUI. That code should be in a soft language, to enable the kinds of tool
support you want to add to C++.

So if GUI code is thin, and depends on form painters, then its code could
easily be in C++, as a simple pass-thru to the logical layers. And, again,
the bulk of the project would not be there, so tool support is not so
important.

Do yourself a favor: Identify a real world problem that you want your
enhanced IDE to help you write C++ to solve.

 

[Steven T. Hatton]

Steven T. Hatton wrote;


You have a lot to learn. Let's start with architecture.

GUI code is supposed to be as thin as possible, with its controllers
pulled out into GUI-free layers.

Oh you mean the abstract user interface, or AUI as I was calling it back in
the 90's?

The bulk of the code out there is the logic between the database and the
GUI. That code should be in a soft language, to enable the kinds of tool
support you want to add to C++.

Where do you come up with these absurdities? But I've been told that
support can, and has already been, implemented for C++. I've also been
told, in the context of the same discussion that it is impossible.

So if GUI code is thin, and depends on form painters, then its code could
easily be in C++, as a simple pass-thru to the logical layers.

So, you are saying C++ is not a good programming language for writing the
business logic parts of an application? You earlier asserted that C++ is
good for writing "libraries". I'm looking at the source for one of the
largest C++ projects in the world, and there sure is a lot of front-end
stuff in libraries.

And, again,
the bulk of the project would not be there, so tool support is not so
important.

http://www.research.att.com/~bs/bs_faq.html#working-on-now
"What are you working on now?
"A better FAQ "

"Seriously, I'm looking for fundamental ways of improving the tools and
techniques we use to build large real-world systems."

Do yourself a favor: Identify a real world problem that you want your
enhanced IDE to help you write C++ to solve.

That list is already huge.

 

[Steven T. Hatton]

Man, that's such a great way to say it.

Then you'll be happy to know this:

Concurrency: I'd like to see a library supporting threads and a related
library supporting concurrency without shared memory. [Like Java has]

Reflection: I'd like to see something like that supported through a library
defining the interface to extended type information.[Like Java has]

Persistence: I'd like to see some support in the Standard Library, probably
in connection with the extended type information, but I don't currently
have any concrete suggestions.[Like Java has]

Regular expression matching: I'd like to see a pattern-matching library in
the standard. [Like Java has]

Garbage collection: I'd like to see the C++ standard explicitly acknowledge
that it is an acceptable implementation technique for C++, specifying that
"concealed pointers" can be ignored and what happens to destructors for
collected garbage. [Like Java has]

GUI: It would be nice to have a standard GUI framework, but I don't see how
that could be politically feasible. ["Politically feasible"? Who would try
to stop that?]

Platform-independent system facilities: I'd like to see the Standard Library
provide a broader range of standard interfaces to common system resources
(where available), such as directories and sockets. [Like Java has]

To do such an IDE, you'd need to re-write a compiler front-end from
scratch. Its object model and algorithms would support event-driven
queries from the IDE about program structure.

You'd need a lexer:
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/classLexer.html

You'd need a parser:
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/classParser.html

Something to manage the parser scheduling:
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/cpp_2backgroundparser_8cpp.html

You'd need an abstract syntax table:
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/classAST.html

You'd need something to actually do the code completion:
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/classCppCodeCompletion.html

You'd need a class to do the colorization for syntax highlighting.
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/classCppColorizer.html

Legacy compilers are tuned for batch-mode, not on-demand mode.

Nobody's going to develop two compilers, one for the editor and
another for the production build. And nobody is going to throw away a
legacy compiler just to ship one that bonds with an IDE. Such a
project would destroy an entire customer base, when the compiler
delivered different bugs than the ones all our code has grown use to.

You are speaking from a very limited perspective, and are quite wrong about
what people are likely to create.

And these points are all peripheral. Coding is not about entering
statements hand-over-fist, or automating that. Coding is about
designing a minimal set of methods to support a maximal set of
requirements. That requires emmendment and thought, not ammendment and
rote.

You really have no idea of the kinds of things I've been working with.

 

[Petec]

Man, that's such a great way to say it.


To do such an IDE, you'd need to re-write a compiler front-end from
scratch. Its object model and algorithms would support event-driven
queries from the IDE about program structure.

Legacy compilers are tuned for batch-mode, not on-demand mode.

Nobody's going to develop two compilers, one for the editor and
another for the production build. And nobody is going to throw away a
legacy compiler just to ship one that bonds with an IDE. Such a
project would destroy an entire customer base, when the compiler
delivered different bugs than the ones all our code has grown use to.

VB 5 and 6 did it...

- Pete

 

[Phlip]

Petec wrote;

Phlip wrote:

VB 5 and 6 did it...

If VB had been a very complex language with a legacy implementation, they
could not have.

 

[Phlip]

Oh you mean the abstract user interface, or AUI as I was calling it back in
the 90's?

Oh, my. I'm just the young whippersnapper, and the senior STH has been
working since the 90s...

Thanks, I needed that!

 

[Julie]

No it doesn't.
Everything that Steven T. Hatton has proposed and more
can be and is being done now with plain text source code files.

Right! at a very high price, like I said.

 

[Julie]

Man, that's such a great way to say it.

Then you'll be happy to know this:

Concurrency: I'd like to see a library supporting threads and a related
library supporting concurrency without shared memory. [Like Java has]

Reflection: I'd like to see something like that supported through a library
defining the interface to extended type information.[Like Java has]

Persistence: I'd like to see some support in the Standard Library, probably
in connection with the extended type information, but I don't currently
have any concrete suggestions.[Like Java has]

Regular expression matching: I'd like to see a pattern-matching library in
the standard. [Like Java has]

Garbage collection: I'd like to see the C++ standard explicitly acknowledge
that it is an acceptable implementation technique for C++, specifying that
"concealed pointers" can be ignored and what happens to destructors for
collected garbage. [Like Java has]

GUI: It would be nice to have a standard GUI framework, but I don't see how
that could be politically feasible. ["Politically feasible"? Who would try
to stop that?]

Platform-independent system facilities: I'd like to see the Standard Library
provide a broader range of standard interfaces to common system resources
(where available), such as directories and sockets. [Like Java has]

With the exception of the last item, what you are asking for sounds like C# --
I presume that you are (programmatically) familiar w/ that?

 

[Petec]

Petec wrote;


If VB had been a very complex language with a legacy implementation,
they could not have.

I can't think of a language more encumbered with legacy junk than VB6.

- Pete

 

[Mark A. Gibbs]

No. You are incorrect.

see, right about there would have been an intelligent time to tell me
what was incorrect and what would have been correct.

Google only takes a few seconds to search the entire internet. It shouldn't
be that hard to build useful indexes of the available resources. Currently
it is not possible to rely on the implementation providing interface
declarations for the Standard Libraries.

that would be an ide issue, not a language issue.

If you type std::vector that means the one from the Standard. If you have a
using declaration in your code for indi::math::vector and nothing else to
inject the name vector, then it means your vector. If there is ambiguity,
then you need to resolve it manually.

so you have to type the entire fully qualified name?

And that demonstrates what is wrong with C++'s fragmented naming system.

opinion != fact. why you would consider c++'s "naming system"
"fragmented" is beyond me. do you believe that c++ source and header
files should be forced to contain one and only one class
definition/declaration, and should be named after that class? and that
the files should be in folder hierarchy based on namespace membership?

that's a very clever solution in a way that somehow manages to be
completely not clever at all.

first, c++ allows the creation of lightweight worker classes - in my
experience, those are very common when using riaa or the adaptor
pattern. you want a file for every tiny little worker class? what about
meta-classes that are never intended to be directly used except via
macros? what about free functions?

second, you would be assuming certain capabilities on the file system
being used for c++ development.

third, why in gods name would you want to force a programmer into
putting huge amounts of code into single files just because they share
the name of the class?

shall i go on?

since it seems that i am lousy at assuming your point, perhaps you could
explicitly tell me exactly what about the "naming system" is
"fragmented", hm?

#include <string>

? do you even read what i write?

I don't see how this has any bearing on the subject. Are you suggesting
names should be introduced into your program through indirect inclusion?

should? no. could? yes, i am indeed.

//file win_something.hpp
typedef HANDLE something_handle;

//file linux_something.hpp
typedef void* something_handle;

//file something_something.hpp
typedef some_struct something_handle;

//file something.hpp
#if defined WINDOWS
#include "win_something.hpp"
#elif defined LINUX
#include "linux_something.hpp"
#elif defined SOMETHING_ELSE
#include "something_something.hpp"
#endif

flexibility is nice.

I can't prevent bad design. But there is certainly room in what I am
bad?

proposing for the identification of exported headers to be included by
users of the library, and internal headers intended for use only by library
developers. That actually strengthens my position.

i find myself increasingly amazed at how just about any fact or opinion
strengthens your position - even evidence in direct opposition.

I believe you are demonstrating what is wrong with the current C++ standard.
There is nothing valuable gained by this incoherence, and much lost.

i am? please don't tell me you would use code completion facilities - in
*any* language - without reading the documentation. once again, do you
even read what i write?

Specifying a standard means of providing an interface to libraries including
the Standard Library should not preclude any of these porting mechanisms.

maybe, but that would depend on what those "standard means" are, would
it not? i cannot see any way to do it, and you have not proposed any.

saying something "should" be done because it is "good" is rather
disingenious. i mean, no shit, sherlock. if it were possible to have
every good feature of every language and still maintain c++'s power,
flexibility and portability, and be backwards compatible, what even
partly intelligent person would say no? and yes, some sacrifices can and
have been made for progress.

the ball was, and is, in your court, however, to find out if any
sacrifices must be made, and what those sacrifices might be.
furthermore, it may be up to you also to make a case as to why those
sacrifices are acceptible for the given benefits.

I have never driven on the streets of Rome Italy. I believe, however, the
city provides a good example of what happens when there are very few
restrictions on how people drive. I base this on what my Italian doctor
told me while performing out patient surgery.

that's... fascinating. actually, that might be a relevant entry into the
discussion if it were about a labotomy.

If anything, I believe the exercise of specifying how this interface
mechanism can be provided will reveal many things that should and can be
changed for the better without negatively impacting the language.

that's good. and quite welcome. specify away.

There will be future modifications to the standard which can include such
changes. I believe such things can be corrected if people are willing to
drop some legacy code from the support requirements.

"willing to drop some legacy code"? perhaps. what code, specifically?
show your work.

I am inclined to believe the difficulties presented to IDE developers reveal
defects in the language. I'm also of the opinion that there are probably
some key points where changes to a certain part of the language will lead
to the solution of many problems.

i disagree on the first point. code generation, and smart ides are nifty
tools, yes. but if flexibility and expressive power must be sacrificed
for their sake, i side with the nays.

as for the for the second point, it's kind of a non-statement. i mean it
probably is true, but so what? do you have any changes to propose?

I'm not sure what your getting at here. I'm not suggesting the IDE solve
all ambiguities without user intervention. I also expect some things
involving templates will need to be taken step by step.

my point was that the complexity involved in implementing this would be
immense. any standard specification for how this should be done would be
similarly immense.

The question was about an IDE. I was trying to determine if any IDEs
currently provide the kind of functionality I'm interested in. If they do,
then at least I know it's possible.

was that the question? the question i read was: "Can anybody provide
a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?"

I don't believe you are getting my point. It should provide a standard
means of structure libraries of any size. I don't believe this is all the
compicated.

and my point - including all the evidence i provided - was that i do.
you're welcome to explain how it could be acclomplished.

If changes in the language specification can make the task significantly
easier then they should be made there.

perhaps. we do have a committee to make these decisions you know. all
you need to do is say what changes for what benefits.

The FAQ specifically states that the newsgroup is open to discussion of
"future directions" for C++.

it does? "Only post to comp.lang.c++ if your question is about the C++
language itself. For example, C++ code design, syntax, style, rules,
bugs, etc. Ultimately this means your question must be answerable by
looking into the C++ language definition as determined by the ISO/ANSI
C++ Standard document, and by planned extensions and adjustments." [5.9]

on the other hand:

" # comp.std.c++

* Discussion directly related to the evolving ANSI/ISO C++ standard
* The evolving ANSI/ISO C++ standard is discussed below"

mark