Why code completion and early error checking are needed

[Steven T. Hatton]

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

 

[Severin Ecker]

but there will be a great loss of functionality

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.

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

 

[Steven T. Hatton]

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?

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.

 

[Severin Ecker]

[...]

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?

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

 

[Steven T. Hatton]

[...]

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/op.../new-project-files/new-kde-project-files.html
http://baldur.globalsymmetry.com/op...e-and-friends/after-automake-and-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.

 

[Buster]

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.

 

[Steven T. Hatton]

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

 

[David Harmon]

On Mon, 07 Jun 2004 14:46:31 -0400 in comp.lang.c++, "Steven T. Hatton"

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