BTW: this is a heap allocation scheme. Very similar to the one used on the early mac, and some other machines. Basically you copy memory around once you discover that the heap is to fragmented to make the next allocation. http://en.wikipedia.org/wiki/Mac_OS_memory_managem ent
See my comment to the AC on stop and copy, and how people have been using similar schemes for heap managment, any why they fell out of favor. BTW what do you think the copy operations are doing if they arn't merging blocks? Also, how do you think the GC runs in a finite amount of memory if its not reusing blocks? Or for that matter were does the memory for the copy operation come from if there isn't some kind of region management?
Just because I am talking about C++ and Java which were the initial choices doesn't make it true that is all I have programmed in. I list 7 major computer languages on my resume that I have written extensive code in, without counting the dozens of scripting languages used for small side projects or pieces of larger projects, or languages I learned to gain experience. Pick another language that implements GC better, that you don't think is as flawed. How about lisp or smalltalk?
Jesus christ, the simple copy active regions type of heap managment (of which stop and copy is a subset) is one of the most simple types of heap managment algorithms out there. One of the reasons it fell out of use for general heap management was the requirement to double derefrence all memory through double pointers, or to manually go through all refrences and update them when the copy operation happened. Plus of course the overhead of copying memory regions around, which gets worse every year due to the fact that main memory accesses are getting more expensive. When I started programming IO and memory use was cheap, and we optimized for conditional checks, today you have to optimize for memory refrences, conditional checks are basically free.
Your model of how garbage collectors work is completely wrong. High performance garbage collectors aren't a layer on top of a C/C++-like heap allocator--that would be horribly inefficient--they use completely different allocation strategies
Like what? There are dozens of heap allocation algorithms, whether or not the heap allocator is integrated into the garbage collector, or a call out to some routine is sort of irrelevant. The fact is that somewhere in the garbage collector there is some form of heap allocation/deallocation. Whether you choose to call it that or not will probably affect the maintainability of your code, more than the performance characteristics of the GC. At some point characteristics like how you select a region to be broken up, how you reuse allocation, or how you merge adjacent regions back in is a heap management problem not a GC problem.
Your right of course that a lot of language features that java and C# claim to be new are decades old, most BASIC's did GC, a number of OO languages, had dynamic binding. C++ became popular despite the lack of these features, which indicate that maybe they aren't as important as everyone would like to think. Things like true dynamic OO as represented by old school activex,COM,DCOM,OLE and now the.net components are one of the only cases where its truly proven to be helpful, and all those technologies had multiple language bindings including C++. Its the same with a lot of operating system features, mainframes from the 70's pioneered many technologies claimed by Linux/Windows/Mac crowds.
I used to think so myself, but after using C++ professionally for 20 years, I can say without a doubt that C++'s flexibility is its weak point: it has enormous project management costs and no significant benefits.
This is almost entirely dependent on your development organization in my book. The project I worked on before my current one, was lead by a C++ weenee that tried to use every feature in the book because he could. It was a mess, and impossible to work on. The current one I lead, uses a number of "advanced" C++ features, but they are used to aid maintainability. Overriding the array index operator, on a couple of utility classes used everywhere in the code so that we could use strings as array indexes, cut literally thousands of lines of BS code. Changing the locking model from a pthreads style lock to a declare the lock and then declare a class to lock it model, saved thousands of lines of exception handling code that had to be wrapped around lock/unlock pairs. Using exceptions from the bottom up, saved thousands of lines of `if (errorcondition)` code, now the exception propagates to the top level and the transaction is canceled with the possibly to retry or simply return an error. Our application has yet to be shown to leak any memory, the few that were there didn't make it out of development due to automatic memory leak detection tools, and use of automatically constrained memory buffers avoid buffer overflow problems. The flexibility allows a very small team to achieve similar results as our competitors do with 10x-25x the manpower. We have a couple of UI's one is written in java and the backlog of features in the C++ portion of the code that are not supported into the java code is enormous. Well maintainable code is more a function of the software engineering practices enforced than the language chosen. The java part of our product has actually had more memory leaks than the C++ portion, proving again that GC can fail. Heck even java now has classes which can be used to control explicit allocation/deallocation.
You're incorrectly assuming that other languages can't use stack allocation (they can, and do, and do so more than C++), and that the C/C++ memory allocator is "fast" (it isn't, relative to a good garbage collector).
I never said that, I thought we were discussing C++ vs's newer languages like java and C# as they relate to having runtime features C++ doesn't have. My original assertion was that C++'s lack of many of these features 25 years ago wasn't a mistake due to constraints of the time.
but C++ almost always loses in terms of programmer productivity and software quality.
I find this to be overgeneralization, I've been involved in a large range of projects over the years using just about every major language, in nearly all the cases C++ found, or could have found a section of the project where it was the best choice for the problem. Of course I tend to use C++ as a better C, which means that just about anywhere I see C code I prefer to use C++ even if 99% of the resulting code could have compiled with a C compiler. When matched with languages like PHP for web development, RAD GUI builders (VB,Delphi,C# etc) for GUI development, database and assorted other tools, the result is impossible to beat with any single language and hard to beat with other combinations. C++ is an incredibly flexable language, that is its strong point. There are C++ libraries that put in on par with the best languages designed for specific purposes. For example, Borland C++ builder, is a far more productive enviroment for GUI development than _ANY_ java enviroment i have ever used, the diffrences are stunning. The resulting code is often of amazing high quality (as measured in customer defects per LOC).
Oh, and BTW, what general purpose garbage collection algorithm which doesn't require a heap allocator, is faster than just using a general purpose heap allocator? I'm afraid you don't understand that most garbage collectors also have heap allocators, and that C/C++ and many other languages skip the middle man and simply use the heap allocator. GC's are added for programmer safety not performace. A particular C++ implementation may have a slow allocator relative to your problem set, that is why there are other specific purpose allocators and other compiler/library/OS vendors. The C++ language standard doesn't describe how the allocator is to work. My opinion of the java GC isn't all that high either, but I know that getting a GC correct in 100% of cases is _REALLY__REALLY_ hard unless you constrain your language so much that its unusable. The fact that it works as well as it does, says a lot of positive things about the tradeoffs being made.
Name mangling doesn't slow the code down, thats a linker problem... Vtable lookups arn't there unless you use virtual methods, C code calling through function pointers is just as slow. Its not an apples to apples comparison. The point is that you _CAN_ compile C code with the C++ compiler, and then sprinkle C++ where it helps. That is why C++ is not slower than C, sure you can write C++ code that is slower than C if you choose to, I can do exactly the same in the converse with proper use of C++, of corse the slower code will probably compile in the C++ compiler as well so the whole argument is bogus. That is why its just plain stupid to say that C++ is slower than C, because C is a subset of C++.
Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.
That's not how GC costs work; GC isn't some big, fixed overhead that you can only afford once you have a fast machine. Rather, GC costs a certain number of cycles per byte allocated. That means that the impact on a normal program running 10 sec on an 8 MHz machine is the same as on a normal program running 10 sec on an 8 GHz machine.
Furthermore, then, as now, a good garbage collector reduces the total amount of CPU spend on memory management compared to C++'s manual storage management scheme; C++ memory management is highly inefficient.
Ok, so I exadurated a little about the 100% CPU, but the point remains. I suspect you don't really know how java does its garbage collection. Here is a nice starting point http://www.javaworld.com/javaworld/jw-03-2003/jw-0 307-j2segc.html?page=1. When your done please explain to me how that can be faster than a simple stack allocation (usually precomputed by the compiler and done when the initial stack is setup on procedure entry) done in C/C++ or a fast O(1) heap based allocator. After all the BS about garbage collection, there is still a heap sitting under it all, and the same heap algorithms are used in C/C++ as java. In fact you can change the heap allocator in C++ if it doesn't match the performace characteristics of your application.
Now, i've seen dozens of programs written in both C++ and java which are written to prove that java has faster memory allocation because of the garbage collector. In ever single case, the C++ example makes some major mistake which would not be made by an experienced C/C++ programmer. Once that mistake is fixed, the C++ version runs anywhere from as fast to significantly faster than the java version, as measured by total wall time. Usually the C++ mistake is there to give the implicit object reuse the JIT did a big boost. The point here is that while you may be able to make C++ programs slower than java, there is usually some way to tweak the C++ program to reverse the situation.
Oh, and while C++ may not have been designed for 64k machines, I ran C++ compilers in DOS and on the early mac's neither of my target machines had 2M of ram.
I don't know about your CS, but I've never heard a pointer to a pointer called a vector. I've always used vector in the same sense as math class. Which BTW, the STL vector conforms to, because it is an n dimensional vector AKA an array. A quick google search on vector didn't yield any results, got any references? I'm just curious, terminology is definitely not always standardized.
Secondly, a HWND is a pointer to the WND structure which is a reference to the window. Just because you can't easily dereference it with your debugger doesn't make it so. On 16-bit windows the HWND was a pointer to a localalloc heap owned by USER and GDI (all you have to do is find the right heap). On 9x systems this was modified slightly and some games were played at the last minute before release to extend the GDI heap past 64k. But its still the same basic game, look at windows 95 system programming secrets for some info. You again need to find the base of the GDI DGROUP to dereference it. With NT its still there, only its read-only (since you could dork with other processes windows if it wasn't), again the game is to find it. Here is a good start http://www.winterdom.com/dev/ui/wnd.html
Now maybe we are discussing semantics, I guess you might define anything that isn't directly dereferencable as a token. I'm calling it a pointer because in the right context it is. I do system programming for a living and I'm used to something only being a "pointer" in the correct context. By this maybe we would like to call the "token" an index or the converse. Whatever...
25 years ago Stroustrup wasn't wrong, I would like to see you run a modern java enviroment on a 64k machine (no, the embedded java systems that remove most of the language don't count). Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.
When you need high performance, C++ is better choice than any other language.
Bullshit, C is.
Not to get into a holy war here, but please show me a program for which your C compiler generates better code than the equivalent C++ compiler does on the same code. For the same code its generally the same damn thing, C++ is just more tools in your toolbox. You don't have to use the extra crap in C++ unless you have a reason. I use C++ exclusively (vs C, I use lots of other languages too, just not C) because it reduces problems with C when used properly, and it provides some powerful constructs that are hard to simulate without a lot of extra overhead in C. There are dozens of cases that short of writing 100x as much code in C, simply cannot be matched for performance. I would like to see your implementation in C of a matrix library that supports a dozen element types ranging from simple ints, floats, vector types to arbitrary precision math that matches what can be done with a template class.
There are gains in everyday tasks as well, C++ exceptions can significantly speed up business logic type code by removing thousands of "if (error)" checks, on some architectures virtual methods are faster than C function pointers in structures, the list goes on. Of course i'm not a purist, I use lots of calls to sprintf, some things are better in C++ syntax some are better in C, I like to have the choice.
The best intro language remains to be pascal. I don't know why people get so fed up with it. Sure it's not as powerful or as popular as C/C++/Java
I'll buy part of that for $1. Pascal is probably the cleanest language I have ever used, Object Pascal is probably the cleanest OO language I have ever used (part of that may be my bias towards borlands VCL, stuff just worked the way it should). I would say that Object Pascal is more powerful than C (C's strengths in low level stuff _can_ be achieved in pascal with a tiny bit more work, and the OO in OP is way more powerful than anything in C). OP is less powerful than C++ (due to generics and some other stuff), and more powerful than Java although its close.
In the case of java the recent addition of lightweight generics give it a plus there, but its lowlevel support is for shit (aka DNE), and I've found the dynamic nature of java to be misused the way weak typechecking and multiple inheritance in other languages is misused. By this I mean that if you find yourself needing weak typchecking, or multiple inheritance you had better start wondering about the structure of your algorithm/program. Then there is the java one true way which makes everything a nail to be attached with your nailgun. So OP wins in my book.
I can understand the switch from pascal to C++, that was due to industry pressure, why teach a language no one uses, just teach people C++ and hopefully they will get around the gotcha's. But java? Jeeze java had a big bandwagon, but I have never really seen the advantages, a reasonable look at the language soon determines that all of its strong points are either stronger somewhere else or are masked by some other critical issue in the language. Seems to me the people calling themselves "software engineers" are still using C/C++, the people calling themselves "programmers" can't quite settle on a language and at the moment C# seems to be winning (a language that has more credibility than java in my book, it has some serious strong points).
the first parameter isn't a pointer, but a window handle (hwnd).
Just a minor pick, but a HWND is a "pointer" in this case to a pointer. Where I come from a handle is defined as a pointer to a pointer. This is due to proper heap managment. Today most people just assume that the virtual address space is unlimited and they don't worry about heap managment. Heap compression is a a very valuable idea, if a little lost in the modern world of 64-bit virtual address spaces and fixed size pages. Windows is old enought to know what a handle is if you read the goobly goop in the header file you find that it is a pointer to the declared type. Wikipedia defines a handle as a smart pointer http://en.wikipedia.org/wiki/Smart_pointer and points out that the values acting as pointers can be array indexes or something similar (in the case of unix file handles) but the concept is the same.
BTW: I'm of the school that C programmers are C++ programmers with less education.
This guy is smoking some serious crack in a couple of places, he talks about how difficult it is to do transparency? Hello I wrote a little piece of code to make transparent windows back with turbo pascal on a 386.. If my 386 could do it i'm sure you don't need a GPU... Just because transparency wasn't in the basic GDI (which is even older) doesn't mean it was hard or even that slow.
This is where the concept of a cell comes in. Want more bandwidth? lower your power and increase your cell density. Even if you put a microcell on ever light pole in the neighborhood its probably cheaper than breaking ground and upgrading to fiber. Sure, with _today's_ equipment its not cheaper to do this, but in the long run it will be.
That isn't the point, the cells can only get so small (until you basically have a wire) and consume so much bandwith without interference. Where is compared to a fiber bundle you simply add another bundle to the existing one. The capacity of few strands of fiber is a lot larger than the capacity of any modern over the air transmitter. If this wern't so, the internet would be running on cells of microwave transmitters instead of fiber bundles (or for that matter cell towers would be connected over the air instead of by cable). Create a network where hundreds of strands run to everyone's houses and you will be set for the next few hundred years, just upgrade the head units and the in home boxes.
This is all because the telcos are on a sinking ship. Wired communications (for anything other than long-haul, high-bandwidth) are on their way out. The simple fact is that some bigass high-gain omni antennas (which can be built cheaply if you're on a small budget) are a fuck of a lot cheaper than a bunch of poles with bundles of copper wire on them or, god forbid, a bunch of poles with fiber on them, and a bunch of equipment to split that fiber out to subscribers
This simply fails to understand that fiber is shielded and doesn't experience cross talk. With fiber, if you need more bandwith you simply lay more fiber. With wireless you are bound by weather conditions, atmospheric conditions, solar flares etc, and other people using harmonic frequencies of your own. There is a limit to the amount of bandwith that can be sent wirelessly even using directional antenna's and point to point microwave links (because there really isn't a such thing as tight beam). Eventually its simply not possible to add more bandwith without eating larger and larger parts of the spectrum. That even has a limit, depending on where the maximum freqency we can build transmitters and recievers. This is why we have goverment bodies like the FCC, and a large part of the usable spectrum (given todays tech) is already consumed.
The real problem is that the telco's are unwilling to take a temporary loss of profits to reap long term benifits. Eventually some upstart is going to run a bunch of fiber and sell the bandwith cheaply the the existing telco's will be in the same boat as the big airlines. Basically screwed until they go out of business leaving the field for stronger competitors. It will probably take another 30 years, but it will happen. For example look at Cogent Communications...
Everyone seems to think the PS3 is going to be so much better than the Xbox3. It seems to me to be a repeat of the xbox vs ps2. Originally everyone said the Ps2 was going to blow the doors off of the xbox, but then it turned out all that wierd hardware didn't really perform as well as everyone expected. There is a distinct posibilty the same thing will happen this time around. In a couple years we can decide which was better, right now i'm leaving my opinion up in the air, and I wish everyone else would too.
Without support from Microsoft (who has no real financial interest in HDCP), HDCP will probably fail in the marketplace.
Basically true, except M$ thinks they see the writing on the wall for standalone PCs. In 10 years they are thinking the media center box will be all people buy at home (because it will be able to surf the web, send email, play games, and even maybe run a word processor and financial software). Without the blessings of the entertainment industry a M$ media center box won't sell a single machine. If the entertainment industry says they won't sell summer blockbusters without DRM M$ pretty much has to get onboard. They figure its better to lead the pack than play catchup. M$ needs to evolve and leverage its desktop OS+Xbox+mobile devices into the media center space rather than try to release yet another product ahead of its time. Without the DRM they can't leverage windows if it won't play any summer blockbusters. So its not true that M$ doesn't have a financial intrest in DRM, they _HAVE_ to have it there as long as the entertainment industry wants it. The second the entertainment industry (or more likely goverment) says DRM is bad then M$ will pull it, not one second sooner. Frankly I suspect that in 10 years i'm going to have to be buying PC's that cost 100x as much as they do today because the mass market will be gone and instead everyone has playstation 5's, playstation laptops or something similar that do 90% of what a PC does today. With high def screens there is one less reason to have a PC.
This is the same argument made 7 years ago for media center PC's. Everyone declared them dead back then because the few that were released flopped. I suspect that its just a case of an idea being to early for its own good, those machines had crappy displays, didn't play games, USB wasn't common enough for everyone to have USB printers, camera's, etc. PC's were not common in the living room, today they are as video scalers, dvd players, mp3 colletion points etc. All that in 5 years, in another 5 years we can have this discussion again. They won't kill the PC, but they sure will make buying a PC with a lot of slots and the like harder.
I disagree with your interpretation of the MySQL commercial license. It seems to me like you are free to use it for commercial uses so long as you do not distribute it.
Try actually reading the Mysql license, its really restrictive, and we _DO_ distribute our software which means we don't really fit into any possible loopholes, seeing as we sell it.... The 30 second version is that mysql considers any connections to their database to be a link, (partly because of the libraries) and therefore its technically violates the GPL if you connect to it with non GPL code. So yes even if it were for internal use we would have to comply with the GPL.
On top of that, nobody is forcing you to use an RHEL kernel; you can use any kernel you want. The only limitation is that you couldn't install a POWER kernel on ES, since it doesn't have the packages for the POWER processor. Essentially the only real difference between ES and AS other than the lack of support for the IBM POWER arch in ES is the support option differences between the basic and standard packages.
That is crap too, we have a particular software package that ships binary drivers that only load on two or three different RHEL patch levels of kernels. That effectively ties us to the RHEL version the vendor specifies. I have done extensive OS kernel development, and there are patches in the mainstream linux kernels with my name on them, it still took me nearly a week with a debugger, hex editor and some other tools to get the proprietary driver loaded in a different kernel version. At which point our support agreement would have been voided with the software vendor providing the binary driver. So, it was pretty much just an exercise in seeing if I could do it. I seriously doubt 99.9% of the "competant linux admins" out there would even know where to start doing something like that.
I understand that SQLite (which is ideal for embedded situations as you describe, and is faster than MySQL for most tasks)
Just because its embedded doesn't mean "light weight". Mysql strains under the load and we use its "advanced" features extensivly, which will probably force us to choose another database in the near future, but it sure won't be some kid's version of a sql parser, our stuff is very critical and the mysql transaction support isn't really sufficient for our application anyway...
Nice load of crap, until recently the only choice for commercial use of mysql was the $1499 enterprise license, which wasn't year limited. Now the choices all seem to be per year.. M$ starts at free for the express edition (which is freely redistributable even for commercial use, but has limits on the number of CPU's and RAM it can use, and goes to about $4k, which you don't have to keep paying for. The base standard edition of sql server is $900 which is two years of basic mysql. Mysql is free for opensource use, but commercial use of it doesn't count as opensource if anything connecting to the box isn't opensource.
Red hat enterprise edition used to be ~1.5k per license and was node locked, while the base windows server licenses were 1k. That has changed so the basic windows license is now ~370 (ive seen them as low as $150) bucks for web edition (unlimited cal) ~550 for the standard edition (5 CAL) and $800 for the small business version which has sql server, sharepoint outlook etc already included.
says the RHE ES is ~349 bucks, basic edition and goes to $800, AS is ~1500 to ~2500. ES and AS have been in the past diffrent kernel versions and such, We have software where I work that _ONLY_ runs on AS forcing us to buy the $1500 versions to get the updates. This ends up costing us more per machine than the extra CALS for the windows box. In fact last year we spend nearly twice as much on the linux machines as the windows ones. We also ship a product that uses mysql as an internal database. The per year licencing costs are a very significant portion of the sale price of the machine over the expected 10 year lifetime of the products in customers locations.
But the problem is that Windows IS broken. The annual cost of dealing with security problems, viruses, worms, spyware, etc. is staggering. There's lots of great reasons to abandon the Windows platform.
This is the same kind of FUD that the linux people accuse the windows people of throwing. There is _absolutly_ nothing in linux that is inherintly more secure than windows. Linux has bug after security bug just like windows and its less than a few percent of the total market which makes me think windows is probably more secure. I've been using windows for a long time (linux too for that matter, I have CD's with.9x series linux kernels). In all that time i've never gotten a virus and companies I work for have had little in the way of virus problems. I've seen them but they are in no way as big of a deal as people make them out to be, its like the war on terra... 2 thousand people die and its all the US talks about for years, and spends billions of dollars fghting. Its the same with windows, there is a CNN windows security article about a bunch of people getting infected because they are running insecure machines, or they didn't keep there machine patched and the/. crowd thinks "windows is broken". Bah...
Well this hits on the core argument... Why switch at all? The only reason most opensource projects have for switching is a higher ideal about whether or not source code should be avialable for a program. While I would love to have source code for every application I use, only programmer types really feel that way. The majority of computer users today just want an application that does what they want without getting in the way. Even if gimp does 100% of what photoshop does there are still going to be a number of people buying photoshop and using it simply because that is what they are comfortable with, the few hundred dollar price tag is insignificant compared to the hours it would take to become profficient in a new enviroment. Learning all the shortcut keys, and where items are in the menu takes more than a few hours. Its like linux, sure you can show someone how to start start star office and spell check their document in a few minuites but the user isn't going to know nearly as much about the enviroment after a few hours as they know about windows/word after having used them for years. Its the old don't fix it if it isn't broken syndrome. Combine this with the fact that many opensource projects cost just as much as their commerical counterparts just makes me wonder.. Why for example does it cost more to get a basic MySQL license than a SQL Server license? Why does Red Hat Enterprise Server cost more than Windows 2003 Server? Sure there are CAL licenses issues for some of the windows services, but a lot of the opensource projects run on windows too. I can run bind/apache/etc on windows as easily as linux.....
Slashdot Mirror
BTW: this is a heap allocation scheme. Very similar to the one used on the early mac, and some other machines. Basically you copy memory around once you discover that the heap is to fragmented to make the next allocation. http://en.wikipedia.org/wiki/Mac_OS_memory_managem ent
See my comment to the AC on stop and copy, and how people have been using similar schemes for heap managment, any why they fell out of favor. BTW what do you think the copy operations are doing if they arn't merging blocks? Also, how do you think the GC runs in a finite amount of memory if its not reusing blocks? Or for that matter were does the memory for the copy operation come from if there isn't some kind of region management?
Just because I am talking about C++ and Java which were the initial choices doesn't make it true that is all I have programmed in. I list 7 major computer languages on my resume that I have written extensive code in, without counting the dozens of scripting languages used for small side projects or pieces of larger projects, or languages I learned to gain experience. Pick another language that implements GC better, that you don't think is as flawed. How about lisp or smalltalk?
Jesus christ, the simple copy active regions type of heap managment (of which stop and copy is a subset) is one of the most simple types of heap managment algorithms out there. One of the reasons it fell out of use for general heap management was the requirement to double derefrence all memory through double pointers, or to manually go through all refrences and update them when the copy operation happened. Plus of course the overhead of copying memory regions around, which gets worse every year due to the fact that main memory accesses are getting more expensive. When I started programming IO and memory use was cheap, and we optimized for conditional checks, today you have to optimize for memory refrences, conditional checks are basically free.
Your model of how garbage collectors work is completely wrong. High performance garbage collectors aren't a layer on top of a C/C++-like heap allocator--that would be horribly inefficient--they use completely different allocation strategies
.net components are one of the only cases where its truly proven to be helpful, and all those technologies had multiple language bindings including C++. Its the same with a lot of operating system features, mainframes from the 70's pioneered many technologies claimed by Linux/Windows/Mac crowds.
Like what? There are dozens of heap allocation algorithms, whether or not the heap allocator is integrated into the garbage collector, or a call out to some routine is sort of irrelevant. The fact is that somewhere in the garbage collector there is some form of heap allocation/deallocation. Whether you choose to call it that or not will probably affect the maintainability of your code, more than the performance characteristics of the GC. At some point characteristics like how you select a region to be broken up, how you reuse allocation, or how you merge adjacent regions back in is a heap management problem not a GC problem.
Your right of course that a lot of language features that java and C# claim to be new are decades old, most BASIC's did GC, a number of OO languages, had dynamic binding. C++ became popular despite the lack of these features, which indicate that maybe they aren't as important as everyone would like to think. Things like true dynamic OO as represented by old school activex,COM,DCOM,OLE and now the
I used to think so myself, but after using C++ professionally for 20 years, I can say without a doubt that C++'s flexibility is its weak point: it has enormous project management costs and no significant benefits.
This is almost entirely dependent on your development organization in my book. The project I worked on before my current one, was lead by a C++ weenee that tried to use every feature in the book because he could. It was a mess, and impossible to work on. The current one I lead, uses a number of "advanced" C++ features, but they are used to aid maintainability. Overriding the array index operator, on a couple of utility classes used everywhere in the code so that we could use strings as array indexes, cut literally thousands of lines of BS code. Changing the locking model from a pthreads style lock to a declare the lock and then declare a class to lock it model, saved thousands of lines of exception handling code that had to be wrapped around lock/unlock pairs. Using exceptions from the bottom up, saved thousands of lines of `if (errorcondition)` code, now the exception propagates to the top level and the transaction is canceled with the possibly to retry or simply return an error. Our application has yet to be shown to leak any memory, the few that were there didn't make it out of development due to automatic memory leak detection tools, and use of automatically constrained memory buffers avoid buffer overflow problems. The flexibility allows a very small team to achieve similar results as our competitors do with 10x-25x the manpower. We have a couple of UI's one is written in java and the backlog of features in the C++ portion of the code that are not supported into the java code is enormous. Well maintainable code is more a function of the software engineering practices enforced than the language chosen. The java part of our product has actually had more memory leaks than the C++ portion, proving again that GC can fail. Heck even java now has classes which can be used to control explicit allocation/deallocation.
You're incorrectly assuming that other languages can't use stack allocation (they can, and do, and do so more than C++), and that the C/C++ memory allocator is "fast" (it isn't, relative to a good garbage collector).
I never said that, I thought we were discussing C++ vs's newer languages like java and C# as they relate to having runtime features C++ doesn't have. My original assertion was that C++'s lack of many of these features 25 years ago wasn't a mistake due to constraints of the time.
but C++ almost always loses in terms of programmer productivity and software quality.
I find this to be overgeneralization, I've been involved in a large range of projects over the years using just about every major language, in nearly all the cases C++ found, or could have found a section of the project where it was the best choice for the problem. Of course I tend to use C++ as a better C, which means that just about anywhere I see C code I prefer to use C++ even if 99% of the resulting code could have compiled with a C compiler. When matched with languages like PHP for web development, RAD GUI builders (VB,Delphi,C# etc) for GUI development, database and assorted other tools, the result is impossible to beat with any single language and hard to beat with other combinations. C++ is an incredibly flexable language, that is its strong point. There are C++ libraries that put in on par with the best languages designed for specific purposes. For example, Borland C++ builder, is a far more productive enviroment for GUI development than _ANY_ java enviroment i have ever used, the diffrences are stunning. The resulting code is often of amazing high quality (as measured in customer defects per LOC).
Oh, and BTW, what general purpose garbage collection algorithm which doesn't require a heap allocator, is faster than just using a general purpose heap allocator? I'm afraid you don't understand that most garbage collectors also have heap allocators, and that C/C++ and many other languages skip the middle man and simply use the heap allocator. GC's are added for programmer safety not performace. A particular C++ implementation may have a slow allocator relative to your problem set, that is why there are other specific purpose allocators and other compiler/library/OS vendors. The C++ language standard doesn't describe how the allocator is to work. My opinion of the java GC isn't all that high either, but I know that getting a GC correct in 100% of cases is _REALLY__REALLY_ hard unless you constrain your language so much that its unusable. The fact that it works as well as it does, says a lot of positive things about the tradeoffs being made.
Name mangling doesn't slow the code down, thats a linker problem... Vtable lookups arn't there unless you use virtual methods, C code calling through function pointers is just as slow. Its not an apples to apples comparison. The point is that you _CAN_ compile C code with the C++ compiler, and then sprinkle C++ where it helps. That is why C++ is not slower than C, sure you can write C++ code that is slower than C if you choose to, I can do exactly the same in the converse with proper use of C++, of corse the slower code will probably compile in the C++ compiler as well so the whole argument is bogus. That is why its just plain stupid to say that C++ is slower than C, because C is a subset of C++.
That's not how GC costs work; GC isn't some big, fixed overhead that you can only afford once you have a fast machine. Rather, GC costs a certain number of cycles per byte allocated. That means that the impact on a normal program running 10 sec on an 8 MHz machine is the same as on a normal program running 10 sec on an 8 GHz machine.
Furthermore, then, as now, a good garbage collector reduces the total amount of CPU spend on memory management compared to C++'s manual storage management scheme; C++ memory management is highly inefficient.
Ok, so I exadurated a little about the 100% CPU, but the point remains. I suspect you don't really know how java does its garbage collection. Here is a nice starting point http://www.javaworld.com/javaworld/jw-03-2003/jw-0 307-j2segc.html?page=1. When your done please explain to me how that can be faster than a simple stack allocation (usually precomputed by the compiler and done when the initial stack is setup on procedure entry) done in C/C++ or a fast O(1) heap based allocator. After all the BS about garbage collection, there is still a heap sitting under it all, and the same heap algorithms are used in C/C++ as java. In fact you can change the heap allocator in C++ if it doesn't match the performace characteristics of your application.
Now, i've seen dozens of programs written in both C++ and java which are written to prove that java has faster memory allocation because of the garbage collector. In ever single case, the C++ example makes some major mistake which would not be made by an experienced C/C++ programmer. Once that mistake is fixed, the C++ version runs anywhere from as fast to significantly faster than the java version, as measured by total wall time. Usually the C++ mistake is there to give the implicit object reuse the JIT did a big boost. The point here is that while you may be able to make C++ programs slower than java, there is usually some way to tweak the C++ program to reverse the situation.
Oh, and while C++ may not have been designed for 64k machines, I ran C++ compilers in DOS and on the early mac's neither of my target machines had 2M of ram.
I don't know about your CS, but I've never heard a pointer to a pointer called a vector. I've always used vector in the same sense as math class. Which BTW, the STL vector conforms to, because it is an n dimensional vector AKA an array. A quick google search on vector didn't yield any results, got any references? I'm just curious, terminology is definitely not always standardized.
Secondly, a HWND is a pointer to the WND structure which is a reference to the window. Just because you can't easily dereference it with your debugger doesn't make it so. On 16-bit windows the HWND was a pointer to a localalloc heap owned by USER and GDI (all you have to do is find the right heap). On 9x systems this was modified slightly and some games were played at the last minute before release to extend the GDI heap past 64k. But its still the same basic game, look at windows 95 system programming secrets for some info. You again need to find the base of the GDI DGROUP to dereference it. With NT its still there, only its read-only (since you could dork with other processes windows if it wasn't), again the game is to find it. Here is a good start http://www.winterdom.com/dev/ui/wnd.html
Now maybe we are discussing semantics, I guess you might define anything that isn't directly dereferencable as a token. I'm calling it a pointer because in the right context it is. I do system programming for a living and I'm used to something only being a "pointer" in the correct context. By this maybe we would like to call the "token" an index or the converse. Whatever...
25 years ago Stroustrup wasn't wrong, I would like to see you run a modern java enviroment on a 64k machine (no, the embedded java systems that remove most of the language don't count). Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.
Bullshit, C is.
Not to get into a holy war here, but please show me a program for which your C compiler generates better code than the equivalent C++ compiler does on the same code. For the same code its generally the same damn thing, C++ is just more tools in your toolbox. You don't have to use the extra crap in C++ unless you have a reason. I use C++ exclusively (vs C, I use lots of other languages too, just not C) because it reduces problems with C when used properly, and it provides some powerful constructs that are hard to simulate without a lot of extra overhead in C. There are dozens of cases that short of writing 100x as much code in C, simply cannot be matched for performance. I would like to see your implementation in C of a matrix library that supports a dozen element types ranging from simple ints, floats, vector types to arbitrary precision math that matches what can be done with a template class.
There are gains in everyday tasks as well, C++ exceptions can significantly speed up business logic type code by removing thousands of "if (error)" checks, on some architectures virtual methods are faster than C function pointers in structures, the list goes on. Of course i'm not a purist, I use lots of calls to sprintf, some things are better in C++ syntax some are better in C, I like to have the choice.
I'll buy part of that for $1. Pascal is probably the cleanest language I have ever used, Object Pascal is probably the cleanest OO language I have ever used (part of that may be my bias towards borlands VCL, stuff just worked the way it should). I would say that Object Pascal is more powerful than C (C's strengths in low level stuff _can_ be achieved in pascal with a tiny bit more work, and the OO in OP is way more powerful than anything in C). OP is less powerful than C++ (due to generics and some other stuff), and more powerful than Java although its close.
In the case of java the recent addition of lightweight generics give it a plus there, but its lowlevel support is for shit (aka DNE), and I've found the dynamic nature of java to be misused the way weak typechecking and multiple inheritance in other languages is misused. By this I mean that if you find yourself needing weak typchecking, or multiple inheritance you had better start wondering about the structure of your algorithm/program. Then there is the java one true way which makes everything a nail to be attached with your nailgun. So OP wins in my book.
I can understand the switch from pascal to C++, that was due to industry pressure, why teach a language no one uses, just teach people C++ and hopefully they will get around the gotcha's. But java? Jeeze java had a big bandwagon, but I have never really seen the advantages, a reasonable look at the language soon determines that all of its strong points are either stronger somewhere else or are masked by some other critical issue in the language. Seems to me the people calling themselves "software engineers" are still using C/C++, the people calling themselves "programmers" can't quite settle on a language and at the moment C# seems to be winning (a language that has more credibility than java in my book, it has some serious strong points).
the first parameter isn't a pointer, but a window handle (hwnd).
Just a minor pick, but a HWND is a "pointer" in this case to a pointer. Where I come from a handle is defined as a pointer to a pointer. This is due to proper heap managment. Today most people just assume that the virtual address space is unlimited and they don't worry about heap managment. Heap compression is a a very valuable idea, if a little lost in the modern world of 64-bit virtual address spaces and fixed size pages. Windows is old enought to know what a handle is if you read the goobly goop in the header file you find that it is a pointer to the declared type. Wikipedia defines a handle as a smart pointer http://en.wikipedia.org/wiki/Smart_pointer and points out that the values acting as pointers can be array indexes or something similar (in the case of unix file handles) but the concept is the same.
BTW: I'm of the school that C programmers are C++ programmers with less education.
It wasn't a dither, thats not transparency. It was a full blown partial transparency algorithm.
This guy is smoking some serious crack in a couple of places, he talks about how difficult it is to do transparency? Hello I wrote a little piece of code to make transparent windows back with turbo pascal on a 386.. If my 386 could do it i'm sure you don't need a GPU... Just because transparency wasn't in the basic GDI (which is even older) doesn't mean it was hard or even that slow.
Ah hello, can I have the $5 mill? I think sharepoint does exactly what she wants... Geeze some of these are just as silly.
That isn't the point, the cells can only get so small (until you basically have a wire) and consume so much bandwith without interference. Where is compared to a fiber bundle you simply add another bundle to the existing one. The capacity of few strands of fiber is a lot larger than the capacity of any modern over the air transmitter. If this wern't so, the internet would be running on cells of microwave transmitters instead of fiber bundles (or for that matter cell towers would be connected over the air instead of by cable). Create a network where hundreds of strands run to everyone's houses and you will be set for the next few hundred years, just upgrade the head units and the in home boxes.
They are suceptable to even greater loss in the atmosphere than over fiber... Plus the beam does spread out over distance.
This simply fails to understand that fiber is shielded and doesn't experience cross talk. With fiber, if you need more bandwith you simply lay more fiber. With wireless you are bound by weather conditions, atmospheric conditions, solar flares etc, and other people using harmonic frequencies of your own. There is a limit to the amount of bandwith that can be sent wirelessly even using directional antenna's and point to point microwave links (because there really isn't a such thing as tight beam). Eventually its simply not possible to add more bandwith without eating larger and larger parts of the spectrum. That even has a limit, depending on where the maximum freqency we can build transmitters and recievers. This is why we have goverment bodies like the FCC, and a large part of the usable spectrum (given todays tech) is already consumed.
The real problem is that the telco's are unwilling to take a temporary loss of profits to reap long term benifits. Eventually some upstart is going to run a bunch of fiber and sell the bandwith cheaply the the existing telco's will be in the same boat as the big airlines. Basically screwed until they go out of business leaving the field for stronger competitors. It will probably take another 30 years, but it will happen. For example look at Cogent Communications...
Everyone seems to think the PS3 is going to be so much better than the Xbox3. It seems to me to be a repeat of the xbox vs ps2. Originally everyone said the Ps2 was going to blow the doors off of the xbox, but then it turned out all that wierd hardware didn't really perform as well as everyone expected. There is a distinct posibilty the same thing will happen this time around. In a couple years we can decide which was better, right now i'm leaving my opinion up in the air, and I wish everyone else would too.
Basically true, except M$ thinks they see the writing on the wall for standalone PCs. In 10 years they are thinking the media center box will be all people buy at home (because it will be able to surf the web, send email, play games, and even maybe run a word processor and financial software). Without the blessings of the entertainment industry a M$ media center box won't sell a single machine. If the entertainment industry says they won't sell summer blockbusters without DRM M$ pretty much has to get onboard. They figure its better to lead the pack than play catchup. M$ needs to evolve and leverage its desktop OS+Xbox+mobile devices into the media center space rather than try to release yet another product ahead of its time. Without the DRM they can't leverage windows if it won't play any summer blockbusters. So its not true that M$ doesn't have a financial intrest in DRM, they _HAVE_ to have it there as long as the entertainment industry wants it. The second the entertainment industry (or more likely goverment) says DRM is bad then M$ will pull it, not one second sooner. Frankly I suspect that in 10 years i'm going to have to be buying PC's that cost 100x as much as they do today because the mass market will be gone and instead everyone has playstation 5's, playstation laptops or something similar that do 90% of what a PC does today. With high def screens there is one less reason to have a PC.
This is the same argument made 7 years ago for media center PC's. Everyone declared them dead back then because the few that were released flopped. I suspect that its just a case of an idea being to early for its own good, those machines had crappy displays, didn't play games, USB wasn't common enough for everyone to have USB printers, camera's, etc. PC's were not common in the living room, today they are as video scalers, dvd players, mp3 colletion points etc. All that in 5 years, in another 5 years we can have this discussion again. They won't kill the PC, but they sure will make buying a PC with a lot of slots and the like harder.
The "web" edition of Windows is locked down and you are not permitted to run (server?) software on it beyond a web server.
M$ 'server' software you mean. I can install other 'server' packages just fine.
Try actually reading the Mysql license, its really restrictive, and we _DO_ distribute our software which means we don't really fit into any possible loopholes, seeing as we sell it.... The 30 second version is that mysql considers any connections to their database to be a link, (partly because of the libraries) and therefore its technically violates the GPL if you connect to it with non GPL code. So yes even if it were for internal use we would have to comply with the GPL.
On top of that, nobody is forcing you to use an RHEL kernel; you can use any kernel you want. The only limitation is that you couldn't install a POWER kernel on ES, since it doesn't have the packages for the POWER processor. Essentially the only real difference between ES and AS other than the lack of support for the IBM POWER arch in ES is the support option differences between the basic and standard packages.
That is crap too, we have a particular software package that ships binary drivers that only load on two or three different RHEL patch levels of kernels. That effectively ties us to the RHEL version the vendor specifies. I have done extensive OS kernel development, and there are patches in the mainstream linux kernels with my name on them, it still took me nearly a week with a debugger, hex editor and some other tools to get the proprietary driver loaded in a different kernel version. At which point our support agreement would have been voided with the software vendor providing the binary driver. So, it was pretty much just an exercise in seeing if I could do it. I seriously doubt 99.9% of the "competant linux admins" out there would even know where to start doing something like that.
I understand that SQLite (which is ideal for embedded situations as you describe, and is faster than MySQL for most tasks)
Just because its embedded doesn't mean "light weight". Mysql strains under the load and we use its "advanced" features extensivly, which will probably force us to choose another database in the near future, but it sure won't be some kid's version of a sql parser, our stuff is very critical and the mysql transaction support isn't really sufficient for our application anyway...
Nice load of crap, until recently the only choice for commercial use of mysql was the $1499 enterprise license, which wasn't year limited. Now the choices all seem to be per year.. M$ starts at free for the express edition (which is freely redistributable even for commercial use, but has limits on the number of CPU's and RAM it can use, and goes to about $4k, which you don't have to keep paying for. The base standard edition of sql server is $900 which is two years of basic mysql. Mysql is free for opensource use, but commercial use of it doesn't count as opensource if anything connecting to the box isn't opensource.
h p?catID=57
v er/
http://www.edirectsoftware.com/product_category.p
https://shop.mysql.com/network.html?rz=s2
Red hat enterprise edition used to be ~1.5k per license and was node locked, while the base windows server licenses were 1k. That has changed so the basic windows license is now ~370 (ive seen them as low as $150) bucks for web edition (unlimited cal) ~550 for the standard edition (5 CAL) and $800 for the small business version which has sql server, sharepoint outlook etc already included.
https://www.redhat.com/en_us/USA/rhel/compare/ser
says the RHE ES is ~349 bucks, basic edition and goes to $800, AS is ~1500 to ~2500. ES and AS have been in the past diffrent kernel versions and such, We have software where I work that _ONLY_ runs on AS forcing us to buy the $1500 versions to get the updates. This ends up costing us more per machine than the extra CALS for the windows box. In fact last year we spend nearly twice as much on the linux machines as the windows ones. We also ship a product that uses mysql as an internal database. The per year licencing costs are a very significant portion of the sale price of the machine over the expected 10 year lifetime of the products in customers locations.
This is the same kind of FUD that the linux people accuse the windows people of throwing. There is _absolutly_ nothing in linux that is inherintly more secure than windows. Linux has bug after security bug just like windows and its less than a few percent of the total market which makes me think windows is probably more secure. I've been using windows for a long time (linux too for that matter, I have CD's with .9x series linux kernels). In all that time i've never gotten a virus and companies I work for have had little in the way of virus problems. I've seen them but they are in no way as big of a deal as people make them out to be, its like the war on terra... 2 thousand people die and its all the US talks about for years, and spends billions of dollars fghting. Its the same with windows, there is a CNN windows security article about a bunch of people getting infected because they are running insecure machines, or they didn't keep there machine patched and the /. crowd thinks "windows is broken". Bah...
Well this hits on the core argument... Why switch at all? The only reason most opensource projects have for switching is a higher ideal about whether or not source code should be avialable for a program. While I would love to have source code for every application I use, only programmer types really feel that way. The majority of computer users today just want an application that does what they want without getting in the way. Even if gimp does 100% of what photoshop does there are still going to be a number of people buying photoshop and using it simply because that is what they are comfortable with, the few hundred dollar price tag is insignificant compared to the hours it would take to become profficient in a new enviroment. Learning all the shortcut keys, and where items are in the menu takes more than a few hours. Its like linux, sure you can show someone how to start start star office and spell check their document in a few minuites but the user isn't going to know nearly as much about the enviroment after a few hours as they know about windows/word after having used them for years. Its the old don't fix it if it isn't broken syndrome. Combine this with the fact that many opensource projects cost just as much as their commerical counterparts just makes me wonder.. Why for example does it cost more to get a basic MySQL license than a SQL Server license? Why does Red Hat Enterprise Server cost more than Windows 2003 Server? Sure there are CAL licenses issues for some of the windows services, but a lot of the opensource projects run on windows too. I can run bind/apache/etc on windows as easily as linux.....