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

From: Mark A. Gibbs (x_gibbsmark_at_rogesr.com_x)
Date: 06/06/04 

Date: Sun, 06 Jun 2004 16:17:00 GMT

Steven T. Hatton wrote:

> Mark A. Gibbs wrote:
>
>>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.

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

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

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

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

so you have to type the entire fully qualified name?

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

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

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

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

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

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

shall i go on?

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

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

? do you even read what i write?

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

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

//file win_something.hpp
typedef HANDLE something_handle;

//file linux_something.hpp
typedef void* something_handle;

//file something_something.hpp
typedef some_struct something_handle;

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

flexibility is nice.

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

bad?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

on the other hand:

" # comp.std.c++

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

mark

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: [LONG] Re: Why code completion and early error checking are needed
    ... >> interface declarations for the Standard Libraries. ... That is a language specefication issue. ... There is a significant difference between specifying how to fully implement ... IDE support for C++ and specifying the language in such a way as to remove ...
    (comp.lang.cpp)
  • Re: subroutine stack and C machine model
    ... They could have standardized that the language would be ... getting the facts wrong anyway. ... And the answer, for the Schildt books, is that they consistently produced ... to C start with the standard. ...
    (comp.lang.c)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... standard systems and a large number of nonstandard ones. ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)