Why code completion and early error checking are needed

Discussion in 'C++' started by Steven T. Hatton, Jun 5, 2004.

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


    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #1
    1. Advertising

  2. Steven T. Hatton wrote:

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

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jun 5, 2004
    #2
    1. Advertising

  3. Julián Albo wrote:

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

    My question was not about the standardization process.
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #3
  4. Steven T. Hatton

    Petec Guest

    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.
    >
    > 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
     
    Petec, Jun 5, 2004
    #4
  5. Petec wrote:

    > Steven T. Hatton wrote:


    >> 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)? //-----------------------------------------------------------


    >
    > 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.
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #5
  6. Steven T. Hatton

    Petec Guest

    Steven T. Hatton wrote:
    > Petec wrote:

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


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


    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
     
    Petec, Jun 5, 2004
    #6
  7. "Petec" <> wrote in message
    news:ALlwc.2324$...
    > Steven T. Hatton wrote:
    > > Petec wrote:

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

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

    >
    > 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.
    :)
     
    Carl Ribbegaardh, Jun 5, 2004
    #7
  8. Steven T. Hatton

    Petec Guest

    Carl Ribbegaardh wrote:
    <snip>
    >>
    >> 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.
    > :)


    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
     
    Petec, Jun 5, 2004
    #8
  9. "Steven T. Hatton" <> wrote in message
    news:...
    > 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
    --
    http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
     
    Ivan Vecerina, Jun 5, 2004
    #9
  10. Steven T. Hatton

    Phlip Guest

    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.


    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
    news:sci.math...

    > 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
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Jun 5, 2004
    #10
  11. Steven T. Hatton

    Phlip Guest

    Steven T. Hatton wrote:

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

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Jun 5, 2004
    #11
  12. Phlip wrote:

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


    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?
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #12
  13. Steven T. Hatton

    Phlip Guest

    Steven T. Hatton wrote:

    > Phlip wrote:


    > > it's for the back-ends and libraries.

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

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Jun 5, 2004
    #13
  14. [LONG] Re: Why code completion and early error checking are needed

    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.


    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
     
    Mark A. Gibbs, Jun 5, 2004
    #14
  15. On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"
    <> wrote:

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


    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 5, 2004
    #15
  16. Steven T. Hatton

    Phlip Guest

    Bob Hairgrove wrote:

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


    Such lies abort your program.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Jun 5, 2004
    #16
  17. Bob Hairgrove wrote:

    > On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"
    > <> wrote:
    >
    > [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.
    >>//-----------------------------------------------------------
    >>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.


    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.


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


    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.
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #17
  18. Steven T. Hatton

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Jun 5, 2004
    #18
  19. 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.
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #19
  20. Phlip wrote:

    > Steven T. Hatton wrote:
    >
    >> Phlip wrote:

    >
    >> > it's for the back-ends and libraries.

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


    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.
    --
    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
     
    Steven T. Hatton, Jun 5, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jason
    Replies:
    4
    Views:
    2,671
    jason
    Jun 2, 2005
  2. Madiba

    Python and Code Completion

    Madiba, Aug 11, 2003, in forum: Python
    Replies:
    1
    Views:
    339
    Simon Burton
    Aug 11, 2003
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    935
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,129
    Smokey Grindel
    Dec 2, 2006
  5. ziggs
    Replies:
    2
    Views:
    201
    Henry Robinson
    Apr 21, 2004
Loading...

Share This Page