Why code completion and early error checking are needed

[Steven T. Hatton]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the part of
the programmer who wants such features. Unfortunately these ad hominem
rhetorts are frequently introduced into purely technical discussions on the
feasibility of supporting such functionality in C++. That usually serves
to divert the discussion from the technical subject to a discussion of the
character of the proponent of the new technology. This recently happened in
this newsgroup, and I have to confess, I took the bait and defended my
character instead of ignoring the irrelevant comments.

Since I still believe the features I listed are important to C++ I am making
an effort to return that discussion to the relevant technical matters. The
list is not intended to be exhaustive, and any item on it is subject to
refinement or even removal. It is only intended as a starting point for
further development of the ideas. Here is the list again:
//-----------------------------------------------------------  
Will the IDE add the required headers and using declarations to your source
automatically?  

Will it give an indication of the exceptions thrown by a function call?  

Will it display all the overloaded function signture with an indication of
the type of parameter it takes?  

Does it filter according to context?  That is, does it only show the
identifiers visible in the current scope when it provides code completion
(unless you ask for more)?

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same level
as it does for the Standard Libraray and the implementation's API(s)?
//-----------------------------------------------------------

Since there is some question as to whether such functionality would be
advantageous to C++, I will briefly address the matter. I have been
working with a project that has grown from something I could download and
build in a matter of minutes on 1997 computing technology (sparc 5, and P2
intel platforms), to a world class desktop user interface environment with
more than 40,000 lines of code. The collective libraries for all the
components of the KDE is huge. It is unreasonable to expect a programmer
to be aware of every feature of every class and function in these
libraries. And that fails to take into account the number of different
supporting libraries employed, or potentially employed by the developer.

The feature I have listed above have proven useful to developers working on
large-scale projects using a different programming language. The provide a
way for the programmer to leaverage the available resources more
efficiently and effectively.

It has been suggested that an effort to support such functionality by
ensuring the C++ implementation provides the necessary interface to the
development environment would somehow encumber C++ and make it
significantly less useful. Since, so far as I know, the requirements for
providing this interface have not been established, I find it difficult to
believe the impact on the language has been evaluated. Can anybody provide
a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

believe the impact on the language has been evaluated. Can anybody
provide a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?

I think the standarization process does not work that way. You must prove
that the proposal will significantly and positively impact C++.

 

[Steven T. Hatton]

I think the standarization process does not work that way. You must prove
that the proposal will significantly and positively impact C++.

My question was not about the standardization process.

 

[Petec]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the
part of the programmer who wants such features. Unfortunately these
ad hominem rhetorts are frequently introduced into purely technical
discussions on the feasibility of supporting such functionality in
C++. That usually serves to divert the discussion from the technical
subject to a discussion of the character of the proponent of the new
technology. This recently happened in this newsgroup, and I have to
confess, I took the bait and defended my character instead of
ignoring the irrelevant comments.

Since I still believe the features I listed are important to C++ I am
making an effort to return that discussion to the relevant technical
matters. The list is not intended to be exhaustive, and any item on
it is subject to refinement or even removal. It is only intended as
a starting point for further development of the ideas. Here is the
list again:
//-----------------------------------------------------------
Will the IDE add the required headers and using declarations to your
source automatically?

Will it give an indication of the exceptions thrown by a function
call?

Will it display all the overloaded function signture with an
indication of the type of parameter it takes?

Does it filter according to context? That is, does it only show the
identifiers visible in the current scope when it provides code
completion (unless you ask for more)?

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same
level as it does for the Standard Libraray and the implementation's
API(s)? //-----------------------------------------------------------

Since there is some question as to whether such functionality would be
advantageous to C++, I will briefly address the matter. I have been
working with a project that has grown from something I could download
and build in a matter of minutes on 1997 computing technology (sparc
5, and P2 intel platforms), to a world class desktop user interface
environment with more than 40,000 lines of code. The collective
libraries for all the components of the KDE is huge. It is
unreasonable to expect a programmer to be aware of every feature of
every class and function in these libraries. And that fails to take
into account the number of different supporting libraries employed,
or potentially employed by the developer.

