Forgot your password?

Comment: Re:EOL (Score 1) 131

by solidraven (#47741075) Attached to: Ask Slashdot: Where Can I Find Good Replacement Batteries?
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.)

Comment: Re:Customer service? (Score 1) 928

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?

Comment: Re: Uh, sure.. (Score 1) 359

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.

Comment: Re: Uh, sure.. (Score 1) 359

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.

Comment: Re: Uh, sure.. (Score 1) 359

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

Comment: Re: Uh, sure.. (Score 1) 359

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.

Comment: Re: Uh, sure.. (Score 1) 359

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.

Blinding speed can compensate for a lot of deficiencies. -- David Nichols