Killing yourself while climbing into a volcano sounds less stupid than throwing a bucket of water over your head and claiming it is good for research into a diseases.
And I can totally imagine them coming home and their grandparents asking them "Where did you go this year?" in the most obnoxious wasy possible, like all grandparents do. Good luck explaining this one!
Lua at least has a standard, can't say the same about Fortran where you just sort of decide whatever the hell you want to use at the time of writing your code. Oh, and you'll just love VHDL where you can make up array indices as you go, no questions asked.
I would like to add one thing: People forget that a kernel has to run on pretty much bare metal. If you're lucky you have BIOS there helping you a bit at the start, but not really. (Yay for obscure backwards compatibility tricks that the folks at Microsoft, IBM and Intel came up with.) So your standard libraries are usually quite limited, if you have them at all. And even then they're usually too slow to deal with anyway, so you end up rewriting everything in X86 assembly anyway.
They still have them in stock. I managed to find a new battery for a 10+ year old IBM Thinkpad for a very reasonable price, so you're not looking hard enough.
(And that's what you deserve for using a flawed product.Ten inch screens are post stamp size, useless for practical computing or even note taking.)
Yeah, he got it all wrong. You need to sell old rusty/broken aeroplane fixtures with sharp edges that otherwise get trashed. Saves you money on disposal of those, and you can make an extra buck out of the cage fight. Maybe provide a live video feed of the fight to the passengers in business class?
Yes, but at least you have useful easy to access documentation with VC++. So when it messes up (as all compiler tool chains invariably do) , you have something to check before you switch to mailing lists, forums, and IRC.
I was expecting this one about assembly. There are a few things about this one though, the gcc one is a hassle to get working exactly right. (Configuration) The msvc one works easily and is predictable. You need the inline assembly to activate/configure the device. After that you usually switch to full asm functions to fetch and write data and c++ functions for everything else. The register blocking and overwriting issues most people mention usually results from incompetence with assembly more so than from compiler behaviour. But that's an educational flaw in the current generation of programmers. Building up an OS from the bare metal ought to be a graduation requirement.
To get around it in the x64 versions you need to get a bit creative with linking though. But I'm so not getting into explaining that one. Lets say very few x64 device drivers need more than the standard x86 instruction set. Weirdly enough it still takes less time than switching to GCC, WDK and GCC really do NOT like each other. We tried it once and lost a lot of time and returned to msvc. The macros don't work, GCC also has very peculiar behaviour that you need to control with switches. (A colleague started calling it GNU Switch Roulette. )
Ideally we'd just scrape both compilers and start from scratch, but then we'd end up with windows compatible LLVM I guess. Or I should stop getting involved with these coding projects and stick with hardware.
A lot of opensource projects go through the extra effort of compiling with MSVC on windows. 7zip, blackbox, gtk+, SDL, and XChat come to mind right now.
May I be as bold as stating that you fail to consider everybody's requirements, or at least that we are looking at this from a very different perspective?
The main OS on the market at this point is Windows, both for professional and personal use. In light of this fact you can scrap GCC and LLVM from the list already, GCC creates large cumbersome executables on windows. Sure MinGW isn't bad for meddling around and some small executables. But I wouldn't want to use it to compile things where performance matters, I've tried on several occasions. I must say I find GCC's capability to deal with the Windows Platform SDK quite remarkable at this point. But the end-performance is icky at the best of times. LLVM simply does not have any real windows port that's stable and performant enough for production software.
Before I continue I should probably also mention the code I write is mostly meant for hardware interfacing (I guess you could say drivers to some degree), simulation, and data visualization. All these things require high-end performance which I simply cannot find in the GCC or LLVM ports to Windows. And before you go off making bold statements about Windows not being fit for these sort of jobs, I disagree heavily. If the program that needs the simulation code runs on windows it doesn't make sense to run it on anything else than windows for small to medium scale simulations. Interfacing to remote systems is a hassle and generates a large overhead. For the very heavy lifting using C++ is pointless, Fortran still takes the gold trophy home in that area for me.
And while to the untrained eye the machine code generated by GCC and MSVC might look very similar, MSVC simply generates better code for hardware interfacing, especially its more predictable what happens when you use in-line assembly. The windows port of GDB also fails miserably for these sort of applications, while the MSVC tool chain does a decent job. For simulation it really starts to show though, MSVC simply generates more efficient code than GCC for Windows. Do note that this requires configuring the compiler correctly, something that's trivial to do for MSVC but requires digging through documentation for GCC. Other alternatives like the compilers produced by WATCOM, Digital Mars, Mentor Graphics, and a few others simply don't cut it most of the time. They're either unable to produce code that's capable of using all the resources efficiently, or behave horribly when things like CUDA are invoked. Then there is also the entire issue of data visualization, one of the most important aspects of software development in my opinion. On Windows its either use DirectX or die trying. I agree this is mostly due to Microsoft's doing but we're stuck with it. And no matter what you do, nothing quite beats MSVC when dealing with DirectX.
This also brings me to the point of more common desktop applications, the MSVC standard library works. If you try to use it like the one produced by the GNU project you'll indeed end up in trouble. Not to mention that GTK is a horrible badly documented excuse for a UI library. Qt is better but has licensing issues all over the place. Wx is lacking features in a few important areas. If you use MSVC it knowing its strengths and weaknesses you have a great *little* tool chian at your disposal. Tie it in with the full Windows platform SDK and you have something you can quickly produce a large application with. Frankly I don't care about the C++ standards, I'm very pragmatic about these sort of things and I'm happy if things work well. If I don't have to dig under the hood too much I'm happy. I don't care about the compilation speed, incremental building works very well and my desktop is more than quick enough for 99% of the cases.
I think my first statement is quite obvious, but we don't talk about that.;)
Why should we care that the source of a compiler is open? In the end of the day we care about these things:
1) If it goes wrong do we have somebody to help us that we can call?
2) Is there a quick development cycle possible? (Not having to read through hundreds of pages of manual)
3) Does it work on Windows?
4) Does it integrate well with existing toolchains?
5) Are there any ridiculous limitations?
6) Can we use it without causing a licensing nightmare?
7) If it does go terribly terribly wrong, do we have somebody to shout at?
Please note how access to the source code isn't part of that list. We're so heavily occupied that even if we had the source code we don't have time to look at it unless we plan it in our agenda several months ahead of time or do it on our own time. But lets get back to opensource compiler toolchains! GCC is hardly user-friendly, huge dependency chains for all the related tools, and don't get me started on GNU autoconf. I'll agree LLVM isn't a bad compiler, but it doesn't work well on windows which kills any use we have for it. (Because lets face it, the majority of the population uses Microsoft Windows.)
I could share my experience of working with programmers, but we don't talk about that. Half the time the opensource toolchains require hours of reconfiguration for specific tasks. Not to mention the bloated MSYS ports, which frankly are a far worse issue. (Most people use windows. ) Saying things are good because they are opensource is foolish. The end result is what matters.
Funny you should say that. MSVC is one of the best compilers in existence for C++. Extremely good optimizer, brilliant debugger, extensive standard library, very forgiving for small mistakes, clean output well suited for pipelined execution and much more. It beats the GCC toolchain easily in every way. Only intel composer does slightly better, and maybe a few very specific ones on very specific code.
I heavily disagree, to find the cutting edge you often need to look at where industry works together with academia. Then again, such projects rarely get advertised due to the amount of IP involved. Another thing I've seen is that some companies "outsource" their R&D department in the sense that they hire the staff but place them at a university, or at least on a university campus, and use the equipment there or at least buy time on it. But it really depends on the industry and the size of the company obviously.
Slashdot Mirror
Killing yourself while climbing into a volcano sounds less stupid than throwing a bucket of water over your head and claiming it is good for research into a diseases.
Whatever floats their boat, it's still stupid.
Well, its still less stupid than throwing a bucket of ice water over your head and then posting it on Facebook.
But building a drone that could work in a volcano would be pretty challenging, lets give it a go!
And I can totally imagine them coming home and their grandparents asking them "Where did you go this year?" in the most obnoxious wasy possible, like all grandparents do. Good luck explaining this one!
Lua at least has a standard, can't say the same about Fortran where you just sort of decide whatever the hell you want to use at the time of writing your code. Oh, and you'll just love VHDL where you can make up array indices as you go, no questions asked.
Compilers actually started reading code though :(
I would like to add one thing: People forget that a kernel has to run on pretty much bare metal. If you're lucky you have BIOS there helping you a bit at the start, but not really. (Yay for obscure backwards compatibility tricks that the folks at Microsoft, IBM and Intel came up with.) So your standard libraries are usually quite limited, if you have them at all. And even then they're usually too slow to deal with anyway, so you end up rewriting everything in X86 assembly anyway.
Discrimination! A virus is also software, how dare you be so racist towards them!
-- PETCOM (People for the Ethical Treatment of COmputer Malware - All organisations need a crappy acronym name!)
They still have them in stock. I managed to find a new battery for a 10+ year old IBM Thinkpad for a very reasonable price, so you're not looking hard enough.
(And that's what you deserve for using a flawed product.Ten inch screens are post stamp size, useless for practical computing or even note taking.)
Sheesh, way to make it difficult. Am I the only person who just orders a new battery on the manufacturer's website or from their Amazon page?
As time continues we have to agree more and more with Linus I guess...
Sure, so not a single European country has satellites either?
Yeah, he got it all wrong. You need to sell old rusty/broken aeroplane fixtures with sharp edges that otherwise get trashed. Saves you money on disposal of those, and you can make an extra buck out of the cage fight. Maybe provide a live video feed of the fight to the passengers in business class?
Yes, but at least you have useful easy to access documentation with VC++. So when it messes up (as all compiler tool chains invariably do) , you have something to check before you switch to mailing lists, forums, and IRC.
MSVC is the compiler, not the GUI (that would be MSVS?).
Standard library != Library that follows standards!
You should mostly be looking in the direction of windows.h when working on Windows.
I was expecting this one about assembly. There are a few things about this one though, the gcc one is a hassle to get working exactly right. (Configuration) The msvc one works easily and is predictable. You need the inline assembly to activate/configure the device. After that you usually switch to full asm functions to fetch and write data and c++ functions for everything else. The register blocking and overwriting issues most people mention usually results from incompetence with assembly more so than from compiler behaviour. But that's an educational flaw in the current generation of programmers. Building up an OS from the bare metal ought to be a graduation requirement. To get around it in the x64 versions you need to get a bit creative with linking though. But I'm so not getting into explaining that one. Lets say very few x64 device drivers need more than the standard x86 instruction set. Weirdly enough it still takes less time than switching to GCC, WDK and GCC really do NOT like each other. We tried it once and lost a lot of time and returned to msvc. The macros don't work, GCC also has very peculiar behaviour that you need to control with switches. (A colleague started calling it GNU Switch Roulette. ) Ideally we'd just scrape both compilers and start from scratch, but then we'd end up with windows compatible LLVM I guess. Or I should stop getting involved with these coding projects and stick with hardware.
A lot of opensource projects go through the extra effort of compiling with MSVC on windows. 7zip, blackbox, gtk+, SDL, and XChat come to mind right now.
May I be as bold as stating that you fail to consider everybody's requirements, or at least that we are looking at this from a very different perspective?
The main OS on the market at this point is Windows, both for professional and personal use. In light of this fact you can scrap GCC and LLVM from the list already, GCC creates large cumbersome executables on windows. Sure MinGW isn't bad for meddling around and some small executables. But I wouldn't want to use it to compile things where performance matters, I've tried on several occasions. I must say I find GCC's capability to deal with the Windows Platform SDK quite remarkable at this point. But the end-performance is icky at the best of times. LLVM simply does not have any real windows port that's stable and performant enough for production software.
Before I continue I should probably also mention the code I write is mostly meant for hardware interfacing (I guess you could say drivers to some degree), simulation, and data visualization. All these things require high-end performance which I simply cannot find in the GCC or LLVM ports to Windows. And before you go off making bold statements about Windows not being fit for these sort of jobs, I disagree heavily. If the program that needs the simulation code runs on windows it doesn't make sense to run it on anything else than windows for small to medium scale simulations. Interfacing to remote systems is a hassle and generates a large overhead. For the very heavy lifting using C++ is pointless, Fortran still takes the gold trophy home in that area for me.
And while to the untrained eye the machine code generated by GCC and MSVC might look very similar, MSVC simply generates better code for hardware interfacing, especially its more predictable what happens when you use in-line assembly. The windows port of GDB also fails miserably for these sort of applications, while the MSVC tool chain does a decent job. For simulation it really starts to show though, MSVC simply generates more efficient code than GCC for Windows. Do note that this requires configuring the compiler correctly, something that's trivial to do for MSVC but requires digging through documentation for GCC. Other alternatives like the compilers produced by WATCOM, Digital Mars, Mentor Graphics, and a few others simply don't cut it most of the time. They're either unable to produce code that's capable of using all the resources efficiently, or behave horribly when things like CUDA are invoked. Then there is also the entire issue of data visualization, one of the most important aspects of software development in my opinion. On Windows its either use DirectX or die trying. I agree this is mostly due to Microsoft's doing but we're stuck with it. And no matter what you do, nothing quite beats MSVC when dealing with DirectX.
This also brings me to the point of more common desktop applications, the MSVC standard library works. If you try to use it like the one produced by the GNU project you'll indeed end up in trouble. Not to mention that GTK is a horrible badly documented excuse for a UI library. Qt is better but has licensing issues all over the place. Wx is lacking features in a few important areas. If you use MSVC it knowing its strengths and weaknesses you have a great *little* tool chian at your disposal. Tie it in with the full Windows platform SDK and you have something you can quickly produce a large application with. Frankly I don't care about the C++ standards, I'm very pragmatic about these sort of things and I'm happy if things work well. If I don't have to dig under the hood too much I'm happy. I don't care about the compilation speed, incremental building works very well and my desktop is more than quick enough for 99% of the cases.
I think my first statement is quite obvious, but we don't talk about that. ;)
Why should we care that the source of a compiler is open? In the end of the day we care about these things:
1) If it goes wrong do we have somebody to help us that we can call?
2) Is there a quick development cycle possible? (Not having to read through hundreds of pages of manual)
3) Does it work on Windows?
4) Does it integrate well with existing toolchains?
5) Are there any ridiculous limitations?
6) Can we use it without causing a licensing nightmare?
7) If it does go terribly terribly wrong, do we have somebody to shout at?
Please note how access to the source code isn't part of that list. We're so heavily occupied that even if we had the source code we don't have time to look at it unless we plan it in our agenda several months ahead of time or do it on our own time. But lets get back to opensource compiler toolchains! GCC is hardly user-friendly, huge dependency chains for all the related tools, and don't get me started on GNU autoconf. I'll agree LLVM isn't a bad compiler, but it doesn't work well on windows which kills any use we have for it. (Because lets face it, the majority of the population uses Microsoft Windows.)
I could share my experience of working with programmers, but we don't talk about that. Half the time the opensource toolchains require hours of reconfiguration for specific tasks. Not to mention the bloated MSYS ports, which frankly are a far worse issue. (Most people use windows. ) Saying things are good because they are opensource is foolish. The end result is what matters.
Funny you should say that. MSVC is one of the best compilers in existence for C++. Extremely good optimizer, brilliant debugger, extensive standard library, very forgiving for small mistakes, clean output well suited for pipelined execution and much more. It beats the GCC toolchain easily in every way. Only intel composer does slightly better, and maybe a few very specific ones on very specific code.
Lets take a look at commercial software...
I heavily disagree, to find the cutting edge you often need to look at where industry works together with academia. Then again, such projects rarely get advertised due to the amount of IP involved. Another thing I've seen is that some companies "outsource" their R&D department in the sense that they hire the staff but place them at a university, or at least on a university campus, and use the equipment there or at least buy time on it. But it really depends on the industry and the size of the company obviously.
And this is supposed to be impressive how?