The feature I have listed above have proven useful to developers
working on large-scale projects using a different programming
language. The provide a way for the programmer to leaverage the
available resources more efficiently and effectively.

It has been suggested that an effort to support such functionality by
ensuring the C++ implementation provides the necessary interface to
the development environment would somehow encumber C++ and make it
significantly less useful. Since, so far as I know, the requirements
for providing this interface have not been established, I find it
difficult to believe the impact on the language has been evaluated.
Can anybody provide a reasoned, objective rationale for why the
proposed support would significantly and negatively impact C++?

Again, C++ already provides such functionality in its declarations. It's up
to the IDEs to use that info, and the /language/ standards should not
specify IDE features.

- Pete

 

[Steven T. Hatton]

Steven T. Hatton wrote:

Again, C++ already provides such functionality in its declarations.

I don't believe the Standard acutally requires the presence of these
declarations as such. As long as the implementation producese the compiled
result "as if" they were present it is considered to conform to the
Standard.

It's
up to the IDEs to use that info, and the /language/ standards should not
specify IDE features.

It's been proposed that IDE support be included as a formal consideration in
future versions of the Standard. The way I see it, the traditional view of
source code written in programming languages is that it has two primary
audiences, programmers, and computers. I believe a third 'audience' should
be considered, the IDE. I am not proposing the specification of the
language place requierments on IDEs. It does seem reasonable to consider
placing requirements on the implementation to provide a standard means of
extracting information from the available resources intended for use as
development libraries. That includes the Standard Library.

It may turn out that the Standard itself does not need to be modified, and
that this can all be accomplished by the implementation.

 

[Petec]

Petec wrote:

I don't believe the Standard acutally requires the presence of these
declarations as such. As long as the implementation producese the
compiled result "as if" they were present it is considered to conform
to the Standard.

For the standard library, yes, that is true, but implemetations are
perfectly capable of knowing how they store their own std lib.
For any other librarys, and components of user programs, declarations and
definitions work fine.

It's been proposed that IDE support be included as a formal
consideration in future versions of the Standard. The way I see it,
the traditional view of source code written in programming languages
is that it has two primary audiences, programmers, and computers. I
believe a third 'audience' should be considered, the IDE. I am not
proposing the specification of the language place requierments on
IDEs. It does seem reasonable to consider placing requirements on
the implementation to provide a standard means of extracting
information from the available resources intended for use as
development libraries. That includes the Standard Library.

It may turn out that the Standard itself does not need to be
modified, and that this can all be accomplished by the implementation.

VC++ has already proved that that is so. Your operating system of choice's
tools have not, but that does not mean that superior OSs' tools do not.

- Pete

 

[Carl Ribbegaardh]

For the standard library, yes, that is true, but implemetations are
perfectly capable of knowing how they store their own std lib.
For any other librarys, and components of user programs, declarations and
definitions work fine.


VC++ has already proved that that is so. Your operating system of choice's
tools have not, but that does not mean that superior OSs' tools do not.

- Pete

You might also want to take a look at Eclipse and CDT.

 

[Petec]

Carl Ribbegaardh wrote:

You might also want to take a look at Eclipse and CDT.

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

 

[Ivan Vecerina]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the part of
the programmer who wants such features. .....
Since I still believe the features I listed are important to C++ I am making
an effort to return that discussion to the relevant technical matters. The
list is not intended to be exhaustive, and any item on it is subject to
refinement or even removal. It is only intended as a starting point for
further development of the ideas. Here is the list again:
//-----------------------------------------------------------
Will the IDE add the required headers and using declarations to your source
automatically?

I guess that this could be achieved by specifying, in the IDE, a list
of "consider for auto-include" headers. I'm not sure how practical this
would be in large projects with many libraries and overloads (this could
require quite some AI in the end), but basic support would be reasonable.

Will it give an indication of the exceptions thrown by a function call?

