Why code completion and early error checking are needed

[Phlip]

Re: Why code completion and early error checking are needed

Bob Hairgrove wrote:
[color=blue][color=green]
> >Will it give an indication of the exceptions thrown by a function call?[/color]
>
> 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.[/color]

Such lies abort your program.

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Bob Hairgrove wrote:
[color=blue]
> On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"
> <susudata@setid ava.kushan.aa> 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...[/color]

No, and I never suggested that, either.[color=blue][color=green]
>>//-----------------------------------------------------------
>>Will the IDE add the required headers and using declarations to your
>>source automatically?[/color]
>
> 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.[/color]

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.
[color=blue]
> As to using declarations, I would NEVER want something as dangerous as
> "using namespace xyz;" automagically added to any of my files![/color]

"using namespace xyz;" is not a using declaration.
[color=blue]
> 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?[/color]

You simply don't invoke the auto inclusion.
[color=blue]
> 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??[/color]

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.

[color=blue][color=green]
>>Will it display all the overloaded function signture with an indication of
>>the type of parameter it takes?[/color]
>
> Most IDE's can already do this. I don't find it essential for most
> projects -- after all, I can read the header files.[/color]

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).
[color=blue]
> 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).[/color]

I'm accustomed to better tools than that.

[color=blue]
> 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![/color]

Nothing I've said suggests you would be forced to use any of these features.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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

[Kai-Uwe Bux]

Re: Why code completion and early error checking are needed

Steven T. Hatton wrote:
[snip][color=blue]
> 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.[/color]
[/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<vercto r>. 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]

Re: Why code completion and early error checking are needed

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.
[color=blue]
> 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<vercto r>. 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.[/color]

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]

Re: Why code completion and early error checking are needed

Phlip wrote:
[color=blue]
> Steven T. Hatton wrote:
>[color=green]
>> Phlip wrote:[/color]
>[color=green][color=darkred]
>> > it's for the back-ends and libraries.[/color]
>>
>> Can you provide any reliable source to support that assertion?[/color]
>
> None whatsoever.
>[color=green]
>> But, more to
>> the point what does the (incorrect) statement quoted above have to do
>> with this subject?[/color]
>
> 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.[/color]

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.
[color=blue]
> 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,[/color]

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

[Petec]

Re: Why code completion and early error checking are needed

Steven T. Hatton wrote:[color=blue]
> Phlip wrote:
>[color=green]
>> Steven T. Hatton wrote:
>>[color=darkred]
>>> Phlip wrote:[/color]
>>[color=darkred]
>>>> it's for the back-ends and libraries.
>>>
>>> Can you provide any reliable source to support that assertion?[/color]
>>
>> None whatsoever.
>>[color=darkred]
>>> But, more to
>>> the point what does the (incorrect) statement quoted above have to
>>> do with this subject?[/color]
>>
>> 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.[/color]
>
> 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.[/color]

Please, stop trying to turn C++ into Java. There's a reason I use C++
instead of Java, because I absolutely hate the Java way of doing things.
If C++ loses its preprocessor, etc in C++ 20xx, I'm sticking with the last
real C++.
[color=blue]
>[color=green]
>> 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,[/color]
>
> 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.[/color]

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

- Pete

[Steven T. Hatton]

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

Mark A. Gibbs wrote:
[color=blue]
>
> Steven T. Hatton wrote:[color=green]
>> 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.[/color][/color]
[color=blue]
> 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?[/color]

No. You are incorrect.
[color=blue][color=green]
>> Will the IDE add the required headers and using declarations to your
>> source automatically?[/color]
>
> 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?[/color]

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.
[color=blue]
> 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?[/color]

If you type std::vector that means the one from the Standard. If you have a
using declaration in your code for indi::math::vec tor and nothing else to
inject the name vector, then it means your vector. If there is ambiguity,
then you need to resolve it manually.
[color=blue]
> 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.Vecto r".[/color]

And that demonstrates what is wrong with C++'s fragmented naming system.
[color=blue]
> 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?[/color]

#include <string>
[color=blue]
> 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.[/color]

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?
[color=blue]
> 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_includ er.h".[/color]

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.
[color=blue]
> 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?[/color]

I believe you are demonstrating what is wrong with the current C++ standard.
There is nothing valuable gained by this incoherence, and much lost.
[color=blue]
> 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.[/color]

Specifying a standard means of providing an interface to libraries including
the Standard Library should not preclude any of these porting mechanisms.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> Will it give an indication of the exceptions thrown by a function call?[/color]
>
> the c++ exception specification mechanism is sadly broken. it is also
> difficult to fix, even if one was inclined to rewrite the standard.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> Will it display all the overloaded function signture with an indication
>> of the type of parameter it takes?[/color]
>
> 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.[/color]

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.
[color=blue]
>
> those are the kinds of design questions you would expect to see in the
> development of an ide, not a language.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

If changes in the language specification can make the task significantly
easier then they should be made there.
[color=blue]
> 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.[/color]

That's fair enough. I never said I had all the solutions.[color=blue]
> 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.[/color]

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

[Steven T. Hatton]

Re: Why code completion and early error checking are needed

