Like I said, Java does not do this -- the JVM does.
No, when Java is compiled natively, it does bounds checking. Just like dozens of other programming languages running natively on x86 and on a vast array of other systems.
So how about the times when I really don't care about whether there comes an IOException while opening a file? I may well want that exception to propagate to the end of the stack and terminate the program. But no -- according to javac I must catch it, and then arrange for some other way to terminate the program.
It's a silly idea that a program should crash because the file isn't there. In a non-trivial program, you would never want the program to end without an appropriate error message just because a file wasn't there.
Arrays and pointers are not defined as being equivalent in C -- only on x86, Sparc, PPC and similar platforms.
Nonsense. Arrays and pointers are defined as being equivalent in many ways in the ISO C standard. But
void foo (char * bob);
int main () { char john[42]; char *jane = 0; foo (john); foo (jane);}
is valid C code anywhere. It is practically impossible for a compiler to do proper bounds checking for C, because of this, and this is true on every system.
But then you subject yourself to exactly the same portability "limitations" as with C.
But you have the option of native compilers and JVM compilers.
Just because there are JVM emulators for most platforms doesn't mean that the class files are portable anymore than an x86 ELF file.
x86 ELF files aren't portable between OSes, and no matter the theoretical portability, and the practical existance of emulators for certain OSes running x86 ELF files, most people don't have them installed. As a practical thing, you can take a bytecode compiled Java file and run it on many people's systems. Whether or not it's being emulated isn't an interesting question; whether or not it will run is.
Let's see, we had PL/I (a merger of Fortran, COBOL, and Algol), RATFOR, Ada, Matlab, C++, and the late, and rather lamented, Sather. None of them has the performance of Fortran, the ease of programming, the extensive and validated libraries, complex numbers as a fundamental data type, or the solidity of compilers.
The ease of programming? RATFOR was easier to program in than Fortran; considering it was just a preprocessor to Fortran, that was the only reason to use it. Except for those who know only Fortran, I wonder that any of the above was harder to program in than Fortran.
PL/I, RATFOR (of course), Ada, Matlab and arguably C++ have complex numbers as a fundamental data type.
"Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM.
That's absurd. There's dozens of languages that do that running on i386. BASIC, Ada, Java, Pascal, Fortran in some cases, they all check the bounds of arrays and prevent the use of arbitrary address in the general case. You don't check the bounds of arrays by some hardware magic; you check them by storing the array bounds with the array. C can't do that, since it's legal to pass a pointer to the middle of an array as if it were a pointer to an array.
In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM.
Really. I guess gcj, the GNU Java frontend to GCC, doesn't exist then. On the flip side, you haven't been around computers much if you haven't seen languages that run on only one architecture; QBasic comes to mind.
Radio involves actual broadcasting of electromagnetic waves on rf frequencies, normally at substantially high power levels.
Which is clearly an insufficent definition, since that would include television. Radio in this usage is clearly audio-only.
This whole fad of calling various forms of digital audio distributed over the internet 'radio', just goes to emphasize the technical illiteracy of the current crop of 'nerds'.
Or it emphasizes how languages change and grow to fill new-found gaps by extension of existing words. Radio, from a simple reference to electromagnetic broadcasting, came to refer to sound broadcasting*, and now that there is non-electromagnetic sound broadcasting, it has clearly, in many contexts, been divested of its original connection to the electromagnetic spectrum.
* OED 2ed: Radio, 2b "[...]; sound broadcasting considered as a medium of communication or as an art form."
"The term "Maginot Line" has been used as a metaphor for something that is confidently relied upon despite being ineffectual. In fact, it did exactly what it was intended to do, sealing off a section of France, and forcing an aggressor around it[...]"
So it did what it was supposed to do, but what it was supposed to do was useless. Sort of like making your computer secure against the Internet and leaving it logged in where anyone can access it from the keyboard.
If all software was "free" according to Stallman's definition, there would be no incentive for students to enter into the software industry
The fact is that 90% of software is speciality software for one business, and free software isn't going to cause the need for tens of thousands of programs to be written to go away. Even big-name open source programs that everyone use, like OpenOffice and Mozilla and Linux (both the kernel and the OS), have people being paid especially to work on them.
How many people is worth giving up the enormous amount of radio spectrum that analog TV takes up? Just cut it off and let them replace the old TVs or get cable. Or learn to go without TV.
A computer language won't help you write better code.
Then why doesn't everyone write in machine language? C and C++ programmers seem to go on and on about how the language doesn't matter, but it really does.
It may not crash and burn like a C/C++ pointer error, but an uncaught exception or excessive object creation in innerloops in java is just as bad.
An uncaught exception in Java will not corrupt memory and let you save a corrupt copy of a file over the good one on disk. An uncaught exception in Java will not let anyone execute arbitary code and gain unwanted access to your computer.
A 16 bit RAW will be much smaller than a 16 bit per channel (48 bit RGB) TIFF.
Ah. Then why are you storing greyscale data in a full-color TIFF? That's hardly TIFF's fault. A 16 bit RAW will be the same size as a 16 bit greyscale TIFF.
A 16 bit RAW will be much smaller than a 16 bit per channel (48 bit RGB) TIFF. And will produce an image of the exact same quality, if not better.
A 16 bit RAW that has only 16 bits of data per pixel is not high quality. 24 bits per pixel isn't considered enough for high-quality pixel work. If you have 16 bits of data per pixel, there are shades that your moniter can distinguish between that your camera can't reproduce. You can't reproduce 48 bits of data in 16 bits.
You do realise that RAW images are generally only one channel, effectivly?
What does that mean? That they aren't color pictures? Wikipedia comes with no definition of the word channel that makes any sense in this connotation.
To me, I thought that was pretty clear when I watched the DVDs. The first episode had a large scene where they did space right; no sound and things moved realistically. Having watched the whole thing, I got the impression that with that scene, they were trying to tell their audience that they were going to do hard science fiction, not normal TV science fiction.
And because Raw is only one value per pixel instead of 3, they tend to be much smaller than 16 bit tiffs.
It doesn't matter whether it's one value or not, it matters how many bits are used per pixel. If an uncompressed file format is using fewer than 24 bits per pixel, you're not getting high quality pictures. TIFF, if used with LZW or PNG/ZLIB compression, can compress out any padding zeros with no problem.
"the ability to have files in more than one folder simultaneously" Is it just me.. or do all OSes do this? I have thousands of files, all in different places, all at the same time... right now.
No, MSDOS 1.0 and CP/M didn't support multiple folders. Perhaps they finally convinced Marketing to upgrade from CP/M to a Microsoft operating system?
You jump to argue that with nobody uses a Macintosh, but you can't understand why Objective-C++ users might not want to be dismissed as nobody. I'm not arguing that it's worth doing, just that all the people that were waiting on Objective C++ (all hundred or whatever), and were told that it would be in GCC 4.0 (http://gcc.gnu.org/wiki/What%20will%20be%20in%204.0) at least deserve a statement that it won't be done.
What is wrong with you that makes you berate a company for listening to it's clients?
I'm not. I'm upset that I still get email via the GCC list of people begging for Objective C++ every so often, and Apple can't even say "No, we're not working on this anymore." Despite having promised that it would be in GCC 4.0. And I'm berating him for not recognizing the difference between nobody wants this and very few people want this, and attacking anyone who says they want it.
An installed base of 40 million users growing at the (as of this moment) rate of ten million new users a year does not round down to zero.
So now you define rounding, huh? If we're defining rounds down to zero as there's so few of them as to be insignificant, then 40 million may very well round down to zero for certain people. Wal-Mart certainly rounds it down, as they don't stock Mac products.
You can't have your cake and eat it too. Either your minority sometimes rounds to zero, or you stop rounding people off to zero. Out there, somewhere, is someone who considers your group insignificant; either he should round them down to zero, or you should accept that you should stop rounding other people down to zero, and accept that they exist, no matter how few of them there are.
There should be a period of years where anything that wasn't flagged is at least flagged as a warning before being flagged as an error.
Blame the standards committee. If the language wasn't damn near unparsable, it would be easy to support various things as warnings. But C++ is so hard to parse that many things that weren't flagged were parser errors, and were almost impossible to support in a new fixed parser.
except for the fact that the people who write GCC continue to insist on breaking older code.
Why use the latest version of GCC, then? The reason they break old code is to improve the compiler; if you don't want the improvements, install the old version of the compiler.
You realize that you got that exactly backwards, right?
I got it exactly the way I wanted it. At its current priority, there aren't enough people to satisfy the demands of higher priority items and it.
What people? That's the point. There's no demand for it.
I guess all the people responding to this thread saying they want it are lying. I guess all the people who emailed the GCC list wanting it were lying too. There may not be enough demand for you to do it, but that doesn't mean there's no people who want it.
That's like saying someone saying they're going to create a Macintosh version of a program, and then stopping silently because there's no Macintosh users. There may not be enough Mac users to support the port, but there are Mac users out there.
Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.
GNU Pascal supports building with a number of versions of GCC, and work on GNU Pascal is with a released version of GCC. The GCC developers want GNU Pascal as just another frontend; changes should go to GCC head, and there shouldn't be #ifdefs to get it to compile with different versions of the compiler backend. That's a large problem that has stopped GPC from being merged.
Re:Figured this had to happen
on
GCC 4.0.0 Released
·
· Score: 5, Informative
We're not shipping "a fork" of GCC 4. We're shipping GCC 4.0.0, which we compiled from source for Darwin 8.
The version of GCC shipped by Apple typically includes a number of extensions not available in a standard GCC release. These extensions are generally for backwards compatibility and best avoided.
i.e. you're using a forked version of GCC, and definitely not 4.0.0 out of the box.
the whole notion of "a fork" runs 100% counter to all that open-source stuff
No, actually, the importance of the ability to fork and wisdom to know when to fork is very important to "that open-source stuff".
You make it sound like our guys are spread too thin to work on Objective-C++. Not so.
It's all matter of priorities. You don't have enough people to work on it with the priorities that you're putting on it.
And it seems pretty unfair that Apple has led all the people who want a Objective-C++ on; there was a big fuss on the GCC list about how Apple wanted Objective-C++ in GCC 4.0, but there never was a message that no, Apple has now decided that it's not important.
Any word on if it's coming any time soon (really)?
Provided that no one volunteers to work on it, it's Apple's ball game. Apple, recently, hasn't seemed to have time to spend on getting Objective C++ merged into the main GCC tree. It's all up to when Apple programmers feel they have time to spare from other GCC work to finish Objective C++.
Slashdot Mirror
No, when Java is compiled natively, it does bounds checking. Just like dozens of other programming languages running natively on x86 and on a vast array of other systems.
So how about the times when I really don't care about whether there comes an IOException while opening a file? I may well want that exception to propagate to the end of the stack and terminate the program. But no -- according to javac I must catch it, and then arrange for some other way to terminate the program.
It's a silly idea that a program should crash because the file isn't there. In a non-trivial program, you would never want the program to end without an appropriate error message just because a file wasn't there.
Arrays and pointers are not defined as being equivalent in C -- only on x86, Sparc, PPC and similar platforms.
Nonsense. Arrays and pointers are defined as being equivalent in many ways in the ISO C standard. Butis valid C code anywhere. It is practically impossible for a compiler to do proper bounds checking for C, because of this, and this is true on every system.
But then you subject yourself to exactly the same portability "limitations" as with C.
But you have the option of native compilers and JVM compilers.
Just because there are JVM emulators for most platforms doesn't mean that the class files are portable anymore than an x86 ELF file.
x86 ELF files aren't portable between OSes, and no matter the theoretical portability, and the practical existance of emulators for certain OSes running x86 ELF files, most people don't have them installed. As a practical thing, you can take a bytecode compiled Java file and run it on many people's systems. Whether or not it's being emulated isn't an interesting question; whether or not it will run is.
Let's see, we had PL/I (a merger of Fortran, COBOL, and Algol), RATFOR, Ada, Matlab, C++, and the late, and rather lamented, Sather. None of them has the performance of Fortran, the ease of programming, the extensive and validated libraries, complex numbers as a fundamental data type, or the solidity of compilers.
The ease of programming? RATFOR was easier to program in than Fortran; considering it was just a preprocessor to Fortran, that was the only reason to use it. Except for those who know only Fortran, I wonder that any of the above was harder to program in than Fortran.
PL/I, RATFOR (of course), Ada, Matlab and arguably C++ have complex numbers as a fundamental data type.
"Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM.
That's absurd. There's dozens of languages that do that running on i386. BASIC, Ada, Java, Pascal, Fortran in some cases, they all check the bounds of arrays and prevent the use of arbitrary address in the general case. You don't check the bounds of arrays by some hardware magic; you check them by storing the array bounds with the array. C can't do that, since it's legal to pass a pointer to the middle of an array as if it were a pointer to an array.
In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM.
Really. I guess gcj, the GNU Java frontend to GCC, doesn't exist then. On the flip side, you haven't been around computers much if you haven't seen languages that run on only one architecture; QBasic comes to mind.
Radio involves actual broadcasting of electromagnetic waves on rf frequencies, normally at substantially high power levels.
Which is clearly an insufficent definition, since that would include television. Radio in this usage is clearly audio-only.
This whole fad of calling various forms of digital audio distributed over the internet 'radio', just goes to emphasize the technical illiteracy of the current crop of 'nerds'.
Or it emphasizes how languages change and grow to fill new-found gaps by extension of existing words. Radio, from a simple reference to electromagnetic broadcasting, came to refer to sound broadcasting*, and now that there is non-electromagnetic sound broadcasting, it has clearly, in many contexts, been divested of its original connection to the electromagnetic spectrum.
* OED 2ed: Radio, 2b "[...]; sound broadcasting considered as a medium of communication or as an art form."
Or for describing everyone who disagrees with Bush as Marxists, which is bullshit and flamebait.
"The term "Maginot Line" has been used as a metaphor for something that is confidently relied upon despite being ineffectual. In fact, it did exactly what it was intended to do, sealing off a section of France, and forcing an aggressor around it[...]"
So it did what it was supposed to do, but what it was supposed to do was useless. Sort of like making your computer secure against the Internet and leaving it logged in where anyone can access it from the keyboard.
Very worthy of bashing, IMO.
If all software was "free" according to Stallman's definition, there would be no incentive for students to enter into the software industry
The fact is that 90% of software is speciality software for one business, and free software isn't going to cause the need for tens of thousands of programs to be written to go away. Even big-name open source programs that everyone use, like OpenOffice and Mozilla and Linux (both the kernel and the OS), have people being paid especially to work on them.
How many people is worth giving up the enormous amount of radio spectrum that analog TV takes up? Just cut it off and let them replace the old TVs or get cable. Or learn to go without TV.
A computer language won't help you write better code.
Then why doesn't everyone write in machine language? C and C++ programmers seem to go on and on about how the language doesn't matter, but it really does.
It may not crash and burn like a C/C++ pointer error, but an uncaught exception or excessive object creation in innerloops in java is just as bad.
An uncaught exception in Java will not corrupt memory and let you save a corrupt copy of a file over the good one on disk. An uncaught exception in Java will not let anyone execute arbitary code and gain unwanted access to your computer.
A 16 bit RAW will be much smaller than a 16 bit per channel (48 bit RGB) TIFF.
Ah. Then why are you storing greyscale data in a full-color TIFF? That's hardly TIFF's fault. A 16 bit RAW will be the same size as a 16 bit greyscale TIFF.
A 16 bit RAW will be much smaller than a 16 bit per channel (48 bit RGB) TIFF. And will produce an image of the exact same quality, if not better.
A 16 bit RAW that has only 16 bits of data per pixel is not high quality. 24 bits per pixel isn't considered enough for high-quality pixel work. If you have 16 bits of data per pixel, there are shades that your moniter can distinguish between that your camera can't reproduce. You can't reproduce 48 bits of data in 16 bits.
You do realise that RAW images are generally only one channel, effectivly?
What does that mean? That they aren't color pictures? Wikipedia comes with no definition of the word channel that makes any sense in this connotation.
I like to think that was on purpose
To me, I thought that was pretty clear when I watched the DVDs. The first episode had a large scene where they did space right; no sound and things moved realistically. Having watched the whole thing, I got the impression that with that scene, they were trying to tell their audience that they were going to do hard science fiction, not normal TV science fiction.
And you can't see any difference between them? Sit down at a UNIX/Linux box and use 'find' to find all files that have a name that ends in ".jpg".
That's because there's better programs to do that then find. Use locate, which comes standard with the GNU versions of findutils.
And because Raw is only one value per pixel instead of 3, they tend to be much smaller than 16 bit tiffs.
It doesn't matter whether it's one value or not, it matters how many bits are used per pixel. If an uncompressed file format is using fewer than 24 bits per pixel, you're not getting high quality pictures. TIFF, if used with LZW or PNG/ZLIB compression, can compress out any padding zeros with no problem.
"the ability to have files in more than one folder simultaneously" Is it just me.. or do all OSes do this? I have thousands of files, all in different places, all at the same time... right now.
No, MSDOS 1.0 and CP/M didn't support multiple folders. Perhaps they finally convinced Marketing to upgrade from CP/M to a Microsoft operating system?
We know that nobody wants Objective-C++.
4 .0) at least deserve a statement that it won't be done.
You jump to argue that with nobody uses a Macintosh, but you can't understand why Objective-C++ users might not want to be dismissed as nobody. I'm not arguing that it's worth doing, just that all the people that were waiting on Objective C++ (all hundred or whatever), and were told that it would be in GCC 4.0 (http://gcc.gnu.org/wiki/What%20will%20be%20in%20
What is wrong with you that makes you berate a company for listening to it's clients?
I'm not. I'm upset that I still get email via the GCC list of people begging for Objective C++ every so often, and Apple can't even say "No, we're not working on this anymore." Despite having promised that it would be in GCC 4.0. And I'm berating him for not recognizing the difference between nobody wants this and very few people want this, and attacking anyone who says they want it.
An installed base of 40 million users growing at the (as of this moment) rate of ten million new users a year does not round down to zero.
So now you define rounding, huh? If we're defining rounds down to zero as there's so few of them as to be insignificant, then 40 million may very well round down to zero for certain people. Wal-Mart certainly rounds it down, as they don't stock Mac products.
You can't have your cake and eat it too. Either your minority sometimes rounds to zero, or you stop rounding people off to zero. Out there, somewhere, is someone who considers your group insignificant; either he should round them down to zero, or you should accept that you should stop rounding other people down to zero, and accept that they exist, no matter how few of them there are.
There should be a period of years where anything that wasn't flagged is at least flagged as a warning before being flagged as an error.
Blame the standards committee. If the language wasn't damn near unparsable, it would be easy to support various things as warnings. But C++ is so hard to parse that many things that weren't flagged were parser errors, and were almost impossible to support in a new fixed parser.
except for the fact that the people who write GCC continue to insist on breaking older code.
Why use the latest version of GCC, then? The reason they break old code is to improve the compiler; if you don't want the improvements, install the old version of the compiler.
You realize that you got that exactly backwards, right?
I got it exactly the way I wanted it. At its current priority, there aren't enough people to satisfy the demands of higher priority items and it.
What people? That's the point. There's no demand for it.
I guess all the people responding to this thread saying they want it are lying. I guess all the people who emailed the GCC list wanting it were lying too. There may not be enough demand for you to do it, but that doesn't mean there's no people who want it.
That's like saying someone saying they're going to create a Macintosh version of a program, and then stopping silently because there's no Macintosh users. There may not be enough Mac users to support the port, but there are Mac users out there.
Something that I would really like to see integrated into GCC, sooner or later, is GNU Pascal.
GNU Pascal supports building with a number of versions of GCC, and work on GNU Pascal is with a released version of GCC. The GCC developers want GNU Pascal as just another frontend; changes should go to GCC head, and there shouldn't be #ifdefs to get it to compile with different versions of the compiler backend. That's a large problem that has stopped GPC from being merged.
According to http://gcc.gnu.org/install/specific.html#powerpc-
i.e. you're using a forked version of GCC, and definitely not 4.0.0 out of the box.
the whole notion of "a fork" runs 100% counter to all that open-source stuff
No, actually, the importance of the ability to fork and wisdom to know when to fork is very important to "that open-source stuff".
You make it sound like our guys are spread too thin to work on Objective-C++. Not so.
It's all matter of priorities. You don't have enough people to work on it with the priorities that you're putting on it.
And it seems pretty unfair that Apple has led all the people who want a Objective-C++ on; there was a big fuss on the GCC list about how Apple wanted Objective-C++ in GCC 4.0, but there never was a message that no, Apple has now decided that it's not important.
Any word on if it's coming any time soon (really)?
Provided that no one volunteers to work on it, it's Apple's ball game. Apple, recently, hasn't seemed to have time to spend on getting Objective C++ merged into the main GCC tree. It's all up to when Apple programmers feel they have time to spare from other GCC work to finish Objective C++.