Well, this could be displayed based on throw-specifications (although
these have a different purpose and side-effects).

Will it display all the overloaded function signture with an indication of
the type of parameter it takes?

Existing IDEs (notably M$'s) do this already.

Does it filter according to context? That is, does it only show the
identifiers visible in the current scope when it provides code completion
(unless you ask for more)?

This feature conflicts somewhat with the first one (auto-include),
but does not seem unreasonable.

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

Some existing platforms (Apple's X-Code for MacOS X, IIRC) perform
continuous 'background compilation', and could rely on the compiler's
output for this.

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same level
as it does for the Standard Libraray and the implementation's API(s)?

You can if you rely on parsing standard code only, or publish a standard
way to annotate source code. The documentation system used by doxygen
(which in turn is similar to javadoc and other tools) is something I
would pick as a de factor standard (with maybe some formalization).

//-----------------------------------------------------------

Since there is some question as to whether such functionality would be
advantageous to C++, I will briefly address the matter. ....
The feature I have listed above have proven useful to developers working on
large-scale projects using a different programming language. The provide a
way for the programmer to leaverage the available resources more
efficiently and effectively.

It has been suggested that an effort to support such functionality by
ensuring the C++ implementation provides the necessary interface to the
development environment would somehow encumber C++ and make it
significantly less useful. Since, so far as I know, the requirements for
providing this interface have not been established, I find it difficult to
believe the impact on the language has been evaluated. Can anybody provide
a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?

Most of the features above can be implemented using the existing language.
The only extension would eventually be to standardize or recommend a code
annotation technique (e.g. doxygen).


The core problem is that parsing C++ is really complex, and this does
not facilitate the development of add-ons and utilities.
What might help is to have a public *reference implementation* of a C++
parser, with a standardized interface.
Existing tools tend to either rely on a modified GCC compiler, or
a home-made annotation system. But some, like doxygen, are rather
good at parsing and analyzing code structure, including overloads
and templates.

Actually, the output of a tool like doxygen could be used to implement
most of the features above...



my 2 cents,
Ivan

 

[Phlip]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the part of
the programmer who wants such features.

Absolutely. So is pair programming, test-driven development, requirements
analysis, keyboards, refactoring, etc. These are all crutches. Only
imbeciles would need them.

Unfortunately these ad hominem
rhetorts are frequently introduced into purely technical discussions on the
feasibility of supporting such functionality in C++. That usually serves
to divert the discussion from the technical subject to a discussion of the
character of the proponent of the new technology. This recently happened in
this newsgroup, and I have to confess, I took the bait and defended my
character instead of ignoring the irrelevant comments.

Well, this forum is the epitome of decorum. It's just us and

Since I still believe the features I listed are important to C++ I am making
an effort to return that discussion to the relevant technical matters. The
list is not intended to be exhaustive, and any item on it is subject to
refinement or even removal. It is only intended as a starting point for
further development of the ideas. Here is the list again:
//-----------------------------------------------------------
Will the IDE add the required headers and using declarations to your source
automatically?

Are you coming from Eclipse? Languages without C++ legacy implementation
architectures are very easy to parse, and languages with static typing are
easy to analyze for module dependencies.

C++ is not. But I'm more interested in a refactoring browser that _removes_
unneeded headers.

Will it give an indication of the exceptions thrown by a function call?

C++'s exception specification system, in Bjarne Stroustrup's opinion, is
broken. If you neglect a throw specifier, if that type throws the program
aborts. Static code analysis can't catch this risk, and refactoring can
easily move a new function under another one.

Will it display all the overloaded function signture with an indication of
the type of parameter it takes?

That would be easy. However, read my thread "The TEST_() macro". Visual
Studio's editor has a broken C++ parser, and it thinks my macro
instantiations are overloaded calls to a mysterious TEST_() function! Of
course the actual compiler interprets #define macros correctly, but the
editor would be as slow as the compiler to get its source browser right.

Does it filter according to context? That is, does it only show the
identifiers visible in the current scope when it provides code completion
(unless you ask for more)?

The next problem with code completion is it's a crutch that encourages
programmers to write instead of think. (I know I know - they said that about
trains, cars, phones, teledildonics, etc.)

You also need to ask for a "refactoring browser". In Eclipse, the Extract
Method command will not only convert selected statements into a call to a
new method, with the correct arguments and return type, but it will also
sweep nearby code looking for the same statements, and merge them too.
Refactoring allows designs to accomodate more features than all that can fit
in programmer's memory.

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

The most ambitious research in Test-Driven Development focuses on editors
that chronically run tests, at every relevant juncture, providing Zero
Button Testing. An editor might, for example, draw pink lines under failing
Test Cases, and under the Production Code they target, much the same way
word processors mark words not in their dictionaries.

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same level
as it does for the Standard Libraray and the implementation's API(s)?

But - that would defeat the purpose of Vendor Lockin! Only your editor's
vendor, and its vassal companies, may add a library!

Since there is some question as to whether such functionality would be
advantageous to C++, I will briefly address the matter. I have been
working with a project that has grown from something I could download and
build in a matter of minutes on 1997 computing technology (sparc 5, and P2
intel platforms), to a world class desktop user interface environment with
more than 40,000 lines of code. The collective libraries for all the
components of the KDE is huge. It is unreasonable to expect a programmer
to be aware of every feature of every class and function in these
libraries. And that fails to take into account the number of different
supporting libraries employed, or potentially employed by the developer.

This reminds me of my experiences on Linux, attempting to download and
compile the f---er.

The feature I have listed above have proven useful to developers working on
large-scale projects using a different programming language. The provide a
way for the programmer to leaverage the available resources more
efficiently and effectively.

There are ways to keep a code-base from growing large, and from appearing
large. Primarily, write many unit tests for all the features. They
self-document. An editor that flipped from a method to its test code would
be great.

It has been suggested that an effort to support such functionality by
ensuring the C++ implementation provides the necessary interface to the
development environment would somehow encumber C++ and make it
significantly less useful. Since, so far as I know, the requirements for
providing this interface have not been established, I find it difficult to
believe the impact on the language has been evaluated. Can anybody provide
a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?

#define macros differ based on /D arguments to the compiler.

 

[Phlip]

It's been proposed that IDE support be included as a formal consideration in
future versions of the Standard.

If you want C# you know where to get it. C++ is not for slinging out huge
quantities of application-level command and control code; it's for the
back-ends and libraries.

 

[Steven T. Hatton]

If you want C# you know where to get it. C++ is not for slinging out huge
quantities of application-level command and control code;

I never suggested that was my objective. Nor is it my objective.

it's for the back-ends and libraries.

Can you provide any reliable source to support that assertion? But, more to
the point what does the (incorrect) statement quoted above have to do with
this subject?

 

[Phlip]

Phlip wrote:

Can you provide any reliable source to support that assertion?

None whatsoever.

But, more to
the point what does the (incorrect) statement quoted above have to do with
this subject?

C++ is not for "command and control" code. That should be in a softer
language that favors the programmer, not the CPU. CnC code is the bulk of
modern development - entraining myriad business rules into flexible
enterprise solutions. Not dicking with smart pointers all day.

I agree that IDEs should refactor C++ automatically (if that's your point).
I challenge the bang/buck ratio against the big picture. Languages like Java
require refactoring editors to support their excessive cruft, and languages
like Ruby can leverage dynamic bonding between the editor and running source
code. Get with one of them instead of wishing the C++ industry in general
was something it was not.

 

[Mark A. Gibbs]

Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the part of
the programmer who wants such features. Unfortunately these ad hominem
rhetorts are frequently introduced into purely technical discussions on the
feasibility of supporting such functionality in C++. That usually serves
to divert the discussion from the technical subject to a discussion of the
character of the proponent of the new technology. This recently happened in
this newsgroup, and I have to confess, I took the bait and defended my
character instead of ignoring the irrelevant comments.

your case starts on shaky ground. you throw ad hominem around, but what
about ad ignorantiam (among others fallacies)? it is you who proposes
that these features are required considerations in the evolution of c++.
if you want them to be taken seriously, you should back them up with
more than a "i just feel it should be so".

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?

Will the IDE add the required headers and using declarations to your source
automatically?

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?

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?

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".

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.

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".

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?

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.

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.

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.

Will it give an indication of the exceptions thrown by a function call?

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

the problem really surfaces in the definition of template functions.
even given such a simplistic function as:

template <typename T>
T max(T const& a, T const& b)
{
return (a > b) ? a : b;
}

when a T is substituted, it is possible that this function may throw an
exception in two places. on operator<(T const&, T const&) or on the T
copy constructor.

how now, do you stipulate this when you do not know a) what T will be
used and b) what the exception specifications on T will be.

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.

Will it display all the overloaded function signture with an indication of
the type of parameter it takes?

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.

and of course, what about function templates and function-like macros?

i have already argued that neither the language nor the compiler should
be responsible for making code-completion easier, so i will not repeat
myself. this is a problem for ide writers to overcome.

Does it filter according to context? That is, does it only show the
identifiers visible in the current scope when it provides code completion
(unless you ask for more)?

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

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

the c++ language does not define error indicators or edit buffers. those
too, are ide writers' concerns.

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same level
as it does for the Standard Libraray and the implementation's API(s)?

that also, is an ide concern. remember, as far as the c++ standard is
concerned, there is no need even for a file structure (and some cases
where there is none). each hosting platform should and does have its own
way of specifying where libraries are. given that, it is now the
responsibility of the ide to understand those library location
specifications, and parse accordingly.

Since there is some question as to whether such functionality would be
advantageous to C++, I will briefly address the matter. I have been
working with a project that has grown from something I could download and
build in a matter of minutes on 1997 computing technology (sparc 5, and P2
intel platforms), to a world class desktop user interface environment with
more than 40,000 lines of code. The collective libraries for all the
components of the KDE is huge. It is unreasonable to expect a programmer
to be aware of every feature of every class and function in these
libraries. And that fails to take into account the number of different
supporting libraries employed, or potentially employed by the developer.

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.

The feature I have listed above have proven useful to developers working on
large-scale projects using a different programming language. The provide a
way for the programmer to leaverage the available resources more
efficiently and effectively.

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.

It has been suggested that an effort to support such functionality by
ensuring the C++ implementation provides the necessary interface to the
development environment would somehow encumber C++ and make it
significantly less useful. Since, so far as I know, the requirements for
providing this interface have not been established, I find it difficult to
believe the impact on the language has been evaluated. Can anybody provide
a reasoned, objective rationale for why the proposed support would
significantly and negatively impact C++?

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 being said, this is hardly the forum to do that. comp.lang.c++
discusses *using* the c++ language, not designing, changing or improving it.

mark

 

[Bob Hairgrove]

On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"

[snip]

Do you really mean to require standards-conforming C++ implementations
to supply an IDE with a minimum feature set going beyond a simple text
editor?

Hmmm...

//-----------------------------------------------------------  
Will the IDE add the required headers and using declarations to your source
automatically?  

What if you have a choice, for example, of different CRT and/or STL
libraries? I would want to be able to include them separately, or not
at all, which I can do very easily by defining symbols which I can
pass to the compiler, or perhaps by changing the operating system's
PATH environment variable. This, IMHO, is not something the IDE should
do automatically.

As to using declarations, I would NEVER want something as dangerous as
"using namespace xyz;" automagically added to any of my files!

For example, we have a custom "string" class which extends the
functionality of std::string. It is in its own namespace, so there is
never a problem as long as nowhere in our code there is a "using
namespace std;" directive -- not even in the CPP file (and certainly
not in any headers)! It should be entirely up to the developer to
decide where and how the "using namespace" (if at all) is declared.

