Just like most anything, it doesn't cure everything automatically. It takes study, planning and good-judgement to determine the design and use of the necessary feature-set. Any code/library/middleware touted as "helpful" can't just be slapped together and expected to perform miracles.
As far as bugs go, yeah, ACE is still under development and still has some quirks and some features that just plain don't work, but they are publicly acknowledged and there are always workarounds. New versions are appearing somewhat regularly.
I use ACE for some personal programming, but our company is using ACE on a large OO project and I can say that things would take 2x as long if I had to use POSIX or System5 message queues, semaphores, shared memory, UDP, etc... Plus you get the added benefits of *mostly* platform independent code. (Those bug-workarounds _always_ break interoperability.)
I whole-heartedly agree with this. Many large corporations and projects are using ACE with lots of success. I find that multi-threaded and/or multi-process application development is simple and straightforward. We are only using the wrapper-functionality of ACE for the most part, but when combined with the pattern-abstractions and implementation, you can really achieve some well-designed, well-performing, cross-platform code.
If by "dum," you mean "grammatically correct and worded in such a way as to elicit (mostly) valid responses from (mostly) intelligent individuals with (mostly) worthy comments and insight to share," then yes, I concede that my post was indeed "dum." My apologies.
But if it is so "obvious" that the benefits are worth the cost, why don't you see more large development firms utilizing them. I don't exactly work for a 2-man, backwoods operaion. I refuse to believe that multi-monitor setups are some sort of secret productivity-boosters that only a priviledged few are aware of.
One thing I did come across was several software packages that claim to have tamed the multiple-monitor beast. Some, like Ultramon , seem to integrate well (with MS OSs) and attempt to provide some common sense to windowing actions. There's also Matrox's software thay may performs similar tasks. I haven't actually used any of them however, but they may address some of your issues. But of course, that means possible added complexity for our massive IT department.
But is there a limit to this? It seems that having 12 monitors would only serve to slow things down as you try to find where you put things. There should be some optimal solution, based on the type and amount of multi-tasking one does. I would think that it also depends on the user. Some highly-productive developers may experience tremendous gains when moving to a multi-monitor environment. Yet, some might actually never use the extra equipment or worse, lose productivity by trying to unsucessfully. That raises the issue that maybe not _everyone_ needs a multi-mon setup, which of course, opens a whole new can of worms. Do we use the same criteria that we use for office/cubical sizes? Seniority determines screen size? Performance ratings or voting? Volunteers?
It seems to me that 3 monitors would be ideal. (perhaps a central 19' or 21' CRT with a 17' LCD on each side) would be ideal. You could have your IDE or editor(s) open in the center monitor, the design document or diagrams on one of the sides, and an algorithm document, requirements document, manual, or other aid on the 3rd. I know I use a _lot_ of paper printing documents so that I can put them on a stand by my monitor while I code.
Slashdot Mirror
Just like most anything, it doesn't cure everything automatically. It takes study, planning and good-judgement to determine the design and use of the necessary feature-set. Any code/library/middleware touted as "helpful" can't just be slapped together and expected to perform miracles.
As far as bugs go, yeah, ACE is still under development and still has some quirks and some features that just plain don't work, but they are publicly acknowledged and there are always workarounds. New versions are appearing somewhat regularly.
I use ACE for some personal programming, but our company is using ACE on a large OO project and I can say that things would take 2x as long if I had to use POSIX or System5 message queues, semaphores, shared memory, UDP, etc... Plus you get the added benefits of *mostly* platform independent code. (Those bug-workarounds _always_ break interoperability.)
I whole-heartedly agree with this. Many large corporations and projects are using ACE with lots of success. I find that multi-threaded and/or multi-process application development is simple and straightforward. We are only using the wrapper-functionality of ACE for the most part, but when combined with the pattern-abstractions and implementation, you can really achieve some well-designed, well-performing, cross-platform code.
If by "dum," you mean "grammatically correct and worded in such a way as to elicit (mostly) valid responses from (mostly) intelligent individuals with (mostly) worthy comments and insight to share," then yes, I concede that my post was indeed "dum." My apologies.
But if it is so "obvious" that the benefits are worth the cost, why don't you see more large development firms utilizing them. I don't exactly work for a 2-man, backwoods operaion. I refuse to believe that multi-monitor setups are some sort of secret productivity-boosters that only a priviledged few are aware of.
One thing I did come across was several software packages that claim to have tamed the multiple-monitor beast. Some, like Ultramon , seem to integrate well (with MS OSs) and attempt to provide some common sense to windowing actions. There's also Matrox's software thay may performs similar tasks. I haven't actually used any of them however, but they may address some of your issues. But of course, that means possible added complexity for our massive IT department.
But is there a limit to this? It seems that having 12 monitors would only serve to slow things down as you try to find where you put things. There should be some optimal solution, based on the type and amount of multi-tasking one does. I would think that it also depends on the user. Some highly-productive developers may experience tremendous gains when moving to a multi-monitor environment. Yet, some might actually never use the extra equipment or worse, lose productivity by trying to unsucessfully. That raises the issue that maybe not _everyone_ needs a multi-mon setup, which of course, opens a whole new can of worms. Do we use the same criteria that we use for office/cubical sizes? Seniority determines screen size? Performance ratings or voting? Volunteers?
It seems to me that 3 monitors would be ideal. (perhaps a central 19' or 21' CRT with a 17' LCD on each side) would be ideal. You could have your IDE or editor(s) open in the center monitor, the design document or diagrams on one of the sides, and an algorithm document, requirements document, manual, or other aid on the 3rd. I know I use a _lot_ of paper printing documents so that I can put them on a stand by my monitor while I code.