Petec wrote:
[color=blue]
> Steven T. Hatton wrote:[color=green]
>> Phlip wrote:
>>[color=darkred]
>>> Steven T. Hatton wrote:[/color][/color][/color]
[color=blue][color=green]
>> But, I'm not just talking about command and control code, or whatever
>> you want to call GUI code this week.[/color]
>
> Please, stop trying to turn C++ into Java. There's a reason I use C++
> instead of Java, because I absolutely hate the Java way of doing things.
> If C++ loses its preprocessor, etc in C++ 20xx, I'm sticking with the last
> real C++.[/color]

Why did Stroustrup suggest that the preprocesor should be replaced?
[color=blue][color=green]
>> 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.[/color]
>
> The language is not the IDE. It's perfectly possible to do what you wish
> in an IDE for C++ in its current state. Again, I don't know why you insist
> on ignoring VC++, but it demonstrates quite nicely that what you want is
> possible.[/color]

I'm not sure it really does provide what I've described. I gave you a list
of questions asking if it provided the features described therein, and you
did not address the questions.
--
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

[Petec]

Re: Why code completion and early error checking are needed

Steven T. Hatton wrote:[color=blue]
> Petec wrote:
>[color=green]
>> Steven T. Hatton wrote:[color=darkred]
>>> Phlip wrote:
>>>
>>>> Steven T. Hatton wrote:[/color][/color]
>[color=green][color=darkred]
>>> But, I'm not just talking about command and control code, or
>>> whatever you want to call GUI code this week.[/color]
>>
>> Please, stop trying to turn C++ into Java. There's a reason I use C++
>> instead of Java, because I absolutely hate the Java way of doing
>> things. If C++ loses its preprocessor, etc in C++ 20xx, I'm sticking
>> with the last real C++.[/color]
>
> Why did Stroustrup suggest that the preprocesor should be replaced?[/color]

I don't know, but I disagree with him.
[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>>
>> The language is not the IDE. It's perfectly possible to do what you
>> wish in an IDE for C++ in its current state. Again, I don't know why
>> you insist on ignoring VC++, but it demonstrates quite nicely that
>> what you want is possible.[/color]
>
> I'm not sure it really does provide what I've described. I gave you
> a list of questions asking if it provided the features described
> therein, and you did not address the questions.[/color]

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

- Pete

[Carl Ribbegaardh]

Re: Why code completion and early error checking are needed


"Petec" <x@x.x> wrote in message
news:48mwc.2365 $uX2.225@newsre ad2.news.pas.ea rthlink.net...[color=blue]
> Carl Ribbegaardh wrote:
> <snip>[color=green][color=darkred]
> >>
> >> 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
> >>[/color]
> >
> > You might also want to take a look at Eclipse and CDT.
> > :)[/color]
>
> 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[/color]
discarded[color=blue]
> it in favor of Windows, due to the fact that I like neither the[/color]
open-source[color=blue]
> philosophy or the style of tools.
>
> - Pete
>[/color]

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

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

/Carl

[Steven T. Hatton]

[OT]Eclipse CDT: was Re: Why code completion and early error checking are needed

Carl Ribbegaardh wrote:
[color=blue]
>
> "Petec" <x@x.x> wrote in message
> news:48mwc.2365 $uX2.225@newsre ad2.news.pas.ea rthlink.net...[color=green]
>> Carl Ribbegaardh wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>> > You might also want to take a look at Eclipse and CDT.[/color][/color][/color]
[color=blue]
> It was meant more as an extension of your post, targeted at the OP.
> :)
>
> Personally I prefer Windows and VC++ as I'm used to it and I work much
> faster there, but Eclipse looks/feels very good.[/color]
I know the feeling. I'm in the same situation regarding switching from
JBuilder to C++. Since the best thing going for C++ IDEs for Linux is
KDevelop, I am learning to program in C++ on builds of the latest CVS. It
can prove interesting.

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

[Julie]

Re: Why code completion and early error checking are needed

"Steven T. Hatton" wrote:[color=blue]
>
> Some people have suggested the desire for code completion and refined
> edit-time error detection are an indication <snip>[/color]

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

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

[Phlip]

Re: Why code completion and early error checking are needed

Petec wrote:
[color=blue]
> Please, stop trying to turn C++ into Java.[/color]

Man, that's such a great way to say it.
[color=blue]
> The language is not the IDE. It's perfectly possible to do what you wish in
> an IDE for C++ in its current state. Again, I don't know why you insist on
> ignoring VC++, but it demonstrates quite nicely that what you want is
> possible.[/color]

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

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

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

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

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

--
Phlip

[Phlip]

Re: Why code completion and early error checking are needed

Steven T. Hatton wrote:
[color=blue]
> 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.[/color]

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

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

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

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[E. Robert Tisdale]

Re: Why code completion and early error checking are needed

Julie wrote:
[color=blue]
> All of what you want and more can be easily provided
> if the source is (parsed and) stored in a _database_
> as opposed to the ancient file-based structure currently used.
>
> So, my recommendation is
> to look at changing the fundamental storage unit
> and the other stuff comes naturally.
> Otherwise, it come at a very high price w/file-based code.[/color]

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