What if I only want to forward declare a class name so that I can
declare a pointer to it without including the entire header? How would
I tell the IDE that I don't want to add that header file if it is
already in my project somewhere else?

However, I can see having automatic header inclusion in CPP files as a
big help ... as many times as I had to hunt down various header files.
However, the big problem was always either that I didn't know exactly
where they resided, or else they had been moved by someone else. So
how would my IDE find them if I couldn't find them myself??

Will it give an indication of the exceptions thrown by a function call?  

The language already has throw specifications. There has been much
discussion as to their usefulness; many people consider them even a
bit dangerous because they can "lie" about what is thrown or not
thrown.

Will it display all the overloaded function signture with an indication of
the type of parameter it takes?  

Most IDE's can already do this. I don't find it essential for most
projects -- after all, I can read the header files.

Does it filter according to context?  That is, does it only show the
identifiers visible in the current scope when it provides code completion
(unless you ask for more)?

(see above...)

When it shows error indicators in the edit buffer, is that a result of
compiler output, or is the code evaluated as you input it?

What is the advantage of character-by-character error parsing? When I
am cutting code, I don't want any interference with my typing until
*I* think it is time to try to compile somthing. I already had to turn
OFF code completion in the IDE I worked with in my last job because it
was too darned slow and always kicked in when I didn't want it (and
when I DID want it, it couldn't find half of the names I needed).

