Moore's Law
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
>Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, >just CPU speed and performance. Actually Moore's law applies to amount of circuit elements on a single IC chip. Increases in CPU performance and memory capacity are consequences of Moore's law, not the law itself. Anyway, the easy availability of a resource such as CPU performance is no excuse to waste it!
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
>>>What do you think? Very little normally but I'll state my thoughts on Moore's Law Moores law has been correct for 36 years ! Moores Law relates purely to the quantity of proccesors per card / IC / Chip It's use doesn't cover how well they are used ! Possibly Bandwidth = .182 x 1 Moore ( Moore being a factor of (1.5 to 2) yrs ) Moore's Law has never been tested by Global depression or war. C++ almost has the power of Hand assembled code, VB etc, Is way of the pace and needs the hardware. VBers are doing today what us C++ heads did 5 or 6 yrs ago. If cutting edge 3rd party apps are to be on the shelf in the next few years, it depends on how you folk focus on performance for us ! Relying on Moores law to solve bottleneck problems etc, will never create a Software HardWare Synergy that leads to Cutting edge development. Regardz Colin Davies Y.G. renewals e-Rooms as moores law energy
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
The thing that I find slows down apps nowadays is not CPU speed (or lack thereof), but rather lack of memory. My little 450MHz runs quite nicely - be it a VB program or a hand crafted C++ app. But once W2K, SQLServer and VS.NET start fighting over my 128Mb then things bog down fairly quickly. Maybe the emphasis should be on memory and resource efficiency rather than the number of cycles taken by a routine. CPU speeds have certainly followed Moore's law, but the standard amount of memory a typical (household) PC has is still only 64-128Mb. Just a thought. cheers, Chris Maunder
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
This is one of my main beefs against Microsoft products. As a company, Microsoft seems concentrate on adding features of dubious merit, instead of cleaning up and tuning the existing code base. A prime example of this is that nasty dancing paperclip "assistant" in office applications, which gobbles screen real estate without providing any functionality. I think Microsoft's propensity to write piggish code is one of the driving forces behind the growth of Linux and Free BSD. After all, why spend money for a bloated OS that may not run on older hardware when one can have a real rocket of an OS for free? This same reasoning keeps people from upgrading the OS. Why should I move from Windows 98 to Windows Me, when the upgrade gives me nothing I care about and may not run as well to boot? While you've got me in a griping mood, what I've heard about the .NET OS and C# has me worried about my future as an MFC/ATL programmer. Microsoft has just finished selling COM as the best thing since sliced bread, and now they are charging off in a different direction. It seems that instead of really focusing and making the effort to get things right, Microsoft is thrashing - jumping from one technology to the next without any clear plan of how it wants to steer it's product line. P.S. - One thing I really miss from UNIX and DOS is a good set of command line utilities. I know the OS is called Windows, however there are times when working from a command line makes the task much easier. It also seems that the command line utilities are getting worse, not better as we go along.
-
This is one of my main beefs against Microsoft products. As a company, Microsoft seems concentrate on adding features of dubious merit, instead of cleaning up and tuning the existing code base. A prime example of this is that nasty dancing paperclip "assistant" in office applications, which gobbles screen real estate without providing any functionality. I think Microsoft's propensity to write piggish code is one of the driving forces behind the growth of Linux and Free BSD. After all, why spend money for a bloated OS that may not run on older hardware when one can have a real rocket of an OS for free? This same reasoning keeps people from upgrading the OS. Why should I move from Windows 98 to Windows Me, when the upgrade gives me nothing I care about and may not run as well to boot? While you've got me in a griping mood, what I've heard about the .NET OS and C# has me worried about my future as an MFC/ATL programmer. Microsoft has just finished selling COM as the best thing since sliced bread, and now they are charging off in a different direction. It seems that instead of really focusing and making the effort to get things right, Microsoft is thrashing - jumping from one technology to the next without any clear plan of how it wants to steer it's product line. P.S. - One thing I really miss from UNIX and DOS is a good set of command line utilities. I know the OS is called Windows, however there are times when working from a command line makes the task much easier. It also seems that the command line utilities are getting worse, not better as we go along.
This is exactly why i have a Linux box. It's just an old worn out P180, but it runs all of those wonderful *nix tools. I often find myself copying files over to my Linux box to do sorting, regex stuff, etc.. There are a few good unix-like shells for DOS/Windows. MKS was good the last time i used it. There are some free ones, too. About MS's tech-of-the-day thing: I don't think MFC is going away. There are close to ten years worth of MFC apps out there. At the very worst, all of us MFC people can do maintenance forever. :( At best, and more likely, project managers will realize that C#/VB isn't the solution to every problem. -c
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
(What I say now hurts, each time I say it, it hurts a little less, but it still hurts. I have always liked pushing machines to their max (at what cost? I only had my account at uni suspended a few times...), and writting code that is tight and great performance. I also take great pride in my work [My code is running some of the Police and Fire systems in New Zealand, Fire system in Melbourne Australia as well as a BP call centre]. Anyway, this is just a preluded to what is to follow...) I used to agree with your team, because I didn't understand the implications of Moore's law. But now when I can buy 256Mb for about US$90, 40Gb drive for around US$150, 700Mhz processors for around $100... So where does this leave us? Well it leaves us in the position where we should make the programmers life as easy as possible. If the alternatives were many orders of magnitude slower, then sure we should ignore them, but for the most part they are not. And a lot of the time you see c++ code which is faster is because it is ignoring to do many of the error checks that other languages are doing. (I have fallen into writing full precondtions and postcondtions for functions and it is a pain in the arse, but can I fully trust callers? should I not point out an error as soon as it is found? Should this only exist in a debug build???) There is still a place for ATL I believe, but MFC? Hmmm... What are you really gaining? A lot of windowing helper functions and a few other classes to help you along the way (which are useful, but at what price?). The windowing stuff? Well either make the jump to somewhere such as VB or tighten your belt and jump to WTL. It had a place, but I think that place is basically gone?? Anyway, I think it is more pigged headed pride that keeps programmers programming c++ (stab at my own heart!), as there is a general unwillingness to let go of the machine and t-r-u-s-t a more abstract language ("oh, but I can't do such-and-such in that language" often turns out to be that they are trying to program that language as if it was c++) Have fun, Paul Westcott.
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
Walter, Yes, please concentrate on performace! Every once of performance you get out of MFC can result in improvements in performance of those who USE the code. It is frustrating when I see code like the implementation of CString::TrimRight() in MFC. It is not a great implementation of a "TrimRight" function. (CopyBeforeWrite being called even if it isn't needed, scanning the ENTIRE string looking for the trailing spaces, etc.) PLEASE fix these sort of things in the next MFC!
-
This is one of my main beefs against Microsoft products. As a company, Microsoft seems concentrate on adding features of dubious merit, instead of cleaning up and tuning the existing code base. A prime example of this is that nasty dancing paperclip "assistant" in office applications, which gobbles screen real estate without providing any functionality. I think Microsoft's propensity to write piggish code is one of the driving forces behind the growth of Linux and Free BSD. After all, why spend money for a bloated OS that may not run on older hardware when one can have a real rocket of an OS for free? This same reasoning keeps people from upgrading the OS. Why should I move from Windows 98 to Windows Me, when the upgrade gives me nothing I care about and may not run as well to boot? While you've got me in a griping mood, what I've heard about the .NET OS and C# has me worried about my future as an MFC/ATL programmer. Microsoft has just finished selling COM as the best thing since sliced bread, and now they are charging off in a different direction. It seems that instead of really focusing and making the effort to get things right, Microsoft is thrashing - jumping from one technology to the next without any clear plan of how it wants to steer it's product line. P.S. - One thing I really miss from UNIX and DOS is a good set of command line utilities. I know the OS is called Windows, however there are times when working from a command line makes the task much easier. It also seems that the command line utilities are getting worse, not better as we go along.
Whatever *YOU* seem to think about such features, there are always people that like them. It really pisses me off when I see comments like this, since your comment bitches only about the negative. MS Office's memory footprint has been greatly reduced in Office 2000 over Office 97. It loads faster, it uses less memory, it offers more flexibility (and you can completely disable the office assistant)... yet these things slip right past you, and you only take the opportunity to bash the paperclip without recognizing that MS has been doing EXACTLY what you criticize them for not doing. A product like Office must appeal to the greatest possible audience, and sometimes that means including features that power users won't find very useful and features which novices will find confusing. That's the nature of general purpose computing. Software design is about making choices. Consider what YOU consider to be good software today, then compare it to systems of 20 years ago. Do you think we'd be anywhere if we always limited ourselves from using new technology and resources in order to keep the people that haven't upgraded happy? Ok.. sorry for the serious flame, but geez.. come into the 2000's and not the 1980's.
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
C/C++ are intended to be low-level and highly optimized. The next fastest step would be assembly itself. In my opinion, yeah, it's fine for things like VB or Java to be bloated hogs, since you still have the option of writing code in C or C++ to gain efficiency if you absolutely need it. If you make C++ a bloated hog, then we only have assembly to turn to.. and that's just not practical these days anymore. You're right, software developers don't have any problems expanding to consume all available resources. But the programmer should have the choice.
-
The thing that I find slows down apps nowadays is not CPU speed (or lack thereof), but rather lack of memory. My little 450MHz runs quite nicely - be it a VB program or a hand crafted C++ app. But once W2K, SQLServer and VS.NET start fighting over my 128Mb then things bog down fairly quickly. Maybe the emphasis should be on memory and resource efficiency rather than the number of cycles taken by a routine. CPU speeds have certainly followed Moore's law, but the standard amount of memory a typical (household) PC has is still only 64-128Mb. Just a thought. cheers, Chris Maunder
Unnecessary working-set bloat is certainly the biggest problem with most applications these days. I can barely get my machines to 80% processor usage, even during compiles etc., but find that I have to shut down the development environment every couple of days, because it is now mysteriously hogging 300Mb of RAM. In our own applications, the effective use of minimal resources is essential. Particularly in the UK, healthcare purchasers are extremely cost-concious, and getting the best use out of the cheapest hardware is an essential part of our design process. For myself, I would want to see equal emphasis on Productivity, Reliability and Efficiency from our tool vendors, and sensible choice of implementation technology and process from developers to balance these in their own work. As an aside, the .NET programme seems to be getting this balance almost perfectly, but I would love to see a slim, efficient next generation native C++ library from Walter Sullivan's group to complement it. Matthew Adams Development Manager Digital Healthcare Ltd
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
Even if you limit Moore's Law to CPU performance, as indicated by specific CPU tests, there are at least two strong reasons for worrying about the performance of an underlying library (or, worse, OS) code: First, Moore's Law tends to not apply to code that isn't going to be strongly cacheable. This covers code, and especially data, that is used in a relatively random manner, such as a library of functions or operations on disparate structures. Furthermore, hardware exception processing or level change only make matters worse. I'd think that MFC/ATL on down fall under such conditions. (There's a ten year old ACM ASPLOS paper titled something like "Why aren't operating systems getting faster as fast as CPUs?" that discusses this at length. Sorry, it's in my library somewhere, but I've not had a chance to look it up...) Second, the effect of Moore's Law has been to enable applications that couldn't be either built, or at least built econonmically. And the performance of these applications is a selling point. If the underlying system provides relatively poor performance, then those applications will avoid them -- either by building their own, or by moving to a platform that provides the performance advantage they commercially need. I'd have thought Microsoft's goals would have included ensuring that such applications stayed on their platforms. By implication, MFC/ATL, and below, should be worried about absolute performance. How much is a business decision that is internal to Microsoft, of course. Jim Johnson These opinions are my own.
-
This is one of my main beefs against Microsoft products. As a company, Microsoft seems concentrate on adding features of dubious merit, instead of cleaning up and tuning the existing code base. A prime example of this is that nasty dancing paperclip "assistant" in office applications, which gobbles screen real estate without providing any functionality. I think Microsoft's propensity to write piggish code is one of the driving forces behind the growth of Linux and Free BSD. After all, why spend money for a bloated OS that may not run on older hardware when one can have a real rocket of an OS for free? This same reasoning keeps people from upgrading the OS. Why should I move from Windows 98 to Windows Me, when the upgrade gives me nothing I care about and may not run as well to boot? While you've got me in a griping mood, what I've heard about the .NET OS and C# has me worried about my future as an MFC/ATL programmer. Microsoft has just finished selling COM as the best thing since sliced bread, and now they are charging off in a different direction. It seems that instead of really focusing and making the effort to get things right, Microsoft is thrashing - jumping from one technology to the next without any clear plan of how it wants to steer it's product line. P.S. - One thing I really miss from UNIX and DOS is a good set of command line utilities. I know the OS is called Windows, however there are times when working from a command line makes the task much easier. It also seems that the command line utilities are getting worse, not better as we go along.
Whilst 'features for features sake' is a big problem with the SW industry at large, and perhaps MS in particular, I would disagree with you about MS 'charging off in a different direction' with COM/.NET. COM interoperability is a key feature of .NET - without it, we would not be basing _our_ future development on the platform. .NET then builds on the philosophy and infrastructure that COM provided, fixing most of its (many!) deficiencies, and then - as a huge, huge bonus - providing a rich set of component libraries that act as enabling technologies for the kind of applications companies are developing today. Previously, I have not been enamoured of the 'web development' model, as espoused by Microsoft, Sun etc. in various forms. It has not offered the flexibility, user experience, or indeed sound technology basis that more 'traditional' programming models have evolved over the years. .NET marries most of the advantages of 'traditional', platform dependent technologies, whilst extending them to embrace the more-or-less heterogenous network environment into which most applications are now deployed. I still think that the focus on broadband, WAN/Internet connectivity is at the 'hype' level, but all of these technologies are applicable in the genuinely high-bandwidth intranet environment we see in most offices, and many homes today. .NET is making my life easier, and yet there is still a critical place for the ATL programmer in our organization, because sometimes hand-tuned code is still essential. Admittedly, the assembler programmer is somewhat out in the cold (we tend to use Intel's C++ performance libraries for processor-intensive coding, and they do much better than my rusty, out-of-date assembler skills), but picking the right technology for the right job is a vital part of software archticture and the development process. Matthew Adams Development Manager Digital Healthcare Ltd
-
This is one of my main beefs against Microsoft products. As a company, Microsoft seems concentrate on adding features of dubious merit, instead of cleaning up and tuning the existing code base. A prime example of this is that nasty dancing paperclip "assistant" in office applications, which gobbles screen real estate without providing any functionality. I think Microsoft's propensity to write piggish code is one of the driving forces behind the growth of Linux and Free BSD. After all, why spend money for a bloated OS that may not run on older hardware when one can have a real rocket of an OS for free? This same reasoning keeps people from upgrading the OS. Why should I move from Windows 98 to Windows Me, when the upgrade gives me nothing I care about and may not run as well to boot? While you've got me in a griping mood, what I've heard about the .NET OS and C# has me worried about my future as an MFC/ATL programmer. Microsoft has just finished selling COM as the best thing since sliced bread, and now they are charging off in a different direction. It seems that instead of really focusing and making the effort to get things right, Microsoft is thrashing - jumping from one technology to the next without any clear plan of how it wants to steer it's product line. P.S. - One thing I really miss from UNIX and DOS is a good set of command line utilities. I know the OS is called Windows, however there are times when working from a command line makes the task much easier. It also seems that the command line utilities are getting worse, not better as we go along.
a) I like the assistant - esp. the cat. And the feedback when working is simply amazing (which is something I can't say about searching the help) b) COM simply didn't work out the way it was planned. Design too academic, to complicated to use, no *real* tools. .NET looks much better for productivity. c) CL - yep, I'd sometime favour some good CL utils, too
-
I wanted to get your take on something, just for kicks. In performance discussions, at Microsoft and with external customers, I often get Moore's Law thrown in my face when I talk about our focus no performance. My team (the MFC/ATL Development team) strongly believes that we need to continue to focus on performance. It seems this is one big reason people use C++, and in my experience, software developers don't have any problems consuming system resources as fast as the hardware developers can create them. Also, Moore's Law doesn't seem to apply as directly to dial-up bandwidth or other factros, just CPU speed and performance. What do you think? Walter Sullivan Lead Program Manager, ATL/MFC
I'd like to see and end of the C/C++ fascination with efficiency - make it one aspect of the language (and libraries), rather than the overwhelming dominant feature. These languages are a product of their time (of course) and that was a time of extremely rare system resources. They had to favour performance over all else in order to succeed. Times have changed. Languages need to change too. It seems a rather shallow argument that if I want a little protection from my programming environment (say, to help prevent memory overlow) I have to give up on C++ and move to VB, Java, or some other 'inefficient' language !! And I'd like to see the same philosophy flow into libraris like MFC - offer a balance. Give programmers a choice - efficiency versus safety. And (just my personal preference) I'd like to see languages/libraries that offer 'safety' as the default, and leave 'efficiency' to the advanced user who knows what they need and why. Maybe then some of these 'highly efficient' C++ programs will run reliably (and take less that a decade to write and debug)! And just to try and avoid too many criticisms - I choose to use C++, I'm just tired of constantly having to remember which library functions (MFC/STL/standard lib/whatever) will crash if I pass in a NULL pointer, and which ones will simply fail - there is no consistency! Ian Kilmister "Without something, there is no nothing.."
-
I'd like to see and end of the C/C++ fascination with efficiency - make it one aspect of the language (and libraries), rather than the overwhelming dominant feature. These languages are a product of their time (of course) and that was a time of extremely rare system resources. They had to favour performance over all else in order to succeed. Times have changed. Languages need to change too. It seems a rather shallow argument that if I want a little protection from my programming environment (say, to help prevent memory overlow) I have to give up on C++ and move to VB, Java, or some other 'inefficient' language !! And I'd like to see the same philosophy flow into libraris like MFC - offer a balance. Give programmers a choice - efficiency versus safety. And (just my personal preference) I'd like to see languages/libraries that offer 'safety' as the default, and leave 'efficiency' to the advanced user who knows what they need and why. Maybe then some of these 'highly efficient' C++ programs will run reliably (and take less that a decade to write and debug)! And just to try and avoid too many criticisms - I choose to use C++, I'm just tired of constantly having to remember which library functions (MFC/STL/standard lib/whatever) will crash if I pass in a NULL pointer, and which ones will simply fail - there is no consistency! Ian Kilmister "Without something, there is no nothing.."
You're never going to achieve consistency i'm afraid. Language choice is about what's important to you. If you like C++, but want more safety, perhaps you'd be better off with Java or C#. These are very similar to C++, but provide much more hand holding and error checking, at the cost of efficiency of course. C/C++ is the basis of which almost all languages are written. Do you think they write VB in assembly or VB itself? No, they use C/C++. Do you think they wrote Java in assembly? Probably some, but most of it is C/C++. It has to be efficient, because if it's inefficient, everything that's based on it will be as well. Now, what you base on it might be inefficient based on your design, but that's your choice.
-
You're never going to achieve consistency i'm afraid. Language choice is about what's important to you. If you like C++, but want more safety, perhaps you'd be better off with Java or C#. These are very similar to C++, but provide much more hand holding and error checking, at the cost of efficiency of course. C/C++ is the basis of which almost all languages are written. Do you think they write VB in assembly or VB itself? No, they use C/C++. Do you think they wrote Java in assembly? Probably some, but most of it is C/C++. It has to be efficient, because if it's inefficient, everything that's based on it will be as well. Now, what you base on it might be inefficient based on your design, but that's your choice.
Yes, I agree - but there are 'degrees' in all of this. I just find it frustrating that we have an historical legacy in C/C++ that favours efficiency over all else - all I'd like (especially in libraries) is an option - the default behaviour says 'do it safer, but slower', and the option says "get out of the way, I need the speed". A trivial example based upon the std::string class supplied as part of VC++ 6. The std::string constructor that takes a 'char*' parameter will crash if the pointer passed in is NULL. Yet, setting a char* to NULL is a standard way of initialising C-style 'char* strings'. When we moved a set of code from char* to std::string, we spent weeks finding and removing bugs caused by the interaction between 'NULL char* strings' and 'empty std::string'. And we still get crahses in new code when programmers 'forget' the differences and try to initialise std::string using NULL (like they've done for years in C/C++) Why doesn't the constructor test for NULL, and simply set the std::string to 'empty' if it is NULL? This would greatly simply change over from old to new. Why doesn't do this? Because it is inefficient to test the char* against NULL when 95% of the time it will not be NULL. The design favour the 95% case. This seems correct,except that the 5% case means a program crash!!! My point would be that std::string should offer safety first, so the constructor does check against NULL. Then add an optional function or second constructor (taking a second bool parameter, perhaps?) that does not check, so that people who need to eliminate that NULL check can. I'm not arguing against C++ and efficiency, just suggesting that perhaps the time has come to change the focus, and favour protection against simple (but common) mistakes.