Stroustrup on next-gen C++: I didn't want to let go of my baby(theregister.co.uk)
theregister.co.uk
Stroustrup on next-gen C++: I didn't want to let go of my baby
http://www.theregister.co.uk/2012/12/13/stroustrup_on_c_plus_plus/
53 comments
I think the notable exception to that rule is Go.
Go is imported by Google, not exported by them.
It's also got good funding, a large number of well known core team members (who won't let it die) and a good license which protects the users in the future.
Go is imported by Google, not exported by them.
It's also got good funding, a large number of well known core team members (who won't let it die) and a good license which protects the users in the future.
Could you explain the "imported" comment? (I don't know much about the history of Go, and it looks a lot like Google is exporting it.)
Google don't really prescribe what happens with Go from what I can see. It's left up to the Go team who's focus is to produce a general purpose language and the community who want a stable product that fills their needs as well. Google take the stable release and use it internally. Therefore Google import it from the community project.
Some other notable organisations develop everything internally and then release it to the public i.e. they export it. For example C#.
Some other notable organisations develop everything internally and then release it to the public i.e. they export it. For example C#.
> who's focus is to produce a general purpose language
More a "solve Google's specific problems" language, general Google purpose
More a "solve Google's specific problems" language, general Google purpose
Um, nope? What exactly is google-specific about it? Nothing from what I can tell. It's as general-purpose as C or Python or JS etc etc. In fact, it's basically C, slightly redesigned from scatch for this decade rather than the one 30 years ago...
It's not dictated by Google management, but it's definitely directed by Pike et al to address the concerns of companies developing software at Google's massive scale.
As an example, C++ and Java programs at Google were taking more than half an hour to compile. This is why Go's semantics were chosen with speed-of-compilation in mind:
* Strictly acyclic module hierarchies (greatly simplifies compile-time name resolution)
* No generics (specialization has a compile-time cost)
* Unused imports are a fatal compilation error (to avoid having to parse unnecessary files)
All three of these decisions are somewhat contentious; Pike admits as much in many of his talks. But they were chosen because of the challenges of writing software at Google's scale. It is in this roundabout way that Go "belongs" to Google, in the sense that it addresses problems that Google has and prioritizes the best solutions to those problems, whether or not those solutions are at odds with the needs of non-Google users.
As an example, C++ and Java programs at Google were taking more than half an hour to compile. This is why Go's semantics were chosen with speed-of-compilation in mind:
* Strictly acyclic module hierarchies (greatly simplifies compile-time name resolution)
* No generics (specialization has a compile-time cost)
* Unused imports are a fatal compilation error (to avoid having to parse unnecessary files)
All three of these decisions are somewhat contentious; Pike admits as much in many of his talks. But they were chosen because of the challenges of writing software at Google's scale. It is in this roundabout way that Go "belongs" to Google, in the sense that it addresses problems that Google has and prioritizes the best solutions to those problems, whether or not those solutions are at odds with the needs of non-Google users.
I see Go basically as Google's kind (duck typing, garbage collection, faster, no Global Interpreter Lock) migration offer to their Python Coders to get rid of hampered (for Google scale) Python, some kind of Python++. If some C++ coders want to migrate also (shorter compile times, better dependency management (no messy include files)), they are welcome.
I agree about Microsoft's heavy-handedness. Interestingly, the C# language up to version 3.0 is ISO standard (SO/IEC 23270:2006).
>I can see this first hand with Objective-C, where Apple evolves the language as they see fit. The joining of such different paradigms as Smalltalk-style OO and C was fragile in the first place and can barely sustain the new functionality.
Huh? Cocoa (and the rest of Obj-C libraries Apple does) are just fine, hardly "barely sustained" by the language.
And it wasn't even Apple, the core framework logic is mostly the same as in NeXT era Objective-C (minus some welcomed syntactic sugar additions).
Smalltalk-style OO and C are very well married in Objective-C, and the language has been, historically, a joy to work with. Jusk ask Tim Berners Lee and Carmack.
Even today it gives strengths that other platforms lack, namely the ability to have very dynamic high level abstractions and easily drop to C whenever you want, which for desktop and especially mobile use is very nice: better memory management and no GC pauses, while still having a full blown OO GUI framework.
Huh? Cocoa (and the rest of Obj-C libraries Apple does) are just fine, hardly "barely sustained" by the language.
And it wasn't even Apple, the core framework logic is mostly the same as in NeXT era Objective-C (minus some welcomed syntactic sugar additions).
Smalltalk-style OO and C are very well married in Objective-C, and the language has been, historically, a joy to work with. Jusk ask Tim Berners Lee and Carmack.
Even today it gives strengths that other platforms lack, namely the ability to have very dynamic high level abstractions and easily drop to C whenever you want, which for desktop and especially mobile use is very nice: better memory management and no GC pauses, while still having a full blown OO GUI framework.
Stoustrup is right, there's many dark and really dank corners of C++ and people start poking around in them and bringing them into production code and that's just bad for everyone. It's like tigers, tigers are awesome and it's great that our ecosystem has developed to support them, but you don't put a tiger in your house.
I do C++ dev work for a living, I enjoy it. The language can be a nightmare, but as long as you're sensible and frugal with what you're using it's no worse than anything else. The trick is to really, really think about whether a specific feature is worth taking into a more complex direction with some of the edgier C++ functionality, or sticking with more core, basic, understandable code which might trade off performance.
I should probably say I've not done any 'proper' C++ development for a while, mostly we build with Qt and that abstracts a lot of the headaches away into a nice toolkit.
I do C++ dev work for a living, I enjoy it. The language can be a nightmare, but as long as you're sensible and frugal with what you're using it's no worse than anything else. The trick is to really, really think about whether a specific feature is worth taking into a more complex direction with some of the edgier C++ functionality, or sticking with more core, basic, understandable code which might trade off performance.
I should probably say I've not done any 'proper' C++ development for a while, mostly we build with Qt and that abstracts a lot of the headaches away into a nice toolkit.
"as long as you're sensible and frugal with what you're using it's no worse than anything else"
That is part what makes C++ worse: the fact that being a C++ experts primarily means knowing what not to do.
That is part what makes C++ worse: the fact that being a C++ experts primarily means knowing what not to do.
Being an expert in any language means knowing what not to do, more than knowing what you should do.
Really? When someone says they are an expert in Java, they do not mean that they are well-versed in what sort of Java statements have unexpected, undefined, or indeterminate behavior. Even more so when someone calls themselves an expert in Lisp, Haskell, Scala, and other high-level languages. We are not talking about maintainability or style, we are talking about just being able to solve basic computational problems without having your program abort. In addition to this entire book on what not to do, books on advanced C++ programming (like the "Effective C++" series) are loaded with things you shouldn't do:
http://www.semantics.org/cpp_gotchas/index.html
C++ also encourages programmers to do "bad things," where other languages discourage such code. In Scheme, arguments to functions are evaluated in an undefined order, and so such arguments should never have global side effects; but Scheme discourages global side effects in general. In C++, arguments to functions are also evaluated in an undefined order...but global side effects are encouraged and widely used in C++, and it is easy to inadvertently create a situation where this becomes a problem (e.g. one argument might resize a vector, when the other is an iterator to that vector -- both common, both encouraged, but a pretty bad combination). C++ makes the most dangerous ways to do things the easiest and least verbose: pointers to access arrays, fixed-width integers, floating point numbers, etc.; other languages make such dangerous things more verbose and force programmers to be explicit when they try to utilize such constructs.
http://www.semantics.org/cpp_gotchas/index.html
C++ also encourages programmers to do "bad things," where other languages discourage such code. In Scheme, arguments to functions are evaluated in an undefined order, and so such arguments should never have global side effects; but Scheme discourages global side effects in general. In C++, arguments to functions are also evaluated in an undefined order...but global side effects are encouraged and widely used in C++, and it is easy to inadvertently create a situation where this becomes a problem (e.g. one argument might resize a vector, when the other is an iterator to that vector -- both common, both encouraged, but a pretty bad combination). C++ makes the most dangerous ways to do things the easiest and least verbose: pointers to access arrays, fixed-width integers, floating point numbers, etc.; other languages make such dangerous things more verbose and force programmers to be explicit when they try to utilize such constructs.
Oh come on; you have to try to find the dark corners, its not like they seek you out!
Having taught C++ to novices, I can assure you that the "dark corners" are not hard to find. You need to be taught what is wrong in C++, and you need to learn "folklore" e.g. always use -Wall, before you can really program effectively in C++.
Out of curiosity, if one wanted to "re-learn modern C++" after years of Java, Python, Ruby, where could he start from? (something like a "crash course") Is Stroustrup's "Principles and Practice Using C++" any good for this purpose?
Depending on your prior expertise level with c++98, you could pick up the c++11 just by looking at deltas of the standard.
Along those lines, the Microsoft compiler team had a good blog post with links to relevant portions of the standard that I found helpful. [0] All of those "No" not implemented yet is a definite problem. I can also recommend the MSDN series "Welcome Back to C++ (Modern C++)" [1]. And also Microsoft supplies the source code for an app called "hilo" that utilizes c++11, asynchronous techniques and MVVM patterns, but obviously in the context of the microsoft platform! [2]
[0]: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...
[1]: http://msdn.microsoft.com/en-us/library/hh279654(v=vs.110).a...
[2]: http://hilo.codeplex.com/
Along those lines, the Microsoft compiler team had a good blog post with links to relevant portions of the standard that I found helpful. [0] All of those "No" not implemented yet is a definite problem. I can also recommend the MSDN series "Welcome Back to C++ (Modern C++)" [1]. And also Microsoft supplies the source code for an app called "hilo" that utilizes c++11, asynchronous techniques and MVVM patterns, but obviously in the context of the microsoft platform! [2]
[0]: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a...
[1]: http://msdn.microsoft.com/en-us/library/hh279654(v=vs.110).a...
[2]: http://hilo.codeplex.com/
Principles and Practices is a book for people who have not programmed before. Unfortunately, the book you want is the fourth edition of The C++ Programming Language, which will not be available until April: http://www.amazon.com/dp/0321563840
yep, I'll probably order it when it comes out ...though it's definitely not a "crash course" :)
C++ Primer, 5th Edition, by Stanley B. Lippman, Josée LaJoie, Barbara E. Moo: https://www.informit.com/store/c-plus-plus-primer-9780321714... and http://isocpp.org/
I tend to think the new C++ is apt for a new project with no historical burden. We can always use the more modern features. However this may not hold true for existing projects with a number of developers
We were lucky enough to start a new project ~1 year ago - completely in C++11. We make heavy use of all the new fun C++11 stuff like lambdas, move constructors (yay, no vectors of pointers anymore!) and all that auto/decltype syntactic sugar.
And I must say: It's a whole different programming language and a new level of productivity.
And I must say: It's a whole different programming language and a new level of productivity.
Depending on move constructors scare the bajeezus out of me because I have no way of knowing if it's working properly. It's behavior is also implementation specific. Given the following test you'll get a variety of results depending on your platform.
struct Foo{...} std::vector<Foo> vec; for( int i = 0; i < 10; ++i) { vec.push_back( Foo() ); }
Results: 35 move / 25 copy / 10 move + 15 copy / 25 move.
It all depends on your compiler and STL implementation. Not knowing scares the hell out of me.
struct Foo{...} std::vector<Foo> vec; for( int i = 0; i < 10; ++i) { vec.push_back( Foo() ); }
Results: 35 move / 25 copy / 10 move + 15 copy / 25 move.
It all depends on your compiler and STL implementation. Not knowing scares the hell out of me.
I assume what you are saying is the following?
* Compilers are introducing move as we move in C++11. If you compile your code in C++03 (or a compiler with partial C++11 support, no move).
* The standard doesn't place a strict definition on how vectors are increased in size as you push_back. Of course, if you want to control the amount of space in a vector manually, rather than let your compiler decide, you can reserve in advance.
Is your problem just with moving to C++11, or do you get different numbers (other than different numbers of moves) in a compiler with proper C++11 support (basically, the most recent version of everything).
* Compilers are introducing move as we move in C++11. If you compile your code in C++03 (or a compiler with partial C++11 support, no move).
* The standard doesn't place a strict definition on how vectors are increased in size as you push_back. Of course, if you want to control the amount of space in a vector manually, rather than let your compiler decide, you can reserve in advance.
Is your problem just with moving to C++11, or do you get different numbers (other than different numbers of moves) in a compiler with proper C++11 support (basically, the most recent version of everything).
You could also look into emplace_back()
http://en.cppreference.com/w/cpp/container/vector/emplace_ba...
http://en.cppreference.com/w/cpp/container/vector/emplace_ba...
I don't understand your comment. Please try the following:
vec.reserve(10);
and report back how many allocations occur.
vec.reserve(10);
and report back how many allocations occur.
At this point assuming your team makeup hasn't changed much, have you been able to generate any intesting metrics to guage the increase in productivity?
Also what compiler did you feel comfortable picking a year ago to base a production development effort on?
Also what compiler did you feel comfortable picking a year ago to base a production development effort on?
Except that's not how it works. The realistically high skilled C++ people are far and few between so you end up with a shit crock cludged together out of vaguely bastardised MFC'ish code, knotted with Win32 and ATL and Boost with a load of "features which were too dangerous to use" removed.
C++ has such a bad legacy, it's going to be really hard to shake off the bad old days.
Perhaps in time when the newer generations actually have been using C++11 for a while, but not for at least 5-10 years if you ask me.
C++ has such a bad legacy, it's going to be really hard to shake off the bad old days.
Perhaps in time when the newer generations actually have been using C++11 for a while, but not for at least 5-10 years if you ask me.
Beyond the complexity of C++ I think one of the biggest problems with it is the lack of self sufficient standard libraries. There was always something extra that needs to be done. For example, simple things like converting a string to a number involves more thinking and knowledge (using string streams) that what is really necessary.
I agree entirely. The one thing which is pushing me from C++ to Haskell is cabal, and a large selection of easy-to-install libraries.
One thing that makes this hard in C++ of course is people tend to get annoyed if libraries don't work with clang, g++ and a recent visual studio. Even then you have the problem of older g++ and old visual studio, and then esoteric compilers. In Haskell on the other hand people tend to always be running a recent version of ghc.
One thing that makes this hard in C++ of course is people tend to get annoyed if libraries don't work with clang, g++ and a recent visual studio. Even then you have the problem of older g++ and old visual studio, and then esoteric compilers. In Haskell on the other hand people tend to always be running a recent version of ghc.
c++11 includes std::string/number conversion.
eg:
int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string to_string(int value);
http://en.cppreference.com/w/cpp/string/basic_string
eg:
int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string to_string(int value);
http://en.cppreference.com/w/cpp/string/basic_string
But it's 2012! it's late.
Actually, in that case you would use wxWidgets instead of any MFC&Win32.
Or some Qt with its non-standard metacompiler.
But yes, that can be considered bad legacy stuff.
Or some Qt with its non-standard metacompiler.
But yes, that can be considered bad legacy stuff.
We could start with a little honesty. Perhaps the C++ zealots could explain to us how the great new features they promoted for so long were actually a crock of shit. Things like auto_ptr, throw specifications, the export keyword and so forth were promoted as the bee's knees. It's funny how they love to criticize C and its "evil arrays and pointers", but never admit their own mistakes. And they've made so many, so many more than C ever did.
Where are you getting these ideas from? Who are these C++ zealots you have been listening to? Certainly no-one I talk to.
No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr".
Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them.
I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction.
In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?
No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr".
Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them.
I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction.
In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?
(In a way this is off-topic, but I feel the need to point out that the throws() specifiers in C++ are not like Java's: they are more like a runtime assertion that "if this function throws something not in this set of types, terminate my program"; the result is a situation where you gain nothing at compile time, force an on-some-architectures-painfully-slow exception check on the function, and in the end find yourself with a very similar result to having just not caught the exception at all. This particular C++ feature was sufficiently useless as to be downright harmful. The Java feature, by comparison, has some defensible merit ;P.)
To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)
To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)
On the other hand, when I talk about the problems with exceptions in C++, the C++ zealots come out in force. Rather than admit that C++ does exceptions the wrong way, they (a) point to other languages as having the same problem (b) claim that exceptions should not be used in cases where the problems are problems and (c) accuse you of not really understanding what exceptions, destructors, constructors, and object oriented programming are about. Rather than fix the problems with C++ exception in C++11, the standards committee further cemented those problems.
I think you fail to understand what it means to evolve a language specification rather than breaking one.
I think given your obvious bias in both method and approach you should probably just plan on learning a new language every 2-3 years or so when what your ideas of the "best" way to do things changes and languges supporting the latest fad are developed. Probably, just avoid commenting on C++ altogether as it is a waste of your energy because it will quite frankly never do what you want given the aims and goals of the steering committee.
I think given your obvious bias in both method and approach you should probably just plan on learning a new language every 2-3 years or so when what your ideas of the "best" way to do things changes and languges supporting the latest fad are developed. Probably, just avoid commenting on C++ altogether as it is a waste of your energy because it will quite frankly never do what you want given the aims and goals of the steering committee.
Out of interest, what do you feel are the solvable problems with exceptions in C++? The obvious one is exception specifications, which are probably best ignored.
While I agree they are frequently a pain, I'm unaware of any language which has really managed to do exceptions much better. I am happy to hear of examples however.
While I agree they are frequently a pain, I'm unaware of any language which has really managed to do exceptions much better. I am happy to hear of examples however.
Double exception faults come to mind; C++11 did not even attempt to solve this problem, and just sort of brushed it under the rug. The solution to double exception faults is pretty straightforward: the stack should not be unwound until either the end of the exception handler or if the exception handler explicitly unwinds the stack. The downside is that it adds complexity to code generation and some overhead to functions with exception handlers, but the upside is that you have a far more robust exceptions system, and you have an opportunity to add a very nice feature that can help a lot with encapsulation: restarts.
Since you asked for examples, I'll point to the Common Lisp "conditions" system, which includes restarts:
http://www.gigamonkeys.com/book/beyond-exception-handling-co...
(I'll be honest here and point out that "handler-case," while simpler and more convenient, can still have a double exception fault; this is resolved similar to how Java resolves such things, which is to "forget" one of the exceptions. "handler-bind" is slightly less convenient but is much more robust, and does not have this problem.)
Since you asked for examples, I'll point to the Common Lisp "conditions" system, which includes restarts:
http://www.gigamonkeys.com/book/beyond-exception-handling-co...
(I'll be honest here and point out that "handler-case," while simpler and more convenient, can still have a double exception fault; this is resolved similar to how Java resolves such things, which is to "forget" one of the exceptions. "handler-bind" is slightly less convenient but is much more robust, and does not have this problem.)
toning down the rhetoric, a good "modern c++" book would be awesome - something that shows how to use a solid, simple core with the latest features in, say, the first half, and then has further chapters extending that with more complex approaches where needed.
i've asked for this kind of thing before,but never had a really good suggestion. seems like it could be a huge seller...
[when i last asked here what, 6 months ago, i think the only vaguely useful answer i got was to read the draft standard]
i've asked for this kind of thing before,but never had a really good suggestion. seems like it could be a huge seller...
[when i last asked here what, 6 months ago, i think the only vaguely useful answer i got was to read the draft standard]
+1 for a "C++: The Good Parts". With a resource like that I might be interested in taking another look at the language.
This sort of thing would be extremely useful for me at the moment. I have a new role starting in a month or so, with a lot of green-field C++ development work. I'm happy with OO concepts and have extended a variety of pre-existing C++ in my time, but my main body of knowledge is most definitely C.
Can anyone recommend a quick-start guide to modern(ish) C++ for the experienced C developer?
Can anyone recommend a quick-start guide to modern(ish) C++ for the experienced C developer?
If you're coming from C, then you need to understand the STL's concepts of "Concepts", "Modeling", "Refinement", and Iterators etc: http://www.sgi.com/tech/stl/index.html
(that link doesn't cover C++11, nor even the STL additions in C++03 and TR1; but it is still essential background reading).
When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
C++ Primer was updated to C++11.
http://www.amazon.com/Primer-5th-Edition-Stanley-Lippman/dp/...
The C++ FAQ is really helpful but doesn't seem to be updated to C++11 http://www.parashift.com/c++-faq/
Fortunately you can refer to Stroustrup's FAQ about C++11 http://www.stroustrup.com/C++11FAQ.html
For reference (like libc manpage, basic usage, which header to include): http://en.cppreference.com/
The C++ FAQ is really helpful but doesn't seem to be updated to C++11 http://www.parashift.com/c++-faq/
Fortunately you can refer to Stroustrup's FAQ about C++11 http://www.stroustrup.com/C++11FAQ.html
For reference (like libc manpage, basic usage, which header to include): http://en.cppreference.com/
"Welcome Back to C++ (Modern C++)" while not a book is not a bad place to start (I posted the link earlier in a prior comment, sorry for the dup):
http://msdn.microsoft.com/en-us/library/hh279654.aspx
http://msdn.microsoft.com/en-us/library/hh279654.aspx
I disagree entirely. I would say that C++ should be treated like COBOL: useful only to maintain legacy code that nobody has the time or money to rewrite in a better language. C++ is a mess, and C++11 has done little to make C++ less of a mess.
Ah that must be the reason why gcc migrated their codebase to C++!
> “A lot of people look at C++ and want to understand every dark corner. This is what you do if you want to be a compiler writer, but most people should look at what is the easiest way to write a good solution for their problem," said Stroustrup.
Ha! So even Soustrup agrees C++ is inevitably subsetted by its users.
> “I try to focus on things that lead to correct programs fairly easily. I emphasise the use of constructors to establish invariance, to acquire resources, destructors for cleaning up, copy operations, and the new [C++ 11] move semantics that allow you to move an object out of one scope and into another one very cheaply," he added.
Keeping the rest of the quote here - now I'm looking for a more abstract and more inclusive notion about what constructors and destructors do.
Ha! So even Soustrup agrees C++ is inevitably subsetted by its users.
> “I try to focus on things that lead to correct programs fairly easily. I emphasise the use of constructors to establish invariance, to acquire resources, destructors for cleaning up, copy operations, and the new [C++ 11] move semantics that allow you to move an object out of one scope and into another one very cheaply," he added.
Keeping the rest of the quote here - now I'm looking for a more abstract and more inclusive notion about what constructors and destructors do.
what an ugly baby that is...
Whata possessive father :-)
I can see this first hand with Objective-C, where Apple evolves the language as they see fit. The joining of such different paradigms as Smalltalk-style OO and C was fragile in the first place and can barely sustain the new functionality.
Another example is C#. No matter how nice the language becomes, it will always be the MS language for me, and I don't trust MS when it comes to APIs and languages - they shuffle things around for no reason, cancel projects, etc. And then you're screwed.