Can you add virtually any SDK such as the Xerces C++ to the available
resources and have the code completion and checking work at the same level
as it does for the Standard Libraray and the implementation's API(s)?
//-----------------------------------------------------------

All these things are certainly "nice to have"; however, I don't want
to be FORCED to use anything but vi or notepad if I don't want to use
it!

As to big projects (re: KDE, etc.) -- what about higher level things
such as UML, design requirements, etc.? The development process
certainly is not limited to the code.

If you are a developer who works mostly with COM+ and/or MFC, then the
M$ IDE will probably save you a lot of time. However, I wouldn't dream
of making it MANDATORY for someone to use, e.g., the M$ class wizard.

Every developer will eventually acquire the tools they need to
accomplish the job at hand. After all, that's part of our "metier", as
the French say.

 

[Phlip]

The language already has throw specifications. There has been much
discussion as to their usefulness; many people consider them even a
bit dangerous because they can "lie" about what is thrown or not
thrown.

Such lies abort your program.

 

[Steven T. Hatton]

On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"

[snip]

Do you really mean to require standards-conforming C++ implementations
to supply an IDE with a minimum feature set going beyond a simple text
editor?

Hmmm...

No, and I never suggested that, either.

What if you have a choice, for example, of different CRT and/or STL
libraries? I would want to be able to include them separately, or not
at all, which I can do very easily by defining symbols which I can
pass to the compiler, or perhaps by changing the operating system's
PATH environment variable. This, IMHO, is not something the IDE should
do automatically.

