For me, winelib is the most interesting part of wine. I have win32 code I would like to just port to linux/X without doing a rewrite. In fact I want to port it to both i386 AND powerpc. I'm not interested in 386 DLL loading and crud like that. I just want to use it as a portable widget library. Yes I know of other portable widget libraries but it is too late for these old programs.
I found that winelib didn't even come CLOSE to compiling on linuxppc.
Making winelib robust would allow other software houses to release native linux ports of their win32 software much easier.
Very good question. Some people here actually got good solutions that appear to work without memory leaks.
HOWEVER
The next step is to take the platform into account!
Let us run the code on Linux.
GUESS WHAT? malloc() will almost never ever return 0 under Linux!!! Even when there is NOT enough memory (phys+swap) available! Try it! Allocate 100 megs 5 times on a system with 256 megs of ram+swap. It works.
It is a 'feature' called memory overcommit.
malloc() returns a pointer to a bunch of virtual memory space. The actual memory pages are not allocated until you TOUCH EACH MEMORY PAGE!
So, in linux you may as well just ignore the return values p1,p2 and p3 and just go ahead and use them. If there isn't enough memory available, the code you have at the point/* Here we do something */ will cause the application to be immediately terminated. No error codes, no way to handle it. In fact, other apps running at the same time may get terminated as well if they need to allocate memory.
Eiffel and C++ exceptions don't help either. The c++ 'new' operator WILL NOT THROW any exception. It will not return 0. Your program will just spontaneously terminate, LATER.
Do a search for 'Endless overcommit memory thread' in the linux kernel archives to read more about this behaviour.
Error handling is unfortunately more complex than just handling return codes properly.
I use threads all the time! I just don't like them to be forced. However I'd like them better in a language that officially SUPPORTS them. C++ is not that language, unfortunately - think thread safe std::string, STL and exceptions, race conditions in singletons without a double guard (therefore the inability to have non-trivial constructors in static members of a class without wrapping them in a thread-safe dynamic singleton allocator object), debuggers, core dumps, profiling tools, memory leak checker tools, lack of warnings when using shared data without a semaphore, etc..
I've been using BeOS for ages and actually had a PPC BeBox too! Still have BeOS installed (which kernel panics when my real Roland 100% standard MPU-401 MIDI interface receives a MIDI byte).
Worked with www.lcsaudio.com where they are STILL SHIPPING commercial software for BeOS. At one point LCS had more BeBoxes than any other company besides Metrowerks. I used to be an enthusiast.
Not anymore.
I can't count how many BeOS applications are written with threading problems! Is it because most programmers actually suck?
Yes, most linux GUI's responsiveness sucks. No, having a seperate thread for each window would NOT always help - Most X apps only have one window anyways. However, having seperate non-gui worker threads WOULD help and should be done when appropriate.
Be Happy! Inefficiency fosters economic growth!!!! You are all sitting around going through scripts, wasting time and getting paid! It is good for the economy!
Hmmm.... But it IS interceptable! All you need to do is have an array (or matrix) of listening devices near the transmitter. Then with (massive?) computing power you should be able to search for the sort of correlation that the transmitters form. Right? Probably would help if you knew the distance to the submarine too.
My question though is why not just steal the buoy?
The kernel could be using C++, I understand the reasonings for that. However if you want to use GOOD C++ with Resource Aquisition Is Initialization (RAII) or have any non-trivial constructors, you NEED c++ exception handling, which can throw a big wrench into your special stack frames.
STL would actually be NICE to use within a kernel however!
The C++ API caused tons of stupid problems and workarounds in BeOS. Not only did they have to reserver vtable slots (in the right order!) they had to make sure that any methods that could be inlined were not if they might possibly be changed to non-inline in the future.
The BeOS api was started a long time ago - before the ANSI C++ standard came out. There are a number of design decisions that Be made back then that seemed reasonable then, but are not good now.
For instance, they should have designed their interface classes to contain pImpls - yes it is an extra redirection but it allows for dynamic library compatibility. Also, there should have been less focus on inheriting non-abstract system base classes. All user classes that the system needs to know about should be inherited from a pure abstract system base class. It would also potentially make their BLooper message dispatching system nicer - like libsignal++...
But one BIG problem with BeOS (besides bugs and slow networking) is their use of threads for EVERYTHING, in the language of C++ which officially has no concept of threads. Yes, you can do it but it is like fitting a square peg into a pentagram. Maybe Ada95 would have been a better choice? But that wouldn't be 1337 then I guess.
heh! Well I guess I should upgrade to 10.1 then! I know it wasn't available for the entire last year. I think HP or someone like that had a patent on the 'thunking' technology used in Objective C++.
In reality however the real analogy would be that Microsoft represents an airport with shoddy security like the Boston airport was - Boston airport was fined many times previously by the FAA for failing their security tests.
Therefore, Microsoft should be fined by the government for shoddy security in IIS! They are allowing terrorists to wreak havoc!
Unfortunately there IS no Objective C++ available anymore. Something about a patent violation, seriously. This severely limits my usage of Cocoa. This is why libQT for MacOSX is so good. Without it, everybody wanting to use C++ on MacOSX would have to thunk to C to call Objective C Cocoa libs, or use C++ with the crappy Carbon libs.
If it isn't, PLEASE research recording contracts. Very very few popular bands make money from record companies. Read how it really works at http://www.salon.com/tech/feature/2000/06/14/love/
--jeff
Re:You really need to stop smoking that cheap shit
on
J#
·
· Score: 2
Probably they will "Make Windows the best operating system to run.NET on" in similiar ways that 10 years ago they made "Windows the best operating system to run Microsoft Word on" by adding busy loops in their programs to slow them down if they detected that they were running in OS/2's Windows compatibility mode.
Qt is not as bad as most GUI frameworks. Gtk-- is better, but 'inti' ( http://sources.redhat.com/inti ) whenever it is done would be even better still (Anyone know what's happening with that?)
One of the unfortunate requirements with Qt is the ability to be compiled with VC++ 6. This alone causes problems with wanting a good design. I myself have found cygwin/mingw32 to finally be usable for all my win32 projects, so maybe now we can drop the 'lame compiler compatibility' requirements.
I think that the presence of the signal/slot preprocessor for Qt shows a fundamental problem with practical C++. I didn't say Qt was 'GOOD' I said for the most part it is OK. Better than Microsoft's MFC and Borland's VCL. Better than wxWindows. A real option for multiplatform apps.
--jeff
Re:A bit of thought on the evolution of the GNOME.
on
Gnome 2.0 Alpha 1 Released
·
· Score: 3, Informative
Sigh... I just spent 10 minutes typing in my response and then slashdot/IE killed my post.
I'll do the short version.
#1 Most people who say they are C++ programmers actually are not properly educated in it, and have no or very little understanding of exception safety, const correctness, mutable, co-variant return types.
#2 Code re-use is a fallacy. Very often projects are factored way too much in the name of code reuse. What is important is GOOD DESIGN MEETING THE SPECIFICATIONS. Code re-use may or may not be part of that. When it is, it is a major thing. It does not come automatically because you typed 'class' instead of 'struct'.
#3 The C++ Fragile Base Class Problem. http://2f.ru/holy-wars/fbc.html
#4 C++ is a multi-paradigm language. Not only procedural, not only pseudo-OO, but generic programming too. Quite often the generic solution is the best solution under C++. I've never actually physically met more than two people who understood generic programming. sigh.
#5 Many C++ compilers just plain suck. You have to code for the lowest common denominator for the platforms that you are interested in.
#6 There is no (and can be no) standard binary API for C++ libraries. Other languages have a much harder time calling C++ libs than C libs.
--jeff
Re:A bit of thought on the evolution of the GNOME.
on
Gnome 2.0 Alpha 1 Released
·
· Score: 3, Informative
Unfortunately, too many people who are ignorant about the issues are jumping on the C++ bandwagon.
I've been using C++ since 1990! I helped port g++ v1.35 to the Atari Mega 4ST. I've followed the language evolution all the way till now. Many of my projects use C++.
Yet, many C++ projects that I see being done by other people are horribly misguided and doomed to failure. There are very good reasons to want to stick to C code!!!
Trolltech's QT lib is NOT one of them. For the most part, QT is ok.
I myself have found very very little new music from RIAA affiliated companies worth listening to.
If you don't like the RIAA, go find local original bands in your community and support them and the local live music scene. Make sure they know about the fallacies of the 'Big Record Deal.'
The reason for the silly ++ and -- operators is simply because of the lack of good optimizers long ago.
"*s++ = *t++" directly maps to a SINGLE instruction on many CPU architectures. eg: 'move (a0)+, (a1)+'
Those operators made it easier to make the compilers use the capabilities of the CPU.
Today, optimizing compilers can and do figure this out all on their own.
Number of keystrokes was not the issue. Too bad it has infected so many languages since. In fact, on some CPU's today just having the ++ and -- operators throws a monkey wrench into the optimizer as it does not allow for fine grained parallelism.
Slashdot Mirror
Sounds like you have an excellent service there!
I did not know about it.
Are you able to make a bare winelib work under non-intel architectures?
--jeff
yes mp3 is a standard. so is minidisc.
The similarity is that both are proprietary standards.
See:
http://www.mp3licensing.com/help/developer.html
I want to support mp3/mp3PRO in my products. Do I need a license? YES
I have my own/third party mp3 software. Do I need a license? YES
Do I need a license to stream mp3/mp3PRO encoded content over the Internet? YES
Do I need a license to distribute mp3/mp3PRO encoded content? YES
Time to read up on http://www.vorbis.org/ and support them instead.
--jeff
Does anyone actually use winelib?
For me, winelib is the most interesting part of wine. I have win32 code I would like to just port to linux/X without doing a rewrite. In fact I want to port it to both i386 AND powerpc. I'm not interested in 386 DLL loading and crud like that. I just want to use it as a portable widget library. Yes I know of other portable widget libraries but it is too late for these old programs.
I found that winelib didn't even come CLOSE to compiling on linuxppc.
Making winelib robust would allow other software houses to release native linux ports of their win32 software much easier.
--jeff
How about this?
(Slashdot
((Editor
(type Full-Time)
(worthless-stock-options yes))
(name CmdrTaco)))
--jeff
"....XML allows two systems that do not share a predetermined data exchange protocol to share data..."
Isn't that statement an oxymoron? If both systems understand XML then they DO 'share a predetermined data exchange protocol.'
--jeff
Very good question. Some people here actually got good solutions that appear to work without memory leaks.
/* Here we do something */ will cause the application to be immediately terminated. No error codes, no way to handle it. In fact, other apps running at the same time may get terminated as well if they need to allocate memory.
HOWEVER
The next step is to take the platform into account!
Let us run the code on Linux.
GUESS WHAT? malloc() will almost never ever return 0 under Linux!!! Even when there is NOT enough memory (phys+swap) available! Try it! Allocate 100 megs 5 times on a system with 256 megs of ram+swap. It works.
It is a 'feature' called memory overcommit.
malloc() returns a pointer to a bunch of virtual memory space. The actual memory pages are not allocated until you TOUCH EACH MEMORY PAGE!
So, in linux you may as well just ignore the return values p1,p2 and p3 and just go ahead and use them. If there isn't enough memory available, the code you have at the point
Eiffel and C++ exceptions don't help either. The c++ 'new' operator WILL NOT THROW any exception. It will not return 0. Your program will just spontaneously terminate, LATER.
Do a search for 'Endless overcommit memory thread' in the linux kernel archives to read more about this behaviour.
Error handling is unfortunately more complex than just handling return codes properly.
--jeff
Well, I agree with you.
--jeff
I use threads all the time! I just don't like them to be forced. However I'd like them better in a language that officially SUPPORTS them. C++ is not that language, unfortunately - think thread safe std::string, STL and exceptions, race conditions in singletons without a double guard (therefore the inability to have non-trivial constructors in static members of a class without wrapping them in a thread-safe dynamic singleton allocator object), debuggers, core dumps, profiling tools, memory leak checker tools, lack of warnings when using shared data without a semaphore, etc..
I've been using BeOS for ages and actually had a PPC BeBox too! Still have BeOS installed (which kernel panics when my real Roland 100% standard MPU-401 MIDI interface receives a MIDI byte).
Worked with www.lcsaudio.com where they are STILL SHIPPING commercial software for BeOS. At one point LCS had more BeBoxes than any other company besides Metrowerks. I used to be an enthusiast.
Not anymore.
I can't count how many BeOS applications are written with threading problems! Is it because most programmers actually suck?
Yes, most linux GUI's responsiveness sucks. No, having a seperate thread for each window would NOT always help - Most X apps only have one window anyways. However, having seperate non-gui worker threads WOULD help and should be done when appropriate.
--jeff
Be Happy! Inefficiency fosters economic growth!!!! You are all sitting around going through scripts, wasting time and getting paid! It is good for the economy!
--jeff
Hmmm.... But it IS interceptable! All you need to do is have an array (or matrix) of listening devices near the transmitter. Then with (massive?) computing power you should be able to search for the sort of correlation that the transmitters form. Right? Probably would help if you knew the distance to the submarine too.
My question though is why not just steal the buoy?
--jeff
Is this true?
What airport did this happen at?
--jeff
I agree, Glock27.
The kernel could be using C++, I understand the reasonings for that. However if you want to use GOOD C++ with Resource Aquisition Is Initialization (RAII) or have any non-trivial constructors, you NEED c++ exception handling, which can throw a big wrench into your special stack frames.
STL would actually be NICE to use within a kernel however!
The C++ API caused tons of stupid problems and workarounds in BeOS. Not only did they have to reserver vtable slots (in the right order!) they had to make sure that any methods that could be inlined were not if they might possibly be changed to non-inline in the future.
The BeOS api was started a long time ago - before the ANSI C++ standard came out. There are a number of design decisions that Be made back then that seemed reasonable then, but are not good now.
For instance, they should have designed their interface classes to contain pImpls - yes it is an extra redirection but it allows for dynamic library compatibility. Also, there should have been less focus on inheriting non-abstract system base classes. All user classes that the system needs to know about should be inherited from a pure abstract system base class. It would also potentially make their BLooper message dispatching system nicer - like libsignal++...
But one BIG problem with BeOS (besides bugs and slow networking) is their use of threads for EVERYTHING, in the language of C++ which officially has no concept of threads. Yes, you can do it but it is like fitting a square peg into a pentagram. Maybe Ada95 would have been a better choice? But that wouldn't be 1337 then I guess.
--jeff
heh! Well I guess I should upgrade to 10.1 then! I know it wasn't available for the entire last year. I think HP or someone like that had a patent on the 'thunking' technology used in Objective C++.
I'm glad it is at least available now! Thanks!
--jeff
Boy, that article sure is a stretch.
In reality however the real analogy would be that Microsoft represents an airport with shoddy security like the Boston airport was - Boston airport was fined many times previously by the FAA for failing their security tests.
Therefore, Microsoft should be fined by the government for shoddy security in IIS! They are allowing terrorists to wreak havoc!
--jeff
Unfortunately there IS no Objective C++ available anymore. Something about a patent violation, seriously. This severely limits my usage of Cocoa. This is why libQT for MacOSX is so good. Without it, everybody wanting to use C++ on MacOSX would have to thunk to C to call Objective C Cocoa libs, or use C++ with the crappy Carbon libs.
--jeff
For a capitalist closed source competitor, Free Software is a nightmare came true. You can't out-invest it, you can't bankrupt it, you can't stop it.
Correct.... But you CAN lobby to make it ILLEGAL.
--jeffIs this a joke? I hope so.
/
If it isn't, PLEASE research recording contracts. Very very few popular bands make money from record companies. Read how it really works at http://www.salon.com/tech/feature/2000/06/14/love
--jeff
Probably they will "Make Windows the best operating system to run .NET on" in similiar ways that 10 years ago they made "Windows the best operating system to run Microsoft Word on" by adding busy loops in their programs to slow them down if they detected that they were running in OS/2's Windows compatibility mode.
I'm not convinced (yet)
--jeff
LOL!!!
No, I am an escapee!!!
I'm in Vancouver now. (whew!)
sorry this is off topic
--jeff
>> too bad you were using windows
Yes, i'm sorry. I'm on linux-ppc with mozilla now!
feel free to email me though
--jeff
Qt is not as bad as most GUI frameworks. Gtk-- is better, but 'inti' ( http://sources.redhat.com/inti ) whenever it is done would be even better still (Anyone know what's happening with that?)
One of the unfortunate requirements with Qt is the ability to be compiled with VC++ 6. This alone causes problems with wanting a good design. I myself have found cygwin/mingw32 to finally be usable for all my win32 projects, so maybe now we can drop the 'lame compiler compatibility' requirements.
I think that the presence of the signal/slot preprocessor for Qt shows a fundamental problem with practical C++. I didn't say Qt was 'GOOD' I said for the most part it is OK. Better than Microsoft's MFC and Borland's VCL. Better than wxWindows. A real option for multiplatform apps.
--jeff
Sigh... I just spent 10 minutes typing in my response and then slashdot/IE killed my post.
I'll do the short version.
#1 Most people who say they are C++ programmers actually are not properly educated in it, and have no or very little understanding of exception safety, const correctness, mutable, co-variant return types.
#2 Code re-use is a fallacy. Very often projects are factored way too much in the name of code reuse. What is important is GOOD DESIGN MEETING THE SPECIFICATIONS. Code re-use may or may not be part of that. When it is, it is a major thing. It does not come automatically because you typed 'class' instead of 'struct'.
#3 The C++ Fragile Base Class Problem. http://2f.ru/holy-wars/fbc.html
#4 C++ is a multi-paradigm language. Not only procedural, not only pseudo-OO, but generic programming too. Quite often the generic solution is the best solution under C++. I've never actually physically met more than two people who understood generic programming. sigh.
#5 Many C++ compilers just plain suck. You have to code for the lowest common denominator for the platforms that you are interested in.
#6 There is no (and can be no) standard binary API for C++ libraries. Other languages have a much harder time calling C++ libs than C libs.
--jeff
Unfortunately, too many people who are ignorant about the issues are jumping on the C++ bandwagon.
I've been using C++ since 1990! I helped port g++ v1.35 to the Atari Mega 4ST. I've followed the language evolution all the way till now. Many of my projects use C++.
Yet, many C++ projects that I see being done by other people are horribly misguided and doomed to failure. There are very good reasons to want to stick to C code!!!
Trolltech's QT lib is NOT one of them. For the most part, QT is ok.
--jeff
Very good points.
I myself have found very very little new music from RIAA affiliated companies worth listening to.
If you don't like the RIAA, go find local original bands in your community and support them and the local live music scene. Make sure they know about the fallacies of the 'Big Record Deal.'
--jeff
The reason for the silly ++ and -- operators is simply because of the lack of good optimizers long ago.
"*s++ = *t++" directly maps to a SINGLE instruction on many CPU architectures. eg: 'move (a0)+, (a1)+'
Those operators made it easier to make the compilers use the capabilities of the CPU.
Today, optimizing compilers can and do figure this out all on their own.
Number of keystrokes was not the issue. Too bad it has infected so many languages since. In fact, on some CPU's today just having the ++ and -- operators throws a monkey wrench into the optimizer as it does not allow for fine grained parallelism.
--jeff