Re: [LONG] Re: Why code completion and early error checking are needed

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 06/06/04 

Date: Sat, 05 Jun 2004 20:02:21 -0400

Mark A. Gibbs wrote:

>
> Steven T. Hatton wrote:
>> 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.

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

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?

#include <string>
 
> 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.

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

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

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.

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

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

-- 
STH 
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org  SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

Relevant Pages

  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)
  • Re: read and write
    ... the C standard says otherwise. ... which are also not a part of the language. ... of these libraries are part of "C", whatever it is, since they contain ... However, any hosted implementation is required to include the entire standard C library, and prior to the standard the first edition of K&R says "Chapter 7 describes the standard C I/O library, which provides a common interface to the operating system. ...
    (comp.lang.c)
  • Re: read and write
    ... the C standard says otherwise. ... which are also not a part of the language. ... of these libraries are part of "C", whatever it is, since they contain ... common interface to the operating system. ...
    (comp.lang.c)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... but having third party libraries to support the new ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ...
    (comp.lang.lisp)
  • Re: Forth and Unix -- history
    ... but modern Forths mostly drive them away. ... You have no justification to call STOIC retro nostalgia given that Standard Forth is pretty much stuck in the mid 70's. ... Users provide a large fraction of those libraries for C. Publicly. ... users must find the language comfortable in order to create such things. ...
    (comp.lang.forth)