I really don't know how that relates to what I'm suggesting. Other than
your last statement. I find it a nusance to have to either remembr the
names and contents of hundreds of header files, or to look up the
information in documentation and then either transcirb, or copy and past it
into my code.

As to using declarations, I would NEVER want something as dangerous as
"using namespace xyz;" automagically added to any of my files!

"using namespace xyz;" is not a using declaration.

What if I only want to forward declare a class name so that I can
declare a pointer to it without including the entire header? How would
I tell the IDE that I don't want to add that header file if it is
already in my project somewhere else?

You simply don't invoke the auto inclusion.

However, I can see having automatic header inclusion in CPP files as a
big help ... as many times as I had to hunt down various header files.
However, the big problem was always either that I didn't know exactly
where they resided, or else they had been moved by someone else. So
how would my IDE find them if I couldn't find them myself??

Through the mechanism I've described. That is, as long as the resources are
referenced by your configuration. As I've already demonstrated previously,
the big difference between Java's approach and C++ is that Java uses a
single namespace for the analog to C++'s namespaces and headers. It is
that simplification that enables Java to provide a much more coherent
development environment.

Most IDE's can already do this. I don't find it essential for most
projects -- after all, I can read the header files.

It takes time to switch between documentation and the working source code.
This functionality is actually available in KDevelop if I use the
persistant class store to generate the tag database. It's also available
in Qt's designer, and with Emacs cedet (I believe).

