Why code completion and early error checking are needed

[Steven T. Hatton]

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.

 

[Steven T. Hatton]

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.

 

[Steven T. Hatton]

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.

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.

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.

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.

? do you even read what i write?

To the extent that what you wrote made senes, I gave the best answer
possible.

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

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

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.

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

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.

 

[Mark A. Gibbs]

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]

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

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

 

[E. Robert Tisdale]

I'm sorry,
I was very tired when I posted that and neglected to attribute the quotes.
Those are Stroustrup's words, not mine.

http://cpptips.hyperformix.com/cpptips/fut_of_c++

 

[E. Robert Tisdale]

Right! at a very high price, like I said.

No. It isn't at all difficult or expensive.

 

[Steven T. Hatton]

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.

 

[Steven T. Hatton]

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.

 

[Julie]

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.

 

[Julie]

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.

 

[Steven T. Hatton]

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.

 

[Julie]

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

 

[Steven T. Hatton]

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

 

[Julie]

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.

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

 

[Steven T. Hatton]

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.

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.Legoc/X3D/doc/html/hierarchy.html
http://www.web3d.org/x3d/specifications/ISO-IEC-19777-FCD-X3dLanguageBindings/index.html
http://developer.kde.org/documentation/library/cvs-api/kdevelop/html/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.

 

[Old Wolf]

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.

 

[Steven T. Hatton]

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

 

[Severin Ecker]

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

 

[Steven T. Hatton]

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/21.5/html/internals_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)."

 

[Severin Ecker]

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