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
Jul 22 '05
67  4180 
Julie wrote: "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.
Looking over some of the metrics, I get the sense that C++ has a significant
edge over C# in expressive power per line of code (whatever that's worth)
and raw performance. IMO C++ has two very serious problems, the C
preprocessor, and people who insult others for suggesting the former is a
problem. There are other problems such as exceptions. That can probably
be fixed in a forward-looking sense, but won't solve the problem of
existing C++ code using the flawed exception mechanism.
I came across this comparison between C++ and C#. It seems reasonably
informed and objective from skimming it: http://www.andymcm.com/csharpfaq.htm#1.5
I believe C++ could, and should look a whole lot different than it currently
does. Removing on character, and the syntax associated with it would be
the best thing that every happened to C++. What C++ could do without is
the '#' symbol. That probably won't happen in the short term. But there
is a good chance there will be means of confining the C preprocessor to the
few places where legacy usage still prevails.
I have an idea for how to accomplish the same thing headers do now with pure
C++ code. There's one significant qualification to that which would
require a change in the Standard to address. On that, more later.
--
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:
Julie wrote:
"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.
Looking over some of the metrics, I get the sense that C++ has a significant
edge over C# in expressive power per line of code (whatever that's worth)
and raw performance. IMO C++ has two very serious problems, the C
preprocessor, and people who insult others for suggesting the former is a
problem. There are other problems such as exceptions. That can probably
be fixed in a forward-looking sense, but won't solve the problem of
existing C++ code using the flawed exception mechanism.
I came across this comparison between C++ and C#. It seems reasonably
informed and objective from skimming it:
http://www.andymcm.com/csharpfaq.htm#1.5
I believe C++ could, and should look a whole lot different than it currently
does. Removing on character, and the syntax associated with it would be
the best thing that every happened to C++. What C++ could do without is
the '#' symbol. That probably won't happen in the short term. But there
is a good chance there will be means of confining the C preprocessor to the
few places where legacy usage still prevails.
I have an idea for how to accomplish the same thing headers do now with pure
C++ code. There's one significant qualification to that which would
require a change in the Standard to address. On that, more later.
--
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
Again, with the exception of one of your previous items ("Platform-independent
system facilities") and that C# is compiled to an intermediate code, everything
that you are talking about (GC, no pre-processor, concurrency, etc.) are in
C#.
You should really spend more time examining C# for yourself (i.e. get a
compiler and write some code for a couple of weeks) rather than try and
advocate such changes to C++.
Think about it for a minute, if you added/removed the things that you are
advocating, you would have a completely different language that would be very
close to C#.
Julie wrote: "Steven T. Hatton" wrote:
Julie wrote:
> "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.
Looking over some of the metrics, I get the sense that C++ has a
significant edge over C# in expressive power per line of code (whatever
that's worth)
and raw performance. IMO C++ has two very serious problems, the C
preprocessor, and people who insult others for suggesting the former is a
problem. There are other problems such as exceptions. That can probably
be fixed in a forward-looking sense, but won't solve the problem of
existing C++ code using the flawed exception mechanism.
I came across this comparison between C++ and C#. It seems reasonably
informed and objective from skimming it:
http://www.andymcm.com/csharpfaq.htm#1.5
I believe C++ could, and should look a whole lot different than it
currently
does. Removing on character, and the syntax associated with it would be
the best thing that every happened to C++. What C++ could do without is
the '#' symbol. That probably won't happen in the short term. But there
is a good chance there will be means of confining the C preprocessor to
the few places where legacy usage still prevails.
Again, with the exception of one of your previous items
("Platform-independent system facilities") and that C# is compiled to an
intermediate code, everything that you are talking about (GC, no
pre-processor, concurrency, etc.) are in C#.
You should really spend more time examining C# for yourself (i.e. get a
compiler and write some code for a couple of weeks) rather than try and
advocate such changes to C++.
The item you are referring to was not from _my_ whish list. It was a direct
quote - as were the other items in that list - from Bjarne Stroustrup's
list of things he would like to see added to C++.
Think about it for a minute, if you added/removed the things that you are
advocating, you would have a completely different language that would be
very close to C#.
You are quite wrong if you stop and think about it. I advocate removing the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.
As for how to fix the naming system in the Standard Library, start by
removing one character and all that goes with it from the language. What
character? '#'.
--
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: The item you are referring to was not from _my_ whish list. It was a direct
quote - as were the other items in that list - from Bjarne Stroustrup's
list of things he would like to see added to C++.
Noted. Your request for code completion and early error checking still apply
to C# (VS2003 IDE!) offerings. Think about it for a minute, if you added/removed the things that you are
advocating, you would have a completely different language that would be
very close to C#.
You are quite wrong if you stop and think about it. I advocate removing the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.
C# has no preprocessor. The only thing that it has that resembles the
preprocessor is conditional compilation using #if.
Third time: look into C#.
Julie wrote: "Steven T. Hatton" wrote: The item you are referring to was not from _my_ whish list. It was a
direct quote - as were the other items in that list - from Bjarne
Stroustrup's list of things he would like to see added to C++.
Noted. Your request for code completion and early error checking still
apply to C# (VS2003 IDE!) offerings.
But I've had those features for years with Java. I'm not looking for a
language that has these kind of IDEs. I'm trying to determine why C++
doesn't.
There is a true irony in all this for me. When I started programming in C
and then in C++ (one coures in C++) for my homework assignments back in the
90s, I found the features of the C++ IDE from Borland extremely useful.
Unfortunately I didn't go into programming right away, so I got out of
practice, and didn't continue to develop my skills until I picked up Java.
With Java, all I had at first was TextPad or Nedit. Emacs was completely
arcane to me at the time. It was C++ I looked to with envy because of it's
IDE features. Then JBuiler came along.
> Think about it for a minute, if you added/removed the things that you
> are advocating, you would have a completely different language that
> would be very close to C#.
You are quite wrong if you stop and think about it. I advocate removing
the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.
C# has no preprocessor. The only thing that it has that resembles the
preprocessor is conditional compilation using #if.
Call it what you like, C# has preprocessing directives according to
Microsoft's C# Language Specification.
Third time: look into C#.
Will C# provide me with an IDE for C++ that provides the features I've
described?
To try to explain to others why I believe these features are so important,
here are examples of the kinds of library I am likely to encounter
frequently and likely even together in the same project: http://artis.imag.fr/Members/Yannick...hierarchy.html http://www.web3d.org/x3d/specificati...ngs/index.html http://developer.kde.org/documentati...hierarchy.html http://developer.kde.org/documentation/library/cvs-api/ http://xml.apache.org/xerces-c/apiDocs/inherits.html http://doc.trolltech.com/3.3/classes.html
Note that I did not include the Standard Library, which certainly adds to
the complexity.
--
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" <su******@setidava.kushan.aa> wrote:
You are quite wrong if you stop and think about it. I advocate removing the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.
Removing the mechanism to include one sourcefile within another,
is a serious loss of functionality.
As for how to fix the naming system in the Standard Library, start by
removing one character and all that goes with it from the language. What
character? '#'.
As is removing the ability to write platform-specific code for multiple
platforms, and the ability to work around compiler non-standard issues,
and removing the ability to have debug builds (assert, etc.), etc. etc.
Nobody is asking -you- to use '#'. If you don't like it , nobody is forcing
you. Write your code without it, and if you have to read someone
else's code, run it through the preprocessor first.
Old Wolf wrote: "Steven T. Hatton" <su******@setidava.kushan.aa> wrote:
You are quite wrong if you stop and think about it. I advocate removing
the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have. Cleaning up the naming system
in C++ really means improving the way the Standard Library is organized.
Then formalizing that organizational approach as a foundation for the
creation of other libraries.
Removing the mechanism to include one sourcefile within another,
is a serious loss of functionality.
I took a look at the translation unit resulting from preprocessing a very
simple program. It was then that I realized how bad that system really is.
What most #includes are used for is either to provide access to the
components of the Standard Library, or to include headers in source files.
This is done so that some subset of the available declaration in the
#included Standard Header or header file are available to the source being
compiled. Thes declarations already have a name resolution mechanism
associated with them that is part of C++ proper. If the implementation were
required to locate these declarations on the basis of the C++ name
resolution mechanism, there would be no need for the #include directive. If
this name resolution were such that it mapped directly to object files,
code would, in many cases, compile orders of magnitude faster than it
currently does.
What is really needed is a mechanism to map between fully qualified
identifiers and resources external to the file where they are used, but not
declared.
As for how to fix the naming system in the Standard Library, start by
removing one character and all that goes with it from the language. What
character? '#'.
As is removing the ability to write platform-specific code for multiple
platforms, and the ability to work around compiler non-standard issues,
and removing the ability to have debug builds (assert, etc.), etc. etc.
It doesn't prevent code from porting. There is much code written in
languages that don't have the kind of preprocessor C and C++ have and ports
from one system to another. The same goes for debug builds. It only means
the currently used mechanisms would not be available. I don't know if it's
a formal part of the language, but Java used to honor the #include
directive, and may still. No one used it.
Conditional compilation could be handled by the compiler by not producing
object code for unreachable statements, and using constance which are made
available throughout the program using the C++ name resolution mechanism.
Nobody is asking -you- to use '#'. If you don't like it , nobody is
forcing you. Write your code without it, and if you have to read someone
else's code, run it through the preprocessor first.
Thanks, but I've seen the results of the latter. Rather disturbing to say
the least. Proting code should be done by isolating the system specific
variants in a separate part of the program from the core application. I'm
certain there are other, better mechanisms possible for accomplishing what
the preprocessor currently does. Even if there is an argument for having
preprocessor directives in that confined part of the program, they should
not be permitted beyond those confines. The preprocessor undermines the
inherent grammar of C++ and limits its usefulness and power without adding
anything that couldn't be provided by a better mechanism.
I'll have to investigate before I say much more on this, but there is a
whole lot of java code compiling on my Linux box without having
preprocessor directives.
--
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
> I'll have to investigate before I say much more on this, but there is a whole lot of java code compiling on my Linux box without having
preprocessor directives.
well java simply compiles into bytecode, which is run within the java-vm, and this code is actually the same on _all_ platforms.
there's a huge difference between that, and native code, which actually is different on different platforms (at least when
system-calls and memory-allocations from the system are invoked).
so, strictly spoken, no java-program is platform independent, because it's using the javavm, which in fact always provides the same
api and the same bytecode interpretation on every platform.
so i don't think that java's portability can be used as argument in this.. hmm.. discussion.
as for the preprocessor,.. i do enjoy and use the possibility of having different builds with only setting a preprocessorflag, or
something like that.
regards,
sev
Severin Ecker wrote: I'll have to investigate before I say much more on this, but there is a
whole lot of java code compiling on my Linux box without having
preprocessor directives.
well java simply compiles into bytecode, which is run within the java-vm,
and this code is actually the same on _all_ platforms. there's a huge
difference between that, and native code, which actually is different on
different platforms (at least when system-calls and memory-allocations
from the system are invoked). so, strictly spoken, no java-program is
platform independent, because it's using the javavm, which in fact always
provides the same api and the same bytecode interpretation on every
platform.
so i don't think that java's portability can be used as argument in this..
hmm.. discussion.
as for the preprocessor,.. i do enjoy and use the possibility of having
different builds with only setting a preprocessorflag, or something like
that.
regards,
sev
I wrote /compile/ not /byte compile/.
This is from the history of my bash shell:
emacs -batch -f batch-byte-compile psgml/*.el 2>&1 http://www.xemacs.org/Documentation/...ls_3.html#SEC8
"The new Java language holds promise as a better general-purpose development
language than C. Java has many features in common with Lisp that are not
shared by C (this is not a coincidence, since Java was designed by James
Gosling, a former Lisp hacker)."
--
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
> I wrote /compile/ not /byte compile/.
i'm not quite sure what you mean by "byte compile". compilation is simply the translation from source to destination language.
did you generate native code?
this does not prove my argument senseless. i'm obviously not the java-guru (and i don't really know what features, classes,.. the
java-standard supports), but there will be a great loss of functionality if you want to use the same java program on a windowing
system and on a console system (there you go,.. implementing 2 versions, only, of course if the java compiler isn't smart enough to
change all the windowing code to console code).
as i said before,. i don't think portability really is an argument here.
and i think it would be better to discuss missing features and not "java has this and that, why doesn't c++" "The new Java language holds promise as a better general-purpose development
language than C. Java has many features in common with Lisp that are not
shared by C (this is not a coincidence, since Java was designed by James
Gosling, a former Lisp hacker)."
so what? should everybody just drop C and start low-level programming in java?
and as for the quote anyway,.. i thought you wanted to change C++ not C?
this whole thread really smells trolling....
regards,
sev
Severin Ecker wrote: I wrote /compile/ not /byte compile/.
i'm not quite sure what you mean by "byte compile". compilation is simply
the translation from source to destination language. did you generate
native code? this does not prove my argument senseless. i'm obviously not
the java-guru (and i don't really know what features, classes,.. the
java-standard supports),
I didn't propose any language feature from Java should be included in C++.
I merely used the compilation of the Java compiler and the associated Java
libraries as an example of a large body of code written in a language that
does not have a preprocessor. Yes, the compiler is written in C and
perhaps C++.
http://gcc.gnu.org/java/
"GCJ is a portable, optimizing, ahead-of-time compiler for the Java
Programming Language. It can compile:
* Java source code directly to native machine code,
* Java source code to Java bytecode (class files),
* and Java bytecode to native machine code.
"
but there will be a great loss of functionality
if you want to use the same java program on a windowing system and on a
console system (there you go,.. implementing 2 versions, only, of course
if the java compiler isn't smart enough to change all the windowing code
to console code).
C++ compilers can't do what you are describing. If you are suggesting the
program should sense whether it is running in a windowing or console
environment, that's a programming, and system issue, not a language
specific one.
as i said before,. i don't think portability really is an argument here.
and i think it would be better to discuss missing features and not "java
has this and that, why doesn't c++"
I was using Java as a counter example to demonstrate that certain
functionality can be achieved without the C preprocessor. I've already
mentioned a feature C++ doesn't have, but I believe it should have.
The Standard should specify a means of resolving names to locate
declarations outside the current file based on native C++ syntax, and not
dependent on the preprocessor.
so what? should everybody just drop C and start low-level programming in
java? and as for the quote anyway,.. i thought you wanted to change C++
not C? this whole thread really smells trolling....
The point was that I know the difference between byte compiled code running
on a VM, and natively compiled code. I really wish people would stop
responding irrationally every time Java is mentioned in a discussion of
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
> > but there will be a great loss of functionality if you want to use the same java program on a windowing system and on a
console system (there you go,.. implementing 2 versions, only, of course
if the java compiler isn't smart enough to change all the windowing code
to console code).
C++ compilers can't do what you are describing.
i didn't say so.
If you are suggesting the program should sense whether it is running in a windowing or console
environment, that's a programming, and system issue, not a language specific one.
i'm not suggesting so, please read what i wrote, before answering.
i was referring to e.g. the swing, awt.... classes, which of course don't make any sense on a console based system. now please
re-read my paragraph, it should be preatty clear (at least i hope so).
I was using Java as a counter example to demonstrate that certain
functionality can be achieved without the C preprocessor.
as mentioned above, write a java program with windowing code, and try to run it on a console-platform, without preprocessor, and
without rewriting the windowing part (that's what my paragraph above was all about).
and as for the argument of not knowing what type is declared in what header-file,.. it's the same with the packages in java. you
have to know what to import.
The Standard should specify a means of resolving names to locate
declarations outside the current file based on native C++ syntax, and not
dependent on the preprocessor.
what's the big difference between that and the import in java? (except for the syntax)
you have to know where to find the declaration, you have to import it. (i'm not quite sure how name-lookup works in java, but i
think the class definition has to be available [through importing] before its usage.)
well the preprocessor is not a language-feature pre say, but it has other advantages that i'd miss, when it's completly abandoned.
so what? should everybody just drop C and start low-level programming in
java? and as for the quote anyway,.. i thought you wanted to change C++
not C? this whole thread really smells trolling....
this was a reaction to the quote you gave (as was obvious from the order of paragraphs)
The point was that I know the difference between byte compiled code running
on a VM, and natively compiled code.
this point has nothing to do with the quote you gave, nor with my reaction to it. and i don't think that it's of much use to compare
different purpose languages (like java and c) with one another, as the quote did.
I really wish people would stop
responding irrationally every time Java is mentioned in a discussion of C++.
well then maybe you should talk about standard c++ (the purpose of this group), or, if you have to bring java into play, don't post
quotes comparing java to C because this is completly OT here.
regards,
sev
Severin Ecker wrote: as mentioned above, write a java program with windowing code, and try to
run it on a console-platform, without preprocessor, and without rewriting
the windowing part (that's what my paragraph above was all about).
That is a very common practice, so I really don't know what your point is.
and as for the argument of not knowing what type is declared in what
header-file,.. it's the same with the packages in java. you have to know
what to import.
I have no idea what you that statement was intended to mean. But what do
packages have to do with this discussion?
The Standard should specify a means of resolving names to locate
declarations outside the current file based on native C++ syntax, and not
dependent on the preprocessor.
what's the big difference between that and the import in java? (except for
the syntax) you have to know where to find the declaration, you have to
import it.
I'm not sure. I stated the requirement, not the the means of achieving it.
(i'm not quite sure how name-lookup works in java, but i think
the class definition has to be available [through importing] before its
usage.)
All that is needed is the declaration. It's very much like C++ in that
regard.
well the preprocessor is not a language-feature pre say, but it
has other advantages that i'd miss, when it's completly abandoned.
My problem with the preprocessor is that it makes C++ less predictable.
There are many effective uses of the preprocessor. Most of the
applications I use are written with Qt which makes extensive use of the
preprocessor. In ways not yet mentioned in this discussion.
this point has nothing to do with the quote you gave, nor with my reaction
to it. and i don't think that it's of much use to compare different
purpose languages (like java and c) with one another, as the quote did.
I guess you would need to know more about Emacs, Lisp, Java and Unix/Linux
to understand what I wrote. Of course you are quoting out of context, and
failed to include the example of using Emacs to byte compile all the Lisp
files in a directory, as well as the part about James Gosling, the creator
of Java, having been an Emacs Lisp hacker.
--
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
> > [...] That is a very common practice, so I really don't know what your point is. [...] I have no idea what you that statement was intended to mean. But what do
packages have to do with this discussion?
my point has nothing to do with packages, but portability. when writing a c++ program, you can compile it everywhere, where you find
a std-conforming compiler (window-platform or consoleplatform, there's no such things like windows, so you don't have to rewrite the
program when porting. also the conditional code-generation "magic" is only needed when using system-calls.)
My problem with the preprocessor is that it makes C++ less predictable.
There are many effective uses of the preprocessor. Most of the
applications I use are written with Qt which makes extensive use of the
preprocessor. In ways not yet mentioned in this discussion.
well but don't you think it's the users fault when messing around with macro-magic? well i must admit you can do some really nasty
things with the preprocessor (and i tend to say that's mostly people who think c++ is just some sort of better C), but where would
you stop? there are many things in the language a programmer can mess around with, abandon them too?
this point has nothing to do with the quote you gave, nor with my reaction
to it. and i don't think that it's of much use to compare different
purpose languages (like java and c) with one another, as the quote did.
I guess you would need to know more about Emacs, Lisp, Java and Unix/Linux
to understand what I wrote.
and again that has nothing to do with the quote, comparing java and c (remember, not i but you brought up this quote)
Of course you are quoting out of context
i'm sorry, i'm what?? i didn't quote a single word. i was just refering to a quote you gave. and you didn't refer to my paragraph
but instead came up again with your knowledge of the difference between byte and native compilation.
and failed to include the example of using Emacs to byte compile all the Lisp
files in a directory, as well as the part about James Gosling, the creator
of Java, having been an Emacs Lisp hacker.
you failed to refer to my post, and if you really thing you must use quotes to affirm your oppinions, you failed to connect your
quote to c++.
i don't see any use in posting some link (non c++ specific) and a quote refering to java and c (non c++ specific).
and i still don't get the point with the link.
anyway,... this was my last trollfood, so please feel free to turn c++ into java, or lisp, or whatever you like.
regards,
sev
Severin Ecker wrote: > [...] That is a very common practice, so I really don't know what your point
is. > [...]
I have no idea what you that statement was intended to mean. But what do
packages have to do with this discussion?
my point has nothing to do with packages, but portability. when writing a
c++ program, you can compile it everywhere, where you find a
std-conforming compiler (window-platform or consoleplatform, there's no
such things like windows, so you don't have to rewrite the program when
porting. also the conditional code-generation "magic" is only needed when
using system-calls.)
Again, I fail to see the relevance, or even what the point is. This is what
I am currently working on:
http://baldur.globalsymmetry.com/ope...ect-files.html
http://baldur.globalsymmetry.com/ope...d-friends.html
If you want to explain portability to me, assume as a starting point a basic
understanding of the mechanisms represented by the files accessed from the
pages above.
well but don't you think it's the users fault when messing around with
macro-magic? well i must admit you can do some really nasty things with
the preprocessor (and i tend to say that's mostly people who think c++ is
just some sort of better C), but where would you stop? there are many
things in the language a programmer can mess around with, abandon them
too?
The unpredictability has implications beyond what the individual user can do
to his or her own code. It limits the tool developer's ability to provide
certain kinds of functionality because there are too many potential
circumstances in which the required language feature can be compromised.
The extensive use of the #include mechanism in C++ can lead to some rather
confusing behavior, and unnecessarily complicates the language.
you failed to refer to my post, and if you really thing you must use
quotes to affirm your oppinions, you failed to connect your quote to c++.
i don't see any use in posting some link (non c++ specific) and a quote
refering to java and c (non c++ specific). and i still don't get the point
with the link.
Let me explain it this way. I posted something about _compiling_ Java as an
example of compiling code that does not use the C/C++ preprocessor. You
responded by telling me:
"well java simply compiles into bytecode, which is run within the java-vm,
and this code is actually the same on all platforms.
there's a huge difference between that, and native code, which actually is
different on different platforms (at least when
system-calls and memory-allocations from the system are invoked).
so, strictly spoken, no java-program is platform independent, because it's
using the javavm, which in fact always provides the same
api and the same bytecode interpretation on every platform."
That is when I provided the qote regarding the origins of Java's features,
along with a link to the remainder of the discussion, and emphasized that I
had written /compile/ not /byte compile/. You wrote "i'm not quite sure
what you mean by 'byte compile'". That demonstrates you are not in a
position to carry on an informed discussion on this topic.
--
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
> That is when I provided the qote regarding the origins of Java's features, along with a link to the remainder of the discussion, and emphasized that I
had written /compile/ not /byte compile/. You wrote "i'm not quite sure
what you mean by 'byte compile'". That demonstrates you are not in a
position to carry on an informed discussion on this topic.
"Byte-compile" is emacs terminology: to byte-compile a program is to
compile it to byte code. Byte-compilation is a kind of compilation.
Severin said that, but you've seen him off, so now I'm repeating it.
--
Regards,
Buster.
Buster wrote: That is when I provided the qote regarding the origins of Java's
features, along with a link to the remainder of the discussion, and
emphasized that I
had written /compile/ not /byte compile/. You wrote "i'm not quite sure
what you mean by 'byte compile'". That demonstrates you are not in a
position to carry on an informed discussion on this topic.
"Byte-compile" is emacs terminology: to byte-compile a program is to
compile it to byte code. Byte-compilation is a kind of compilation.
For whose benefit was that intended?
It was James Gosling who wrote the first C-based Emacs implementation. The
same James Gosling who created Java. The term byte compilation is often
used to describe the way Java is compiled into byte code, and appears in
the Java literature from Sun Microsystems.
--
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
On Mon, 07 Jun 2004 14:46:31 -0400 in comp.lang.c++, "Steven T. Hatton"
<su******@setidava.kushan.aa> wrote, You are quite wrong if you stop and think about it. I advocate removing the
'#' symbol and all that goes with it from C++. C# has the same kind of
preprocessing as C and C++ currently have.
I advocate removing the # symbol from C#. This thread has been closed and replies have been disabled. Please start a new discussion. |