What is the advantage of character-by-character error parsing? When I
am cutting code, I don't want any interference with my typing until
*I* think it is time to try to compile somthing. I already had to turn
OFF code completion in the IDE I worked with in my last job because it
was too darned slow and always kicked in when I didn't want it (and
when I DID want it, it couldn't find half of the names I needed).

I'm accustomed to better tools than that.

All these things are certainly "nice to have"; however, I don't want
to be FORCED to use anything but vi or notepad if I don't want to use
it!

Nothing I've said suggests you would be forced to use any of these features.

As to big projects (re: KDE, etc.) -- what about higher level things
such as UML, design requirements, etc.? The development process
certainly is not limited to the code.

JBuilder will generate UML for the working project. There are tools for
generating UML for C++ and other languages, or generating stubs based on
UML.
http://argouml.tigris.org/
http://uml.sourceforge.net/index.php
I don't find these overly useful. What JBuilder provides is useful because
it doesn't require I switch between tools, and it directly links into the
edit buffer where the source is, as well as to the other sources referenced
in the class diagrams.

If you are a developer who works mostly with COM+ and/or MFC, then the
M$ IDE will probably save you a lot of time. However, I wouldn't dream
of making it MANDATORY for someone to use, e.g., the M$ class wizard.

COM+? MFC? Those have something to do with Microsoft Windows don't they? I
never suggested any of these features should be manditory. I merely
suggested the C++ Standard should define an interface to the Standard
Library to access the declarations needed to provide that support.

 

[Kai-Uwe Bux]

Steven T. Hatton wrote:
[snip]

COM+? MFC? Those have something to do with Microsoft Windows don't they?
I
never suggested any of these features should be manditory. I merely
suggested the C++ Standard should define an interface to the Standard
Library to access the declarations needed to provide that support.

[/snip]

I do not understand why the standard needs to specify more in this area than
it does already. It requires that certain identifyers become visible to your
code by writing a line like #include<verctor>. Since an IDE could just know
about which identifyers are supposed to become visible that way, it does not
need a seperate interface to the standard libraries. But maybe, I am missing
something.


Best

Kai-Uwe Bux

 

[Steven T. Hatton]

Kai-Uwe Bux wrote:

Please don't include a request for an e-mail copy of my response. My usenet
client is not configured to send mail, and I really don't want it to be.
This is the first time I encountered this feature, but it is rather
invonvenient because KNode is trying to send mail when I reply.

I do not understand why the standard needs to specify more in this area
than it does already. It requires that certain identifyers become visible
to your code by writing a line like #include<verctor>. Since an IDE could
just know about which identifyers are supposed to become visible that way,
it does not need a seperate interface to the standard libraries. But
maybe, I am missing something.

I would need to carefully examine the Standard to determine if this is a
viable alternative. There may be some cases where the implementation can
use its own declarations. It also assumes the implementation is providing
all of the library. To my way of thinking, it makes more sense for the
implementation to provide this interface than to have the user do so.

Note to anybody familiar with javap: would that same functionality be useful
to C++?

I'm also thinking there should be a standardized means for any library
implementation to present its user interface to an IDE, or programmer or
whatever through the generation of the declarations describing it, as if
they were placed in header files.

 

[Steven T. Hatton]

None whatsoever.


C++ is not for "command and control" code. That should be in a softer
language that favors the programmer, not the CPU. CnC code is the bulk of
modern development - entraining myriad business rules into flexible
enterprise solutions. Not dicking with smart pointers all day.

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.

I agree that IDEs should refactor C++ automatically (if that's your
point). I challenge the bang/buck ratio against the big picture. Languages
like Java require refactoring editors to support their excessive cruft,

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.