Daily Olds?
-
I will yell sternly at Mr Insider and tell him to only include hip and trendy reading from now on. Or maybe I'll ask him to include something on FORTRAN.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Stefan63 wrote:
quite a few other bad practices in the provided examples, such as multiple return statements.
Are you trying to start a flame war here? Wanna take this outside, huh? :) I too was taught, and religiously believed, that multiple return statements were bad. I have come to realise that deeply nested and unnecessarily complex if blocks are more detrimental to readability and defect rates in code than multiple returns. Of course practice has a justification and place to be used, but I prefer clear and early returns to nested conditional blocks. However, my code is normally quite explicit about what it is doing. Of course in untidy and unstructured code, multiple returns are going to bring confusion. BTW, I don't code C, but C#, but I was first indoctrinated against multiple returns in Pascal and C++.
My experience with other people's code is that in the vast majority of cases early returns are just lazy coding, and a way out of overlong functions that shouldn't have been that long in the first place. And I've seen quite a few places that didn't properly clean up the previously allocated resources. If you have 1 return, then you have 1 point to clean up. Not saying an early return can't be easy and clean and readable, but the examples I've seen mostly weren't like that at all. Maybe your experience is different.
-
Yes, because if it doesn't come with an XML cloud, it's not worth reading. :rolleyes: Generally, using only trendy and hip reading is a good approach. This can be improved further by keeping out all the the practical, applicable things. Most of us read it only to slack off anyway.
Agh! Reality! My Archnemesis![^]
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyRight: more fluff, less brain tax. Got it.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Yes - on small systems there is the memory overhead and larger systems (we produce SoCs for STBs and TVs amongst other things) the overhead with constructors which afect driver timings as well as the memory costs. Add the overhead in usign collections etc. and controlling performance becomes almost impossible. A TV can have 20-50MB of code, sometimes more and the cost of fitting a 32MB flash device instead of 16MB in a STB (Set Top Box) can determine if there is enough margin to make it worth selling a product.
Join the cool kids - Come fold with us[^]
Interesting, I really didn't know that. Thanks for the info. Regarding the bigger systems, I know exactly what you mean, had been designing embedded systems with a considerably huge amount of 16MB flash, although only about a third of that was actually available for the app. Still, we did some pretty sophisticated programming (at least when considering this was an embedded system), including smart pointer mechanics, pool allocation, lots of inheritance and polymorphism, etc.. Each actuator and each sensor of the machine had it's counterpart in the software. The only thing we had to look out for is keep down the use of templates, which tend to blow up the binary. Now, I have no idea how much overhead all of this introduced for using C++ instead of C, but the high level of abstraction and object orientation based on physical parts of the machine allowed us to adapt our software to a new machine prototype within just one day! I don't think I've ever done a project that allowed this high degree of reuse. And that was only possible because OO mechanisms fit so well with software that is so closely linked with physical hardware.
-
I will yell sternly at Mr Insider and tell him to only include hip and trendy reading from now on. Or maybe I'll ask him to include something on FORTRAN.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Seriously, the web site was last updated more than 7 years ago, so it's hardly news. But maybe my expectations were wrong? Don't get me wrong. Even old articles have their merit, and just because they're old doesn't mean everyone is already aware of their existance. So I actually appreciate these links - I just find it odd to find something that old on a newsletter titled '*** News'. Have you considered changing the sub-headline from 'Developer News' to 'Developer Articles' or something else that doesn't imply a recent date?
-
Seriously, the web site was last updated more than 7 years ago, so it's hardly news. But maybe my expectations were wrong? Don't get me wrong. Even old articles have their merit, and just because they're old doesn't mean everyone is already aware of their existance. So I actually appreciate these links - I just find it odd to find something that old on a newsletter titled '*** News'. Have you considered changing the sub-headline from 'Developer News' to 'Developer Articles' or something else that doesn't imply a recent date?
Normally the news items are recent - very recent - but occasionally an oldie will be thrown in because it might generate some discussion, might be a blast from the past, or is just too good not for everyone not to know about it. I'll pass your feedback on, though. It's definitely valuable.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Seriously, the web site was last updated more than 7 years ago, so it's hardly news. But maybe my expectations were wrong? Don't get me wrong. Even old articles have their merit, and just because they're old doesn't mean everyone is already aware of their existance. So I actually appreciate these links - I just find it odd to find something that old on a newsletter titled '*** News'. Have you considered changing the sub-headline from 'Developer News' to 'Developer Articles' or something else that doesn't imply a recent date?
A sharp-eyed reader would notice that very few of the items in the Daily Insider newsletter are particularly newsy. I've intentionally shied away from an approach of regurgitating the day's tech news in the newsletter. If that's what you want, go check TechMeme or Mashable or CNET... they do a way better job at it than I ever could. Do you really want to know who's got VC funding, or that Justin Bieber is trending on Twitter? Instead, my focus is on looking for items that will be of interest specifically to programmers, with slight bias toward programmers working on the Microsoft stack. (Though not exclusively, because I think y'all need to be well-rounded in your skills and environments.) Very little of this is news in any sense. If it's news because you don't know much about NoSQL, then it's equally possible someone else doesn't know much about C -- particularly if they started coding in the last decade. We're not all grizzled veterans of COBOL and TurboPacal. In fact, my real goal in all of this is to do at least one of the following: A.) Make you laugh 2.) Help you learn something new III.) Spark a conversation I think this ancient article on C did all three. The feedback *is* always appreciated. Really. I'd like to see more of it, because I really do listen to the good and the bad and make changes accordingly (usually... well, sometimes). But let's dispel the notion that the daily news is actually news in the traditional sense.
-
A sharp-eyed reader would notice that very few of the items in the Daily Insider newsletter are particularly newsy. I've intentionally shied away from an approach of regurgitating the day's tech news in the newsletter. If that's what you want, go check TechMeme or Mashable or CNET... they do a way better job at it than I ever could. Do you really want to know who's got VC funding, or that Justin Bieber is trending on Twitter? Instead, my focus is on looking for items that will be of interest specifically to programmers, with slight bias toward programmers working on the Microsoft stack. (Though not exclusively, because I think y'all need to be well-rounded in your skills and environments.) Very little of this is news in any sense. If it's news because you don't know much about NoSQL, then it's equally possible someone else doesn't know much about C -- particularly if they started coding in the last decade. We're not all grizzled veterans of COBOL and TurboPacal. In fact, my real goal in all of this is to do at least one of the following: A.) Make you laugh 2.) Help you learn something new III.) Spark a conversation I think this ancient article on C did all three. The feedback *is* always appreciated. Really. I'd like to see more of it, because I really do listen to the good and the bad and make changes accordingly (usually... well, sometimes). But let's dispel the notion that the daily news is actually news in the traditional sense.
Ok, gotcha. Fair enough. And yes, while I don't follow each and every link on CP Insider Daily News, those I do follow often achieve at least 2/3 of your stated goals. And TBH I don't care all that much how old that site actually is. As I said, it just made me wonder. Oh, and I did notice that link to the FORTRAN article in the latest 'News'. Made me :laugh: before even clicking on it :thumbsup:
-
Ok, gotcha. Fair enough. And yes, while I don't follow each and every link on CP Insider Daily News, those I do follow often achieve at least 2/3 of your stated goals. And TBH I don't care all that much how old that site actually is. As I said, it just made me wonder. Oh, and I did notice that link to the FORTRAN article in the latest 'News'. Made me :laugh: before even clicking on it :thumbsup:
Excellent. My work here is done. Until tomorrow's headlines... :-)
-
Interesting, I really didn't know that. Thanks for the info. Regarding the bigger systems, I know exactly what you mean, had been designing embedded systems with a considerably huge amount of 16MB flash, although only about a third of that was actually available for the app. Still, we did some pretty sophisticated programming (at least when considering this was an embedded system), including smart pointer mechanics, pool allocation, lots of inheritance and polymorphism, etc.. Each actuator and each sensor of the machine had it's counterpart in the software. The only thing we had to look out for is keep down the use of templates, which tend to blow up the binary. Now, I have no idea how much overhead all of this introduced for using C++ instead of C, but the high level of abstraction and object orientation based on physical parts of the machine allowed us to adapt our software to a new machine prototype within just one day! I don't think I've ever done a project that allowed this high degree of reuse. And that was only possible because OO mechanisms fit so well with software that is so closely linked with physical hardware.