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 67  4129 
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
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 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 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 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" <x@x.x> wrote in message
news:AL****************@newsread2.news.pas.earthli nk.net... 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 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:k5********************@speakeasy.net... 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
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/bi...UserInterfaces
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/bi...UserInterfaces
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 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/bi...UserInterfaces
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
On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"
<su******@setidava.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... //-----------------------------------------------------------**
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 No**********@Home.com
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/bi...UserInterfaces
Bob Hairgrove wrote: On Sat, 05 Jun 2004 08:41:28 -0400, "Steven T. Hatton"
<su******@setidava.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...
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 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 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
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 wrote: 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.
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++.
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.
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
Mark A. Gibbs wrote:
Steven T. Hatton wrote: Some people have suggested the desire for code completion and refined
edit-time error detection are an indication of incompetence on the part
of
the programmer who wants such features. Unfortunately these ad hominem
rhetorts are frequently introduced into purely technical discussions on
the
feasibility of supporting such functionality in C++. That usually serves
to divert the discussion from the technical subject to a discussion of
the character of the proponent of the new technology. This recently
happened in this newsgroup, and I have to confess, I took the bait and
defended my character instead of ignoring the irrelevant comments.
frankly what you feel, what i feel, and what anyone else feels is
irrelevant. if you have a case to present, please present that case on
its own merits. am i correct in assuming that your thesis is that one of
the guiding principles in the evolution of the c++ language should be
the ease with which machines can deduce code given partial samples?
No. You are incorrect.
Will the IDE add the required headers and using declarations to your
source automatically?
the problem with this is that ide must first be able to assume
intention. even in more simplified cases, such as java, a lot of
information is needed to make safe assumptions. for example, on first
appearance of a type name, the compiler has to search all known
libraries to find the type declaration. this is a tedious but trivial
process if there is only one matching type, but what if there are
duplicated type names?
Google only takes a few seconds to search the entire internet. It shouldn't
be that hard to build useful indexes of the available resources. Currently
it is not possible to rely on the implementation providing interface
declarations for the Standard Libraries.
for example, i type "Vector". does that mean the standard vector
container, int namespace java.util? or my own 3d vector class in
indi.math?
If you type std::vector that means the one from the Standard. If you have a
using declaration in your code for indi::math::vector and nothing else to
inject the name vector, then it means your vector. If there is ambiguity,
then you need to resolve it manually.
in java's simplified world the solution to such a problem is simply to
offer a choice of all candidates. but c++ has special challenges. in
java, the required header to import is well-defined and can be easily
extrapolated from the type name, or even better, from the
fully-qualified typename. you want "Vector" in "java.util"? it doesn't
take a complicated algorithm to generate "import java.util.Vector".
And that demonstrates what is wrong with C++'s fragmented naming system.
but in c++ the header to import is not well-known, not only because no
part of it can be deduced from the type name, but because the possiblity
of nesting includes within other includes. for example, consider
std::string. obviously the correct include in this case is <string>, but
indulge me momentarily. imagine you have thousands of headers for
classes that use strings internally. how is the compiler to know that
you specifically want <string> and do not wish to come by string by some
other means?
#include <string>
it cannot be argued that programmers will only want to include the
actual base declaration header for a type. it may be by design that
<string> is not included directly, for several reasons, including
precompiled headers and the potential to transparently replace usage of
std::string in the library with something_else::string at some future
date.
I don't see how this has any bearing on the subject. Are you suggesting
names should be introduced into your program through indirect inclusion?
furthermore it may be that while "some_type" is actually declared in
"some_type.h", the intention was that "some_type.h" should never be
included in client code directly. take the classic case of <windows.h>.
the definition of type LPTSTR is given a default value in <windows.h>
that can be overidden by the use of precompiler macros. across the scope
of a project it would be expected that the definition is consistent, but
this may not be the case if <windows.h> is included directly instead of
"windows_includer.h".
I can't prevent bad design. But there is certainly room in what I am
proposing for the identification of exported headers to be included by
users of the library, and internal headers intended for use only by library
developers. That actually strengthens my position.
you could argue that programmer oversight would properly direct the
ide's assumptions, but if the programmer has to read the documentation
and determine the proper include files themself, what gain is there in
having the ide attempt a guess? the cost is the time spent parsing what
may be a massive source pool (or the disk-space cost if it is
pre-parsed), the pros are.... what? forcing the programmer to read
documention he should be reading anyway?
I believe you are demonstrating what is wrong with the current C++ standard.
There is nothing valuable gained by this incoherence, and much lost.
so the ide will have a job of it. well then, maybe changes are needed
elsewhere, right?
even if it were possible to correct this problem by a reasonable
revision to the language standard (which i doubt), i do not believe that
it should be applied. it would be limiting to the power and flexibility
of the language to have certain naming and declaration standards
imposed. unlike a language such as java, c++ is multi-platform capable -
the task of writing portable code demands the ability to be flexible
with type declarations.
Specifying a standard means of providing an interface to libraries including
the Standard Library should not preclude any of these porting mechanisms.
within a given coding team you could enforce standards that facilitate
easy machine analysis, and project leaders are welcome to do so.
personally, i am opposed to tying programmers hands with more rules than
are absolutely necessary - it limits efficiency to have to conform to
potentially unnatural rules, stifles creativity, and may preclude some
powerful problem solutions.
I have never driven on the streets of Rome Italy. I believe, however, the
city provides a good example of what happens when there are very few
restrictions on how people drive. I base this on what my Italian doctor
told me while performing out patient surgery.
so the onus is back on the ide to somehow handle this. i don't pretend
it will be easy - c++ is a two-pass parsed language with a one
definition rule, but no one declaration rule. can it be done? oh most
probably. but it should be done by the ide, not by limiting the power
and flexibility of the language, or by hampering the programmers trying
to use it.
If anything, I believe the exercise of specifying how this interface
mechanism can be provided will reveal many things that should and can be
changed for the better without negatively impacting the language.
Will it give an indication of the exceptions thrown by a function call?
the c++ exception specification mechanism is sadly broken. it is also
difficult to fix, even if one was inclined to rewrite the standard.
There will be future modifications to the standard which can include such
changes. I believe such things can be corrected if people are willing to
drop some legacy code from the support requirements.
in my mind, this and complications due to inheritance preclude changes
to the language directly, so the task for implementing this feature will
fall at the feet of the ide writer.
I am inclined to believe the difficulties presented to IDE developers reveal
defects in the language. I'm also of the opinion that there are probably
some key points where changes to a certain part of the language will lead
to the solution of many problems.
Will it display all the overloaded function signture with an indication
of the type of parameter it takes?
well now, you've opened up a whole new kettle of fish here. i
deliberately avoided mentioning functions when i was discussing
including the correct headers for types because the problem is even
worse there. even within the bounds of the standard library, there can
be several answers to the question of which file to include given a
specific function signature.
now that you're talking about considering not only multiple declarations
of a single function, but also potentially multiple signature for
multiple overloads, the complexity is increasing by leaps and bounds.
I'm not sure what your getting at here. I'm not suggesting the IDE solve
all ambiguities without user intervention. I also expect some things
involving templates will need to be taken step by step.
those are the kinds of design questions you would expect to see in the
development of an ide, not a language.
The question was about an IDE. I was trying to determine if any IDEs
currently provide the kind of functionality I'm interested in. If they do,
then at least I know it's possible.
i feel your pain. i am a lone wolf developer and hobbyist c++ coder. i
do not have the luxury of being a programmer that can choose to
specialize in one library, or even one aspect of program development. i
agree that the size of many libraries is daunting, and expecting anyone
to know all the capabilities and gotchas associated with any particular
api is ludicrous.
but these are not problems with the standard, they are concerns of the
library writer. even if the language were to make it laughably simple to
maniuplate huge libraries, the question remains as to whether making a
huge library is a good thing. a good library would be simple and
modular, so that for any given problem you would know where to look for
the solution set, and the size of that solution set is manageable.
the argument that c++ should have built-in facilities to support huge,
cumbersome libraries because they exist and must be used is no more or
less valid than the argument that built-in facilities to support huge,
monolithic should not be added to the c++ language because the c++
language is the way it is and must be used as is.
I don't believe you are getting my point. It should provide a standard
means of structure libraries of any size. I don't believe this is all the
compicated.
The feature I have listed above have proven useful to developers working
on
large-scale projects using a different programming language. The provide
a way for the programmer to leaverage the available resources more
efficiently and effectively.
and there is no rational argument that i can imagine for why they should
not be developed and used - or at least available. the only question
here is where the burden for the development of these feature should be
placed.
If changes in the language specification can make the task significantly
easier then they should be made there.
you make a good point. my argument exists only of glaring generalities.
but then, no-one has provided a valid proposal for how these
requirements could be met on any given c++ implementation, let alone all
of them. i will provide a reasoned, objective rationale for why the
proposed support would significantly impact c++ - positively, negatively
or both - when you provide a reasonable proposal of what this support
will be.
That's fair enough. I never said I had all the solutions. that being said, this is hardly the forum to do that. comp.lang.c++
discusses *using* the c++ language, not designing, changing or improving
it.
The FAQ specifically states that the newsgroup is open to discussion of
"future directions" for C++.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Petec wrote: Steven T. Hatton wrote: Phlip wrote:
Steven T. Hatton wrote:
But, I'm not just talking about command and control code, or whatever
you want to call GUI code this week.
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++.
Why did Stroustrup suggest that the preprocesor should be replaced? 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.
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.
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
Steven T. Hatton wrote: Petec wrote:
Steven T. Hatton wrote: Phlip wrote:
Steven T. Hatton wrote: But, I'm not just talking about command and control code, or
whatever you want to call GUI code this week.
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++.
Why did Stroustrup suggest that the preprocesor should be replaced?
I don't know, but I disagree with him.
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.
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.
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.
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
"Petec" <x@x.x> wrote in message
news:48****************@newsread2.news.pas.earthli nk.net... 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
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
Carl Ribbegaardh wrote:
"Petec" <x@x.x> wrote in message
news:48****************@newsread2.news.pas.earthli nk.net... Carl Ribbegaardh wrote:
> You might also want to take a look at Eclipse and CDT.
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.
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
"Steven T. Hatton" wrote:
Some people have suggested the desire for code completion and refined
edit-time error detection are an indication <snip>
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.
Petec wrote: Please, stop trying to turn C++ into Java.
Man, that's such a great way to say it.
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.
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
Steven T. Hatton wrote: 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.
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/bi...UserInterfaces
Julie wrote: 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.
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.
Steven T. Hatton wrote; Phlip wrote: 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.
You have a lot to learn. Let's start with architecture.
GUI code is supposed to be as thin as possible, with its controllers pulled
out into GUI-free layers.
The bulk of the code out there is the logic between the database and the
GUI. That code should be in a soft language, to enable the kinds of tool
support you want to add to C++.
So if GUI code is thin, and depends on form painters, then its code could
easily be in C++, as a simple pass-thru to the logical layers. And, again,
the bulk of the project would not be there, so tool support is not so
important.
Do yourself a favor: Identify a real world problem that you want your
enhanced IDE to help you write C++ to solve.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Phlip wrote: Steven T. Hatton wrote;
Phlip wrote:
But, I'm not just talking about command and control code, or whatever you
want to call GUI code this week.
You have a lot to learn. Let's start with architecture.
GUI code is supposed to be as thin as possible, with its controllers
pulled out into GUI-free layers.
Oh you mean the abstract user interface, or AUI as I was calling it back in
the 90's?
The bulk of the code out there is the logic between the database and the
GUI. That code should be in a soft language, to enable the kinds of tool
support you want to add to C++.
Where do you come up with these absurdities? But I've been told that
support can, and has already been, implemented for C++. I've also been
told, in the context of the same discussion that it is impossible.
So if GUI code is thin, and depends on form painters, then its code could
easily be in C++, as a simple pass-thru to the logical layers.
So, you are saying C++ is not a good programming language for writing the
business logic parts of an application? You earlier asserted that C++ is
good for writing "libraries". I'm looking at the source for one of the
largest C++ projects in the world, and there sure is a lot of front-end
stuff in libraries.
And, again,
the bulk of the project would not be there, so tool support is not so
important.
http://www.research.att.com/~bs/bs_f...working-on-now
"What are you working on now?
"A better FAQ :-)"
"Seriously, I'm looking for fundamental ways of improving the tools and
techniques we use to build large real-world systems."
Do yourself a favor: Identify a real world problem that you want your
enhanced IDE to help you write C++ to solve.
That list is already huge.
--
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
Phlip wrote: Petec wrote:
Please, stop trying to turn C++ into Java.
Man, that's such a great way to say it.
Then you'll be happy to know this:
Concurrency: I'd like to see a library supporting threads and a related
library supporting concurrency without shared memory. [Like Java has]
Reflection: I'd like to see something like that supported through a library
defining the interface to extended type information.[Like Java has]
Persistence: I'd like to see some support in the Standard Library, probably
in connection with the extended type information, but I don't currently
have any concrete suggestions.[Like Java has]
Regular expression matching: I'd like to see a pattern-matching library in
the standard. [Like Java has]
Garbage collection: I'd like to see the C++ standard explicitly acknowledge
that it is an acceptable implementation technique for C++, specifying that
"concealed pointers" can be ignored and what happens to destructors for
collected garbage. [Like Java has]
GUI: It would be nice to have a standard GUI framework, but I don't see how
that could be politically feasible. ["Politically feasible"? Who would try
to stop that?]
Platform-independent system facilities: I'd like to see the Standard Library
provide a broader range of standard interfaces to common system resources
(where available), such as directories and sockets. [Like Java has]
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.
You'd need a lexer:
http://developer.kde.org/documentati...lassLexer.html
You'd need a parser:
http://developer.kde.org/documentati...assParser.html
Something to manage the parser scheduling:
http://developer.kde.org/documentati...rser_8cpp.html
You'd need an abstract syntax table:
http://developer.kde.org/documentati.../classAST.html
You'd need something to actually do the code completion:
http://developer.kde.org/documentati...ompletion.html
You'd need a class to do the colorization for syntax highlighting.
http://developer.kde.org/documentati...Colorizer.html
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.
You are speaking from a very limited perspective, and are quite wrong about
what people are likely to create.
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.
You really have no idea of the kinds of things I've been working with.
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?
--
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
Phlip wrote: Petec wrote:
Please, stop trying to turn C++ into Java.
Man, that's such a great way to say it.
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.
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.
VB 5 and 6 did it...
- Pete
Petec wrote; Phlip wrote: 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.
VB 5 and 6 did it...
If VB had been a very complex language with a legacy implementation, they
could not have.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Steven T. Hatton wrote: Oh you mean the abstract user interface, or AUI as I was calling it back
in the 90's?
Oh, my. I'm just the young whippersnapper, and the senior STH has been
working since the 90s...
Thanks, I needed that!
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
"E. Robert Tisdale" wrote:
Julie wrote:
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.
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.
Right! at a very high price, like I said.
"Steven T. Hatton" wrote:
Phlip wrote:
Petec wrote:
Please, stop trying to turn C++ into Java.
Man, that's such a great way to say it.
Then you'll be happy to know this:
Concurrency: I'd like to see a library supporting threads and a related
library supporting concurrency without shared memory. [Like Java has]
Reflection: I'd like to see something like that supported through a library
defining the interface to extended type information.[Like Java has]
Persistence: I'd like to see some support in the Standard Library, probably
in connection with the extended type information, but I don't currently
have any concrete suggestions.[Like Java has]
Regular expression matching: I'd like to see a pattern-matching library in
the standard. [Like Java has]
Garbage collection: I'd like to see the C++ standard explicitly acknowledge
that it is an acceptable implementation technique for C++, specifying that
"concealed pointers" can be ignored and what happens to destructors for
collected garbage. [Like Java has]
GUI: It would be nice to have a standard GUI framework, but I don't see how
that could be politically feasible. ["Politically feasible"? Who would try
to stop that?]
Platform-independent system facilities: I'd like to see the Standard Library
provide a broader range of standard interfaces to common system resources
(where available), such as directories and sockets. [Like Java has]
With the exception of the last item, what you are asking for sounds like C# --
I presume that you are (programmatically) familiar w/ that?
Phlip wrote: Petec wrote;
Phlip wrote:
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.
VB 5 and 6 did it...
If VB had been a very complex language with a legacy implementation,
they could not have.
I can't think of a language more encumbered with legacy junk than VB6.
- Pete
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
Phlip wrote: Steven T. Hatton wrote:
Oh you mean the abstract user interface, or AUI as I was calling it back
in the 90's?
Oh, my. I'm just the young whippersnapper, and the senior STH has been
working since the 90s...
Thanks, I needed that!
No. That's just when I came up with a model for designing a project with a
conscious separation of UI and AUI. It actually has four layers. But the
two that are immediately relevant are the GUI and the AUI. I've been
working since the 1970s. If you must know.
--
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 wrote: "Steven T. Hatton" wrote:
Phlip wrote:
> Petec wrote:
>
>> Please, stop trying to turn C++ into Java.
>
> Man, that's such a great way to say it.
Then you'll be happy to know this:
Concurrency: I'd like to see a library supporting threads and a related
library supporting concurrency without shared memory. [Like Java has]
Reflection: I'd like to see something like that supported through a
library defining the interface to extended type information.[Like Java
has]
Persistence: I'd like to see some support in the Standard Library,
probably in connection with the extended type information, but I don't
currently have any concrete suggestions.[Like Java has]
Regular expression matching: I'd like to see a pattern-matching library
in the standard. [Like Java has]
Garbage collection: I'd like to see the C++ standard explicitly
acknowledge that it is an acceptable implementation technique for C++,
specifying that "concealed pointers" can be ignored and what happens to
destructors for collected garbage. [Like Java has]
GUI: It would be nice to have a standard GUI framework, but I don't see
how that could be politically feasible. ["Politically feasible"? Who
would try to stop that?]
Platform-independent system facilities: I'd like to see the Standard
Library provide a broader range of standard interfaces to common system
resources (where available), such as directories and sockets. [Like Java
has]
With the exception of the last item, what you are asking for sounds like
C# -- I presume that you are (programmatically) familiar w/ that?
I'm sorry, I was very tired when I posted that and neglected to attribute
the quotes. Thoes are Stroustrup's words, not mine.
C#? I've looked at it briefly. The monodoc thing that came with it is kind
of nifty.
--
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
Mark A. Gibbs wrote:
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.
I didn't care to elabourate my guiding principals. From the subject of this
thread, it should be clear where my objectives lie.
I grow weary of being told how I should behave myself.
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.
No. That is a language specefication issue. The C++ Standard does not
require the Standard Library provide any kind of retrievable representation
of its interface. I believe this to be an ommision due to error.
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?
If you want the the unique representation of the name in a scope where it is
otherwise ambiguous, yes. That's how the language works.
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?
No. Why would you think that? If you are basing that on the Java model,
then you do not correctly understand Java. But as far as header files and
implementation files go. I do not believe the C++ Standard specifies
anything called a header file. Perhaps I should say conventional usage
employs a fragmented naming system, and the Standard implicitly presupposes
its use.
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?
For any of that to be relevant, your assumption would need to be correct. It
isn't.
second, you would be assuming certain capabilities on the file system
being used for c++ development.
No. I would be placing requierments on the naming system used to identify
resources used by the C++ implementation.
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?
To what end?
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?
I don't really care to share more of my design ideas on this matter, at this
point.
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?
To the extent that what you wrote made senes, I gave the best answer
possible.
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.
Some people believe the use of goto is a good solution to branching
situations for the same reason.
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?
If I have a hundred or so header files for a toolkit, and they have a
coherent, rational naming scheme that corresponds to what they hold, once I
understand how the naming scheme works, and how the names of classes
correspond to functionality, there is often no need to consult the
documentation for every individual component of the toolkit. Furthermore,
it is often the case that names can be a bit hard to remember exactly. Was
that XHBoxSlider or XHSliderBox? Was that contained in <xhbox.h> or
<xbox.h>?
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.
Why should I? Actually, I learned something last night about a likely
future direction of C++ which is forcing me to rethink a lot of this. It's
potentially a very positive direction as long as Stroustrup can keep the
dogs at bay.
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.
I really don't know what you mean by "power". The fact that C++ presents so
many obstacles to ease of use is a weakness. Java seems, from the evidence
I've seen, to be as portable, or more portable than C++.
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.
That is more easily said than done. The C++ community has a tendency to
reject ideas out of hand without considering their merit.
"willing to drop some legacy code"? perhaps. what code, specifically?
show your work.
Why should I? What have you done to earn it?
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.
I'm actually more optimistic now that ever.
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.
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
unnecessary obstacles to implementing such support.
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++?"
Please consult this relevant reference and see if you can figure it out for
yourself:
http://www.bartleby.com/64/1.html
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.
I don't care to share my thoughts on this matter.
perhaps. we do have a committee to make these decisions you know. all
you need to do is say what changes for what benefits.
I've made some suggestions. I may make more. But why should I? 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
Read the whole FAQ. People tend to view that particular item in isolation
and therefore draw incorrect conclusion.
--
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 wrote: I didn't care to elabourate my guiding principals. From the subject of this
thread, it should be clear where my objectives lie.
I grow weary of being told how I should behave myself.
[snip]
No. That is a language specefication issue. The C++ Standard does not
require the Standard Library provide any kind of retrievable representation
of its interface. I believe this to be an ommision due to error.
[snip]
No. Why would you think that? If you are basing that on the Java model,
then you do not correctly understand Java. But as far as header files and
implementation files go. I do not believe the C++ Standard specifies
anything called a header file. Perhaps I should say conventional usage
employs a fragmented naming system, and the Standard implicitly presupposes
its use.
[snippety]
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?
For any of that to be relevant, your assumption would need to be correct. It
isn't.
[snip]
shall i go on?
To what end?
[clip]
I don't really care to share more of my design ideas on this matter, at this
point.
[trim]
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?
To the extent that what you wrote made senes, I gave the best answer
possible.
[slash]
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.
[...]flexibility is nice.
Some people believe the use of goto is a good solution to branching
situations for the same reason.
[burn]
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?
If I have a hundred or so header files for a toolkit, and they have a
coherent, rational naming scheme that corresponds to what they hold, once I
understand how the naming scheme works, and how the names of classes
correspond to functionality, there is often no need to consult the
documentation for every individual component of the toolkit. Furthermore,
it is often the case that names can be a bit hard to remember exactly. Was
that XHBoxSlider or XHSliderBox? Was that contained in <xhbox.h> or
<xbox.h>?
[squish]
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.
Why should I? Actually, I learned something last night about a likely
future direction of C++ which is forcing me to rethink a lot of this. It's
potentially a very positive direction as long as Stroustrup can keep the
dogs at bay.
[buzz]
I really don't know what you mean by "power". The fact that C++ presents so
many obstacles to ease of use is a weakness. Java seems, from the evidence
I've seen, to be as portable, or more portable than C++.
there is absolutely no basis in fact for that last statement. none. if
that wasn't a complete fabrication, then you are sorely confused about
java, c++ or both.
errr, i meant
[snip]
That is more easily said than done. The C++ community has a tendency to
reject ideas out of hand without considering their merit.
[swipe]
"willing to drop some legacy code"? perhaps. what code, specifically?
show your work.
Why should I? What have you done to earn it?
[compress]
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.
I'm actually more optimistic now that ever.
[snip?]
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
unnecessary obstacles to implementing such support.
[snip]
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++?"
Please consult this relevant reference and see if you can figure it out for
yourself:
http://www.bartleby.com/64/1.html
[he he snip]
I don't care to share my thoughts on this matter.
[snip!] perhaps. we do have a committee to make these decisions you know. all
you need to do is say what changes for what benefits.
I've made some suggestions. I may make more. But why should I?
[snip] 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
Read the whole FAQ. People tend to view that particular item in isolation
and therefore draw incorrect conclusion.
[snip?]
he he he, man, you've totally made my weekend ^_^. let me see if i get
this straight: you want to change c++ because you *think* it's wrong,
and you *believe* that it shouldn't be a problem for people if tested
and debugged code they have suddenly stops to work for the sake of a
feature that tens of thousands of programmers have gotten by without.
but no-one *really* understands what it is you're trying to do, and even
if they did they would oppose it because the "c++ community" is full of
backwards-minded assholes who may only be contained by the might of
bjarne stroustrup. as for me personally, not only do i have no chance of
understanding, appreciating or even helping with your crusade, i'm not
even worthy of the time you would have to spend explaining it because i
lack the intellectual capacity to grasp java, c++, english grammar, or
the metaphysical connection between your italian brain surgeon and c++
syntax checking. did i miss anything?
oh, and despite the fact that the faq explictly, clearly and
categorically states that this conversation is off-topic, somehow,
somewhere buried deep in the faq is an exception that allows for quote
future directions unquote, though you will not tell us where because we
will probably have more fun wasting our precious time looking for it
ourselves, and thus you are free to post just about any rambling
nonsense you so please.
he he he ^_^ and of course, despite the fact that you haven't described,
defended or proved your position at all, you're nonetheless supremely
confident that all discussion is only serving to provide further
evidence in favour of your case, and are - of course - ever optimistic
that one day the bourgeois dogs will be enlighted.
^_^ good luck on that dude, i don't want to take up your precious time
any further seeing as there's no chance i have anything to offer anyway.
he he he
mark
Julie wrote: "E. Robert Tisdale" wrote:
Julie wrote:
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.
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.
Right! at a very high price, like I said.
No. It isn't at all difficult or expensive.
Mark A. Gibbs wrote: there is absolutely no basis in fact for that last statement. none. if
that wasn't a complete fabrication, then you are sorely confused about
java, c++ or both.
errr, i meant
Well, I haven't used it, but I've seen it. AFAIK, the Java compiler is
porting to the major platforms. Just by the number of libraries that
compile with the default distribution, I'm pretty convinced that Java code
compile wll on multiple platforms.
--
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
E. Robert Tisdale wrote: Julie wrote:
"E. Robert Tisdale" wrote:
Julie wrote:
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.
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.
Right! at a very high price, like I said.
No. It isn't at all difficult or expensive.
It doesn't take long to build an index of say, Xerces C++'s include files
for KDevelop, using the persistant class store feature. I'll have to take
the middle ground as far as Julie's code in databases ideas go. To my way
of thinking, the file system /is/ a data repository, and the structure is a
resource to leverage in the same sense the facilities of an RDBMS or other
data store can be.
That's why I think the use of filesystem names to correspond with namespace
names is a good idea. If such an arrangement were standardize, it could,
and should be done in terms of namespaces, not explicitly file systems.
I'm going to attempt to establish a system that works like this in the
context of KDevelop, regardless of whether is becomes part of, or
associated with, the Standard.
As for the functionality I've described being available, are you talking
about VC++? I don't believe what I've described is a trivial exercise,
especially with C++. If you know how to accomplish these things easily,
please help out the KDevelop team.
--
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" wrote: C#? I've looked at it briefly. The monodoc thing that came with it is kind
of nifty.
Take a deeper look. It is a high-powered modern language w/ a billion-dollar
backing and a lot of features.
"E. Robert Tisdale" wrote:
Julie wrote:
"E. Robert Tisdale" wrote:
Julie wrote:
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.
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.
Right! at a very high price, like I said.
No. It isn't at all difficult or expensive.
Well then perhaps you would care to elaborate on why these features have been
poorly implemented, supported, and basically only recent (somewhat spotty)
additions to IDEs -- the modern IDE has been around since the early 90's. I'll
stick w/ my opinion that it is due to the cost to implement and the relative
cost of the feature (i.e. pre-processing/parsing/pre-compiling performance
issues on the user's machine).
Regardless, along w/ the features STH was posting about, (parsed) code in a
database offers a *magnitude* (if not more) capabilities to code development
that could ever be provided by simple text-based files and their supporting
editors. I'm not trying to sell anything here, and I don't purport to be the
originator of the idea, but in the future, code *will* be in a database, pure
and simple. Increasing project complexity mandates it. This thread has been closed and replies have been disabled. Please start a new discussion. |
