Your assumption, that Office 2016 and Skype For Business are unrelated, is incorrect. The GP is likely referring to how Skype For Business 2016 is bundled with the Professional Plus edition of Office 2016. IOW, (s)he meant "update to the latest Skype For Business". So, most likely not shilling.
watts per gram ? Since when is that a measurement standard?
It isn't, yet. But, I first heard of "performance per watt" when Transmeta debuted their first CPU, and similarly thought "who (expletive) cares about that"? Today, performance per watt actually matters in some applications (parallel systems, possibly data centers...).
Point is, somebody may find a compelling use for these devices if they can be made practical, be they solar-powered robo-flies or whatever.
That defer keyword looks like the mother of all hidden bugs.
At first glance it looks to me like Apple ripped defer straight from Go. I think it has its use -- in a language that doesn't support RAII. But I prefer the latter.
I agree, if we change "about ten years" to "at *least* ten years". Tongue only slightly in cheek. C++ took 25 years (C++11) to become, IMO, a compelling improvement over C.
I disagree with basically everything the coward said -- particularly wrt the Rust community which I think is great -- but I don't use Rust (yet), either. The things that irk me the most about Rust are the lifetime annotations, the fact that it's non-trivial to write a linked-list implementation, and a few issues that will go away after further development (overly restrictive borrow checker and compiler speed). The place it would come in most useful -- working in a corporate-ish environment with morons who don't understand ownership issues and who need a compiler to slap sense into them -- is also the place it is currently (due to novelty, immaturity, and inertia) the least adopted.
But, if Rust can get over some of its present hurdles, it has the potential to become a really good language. And, many would say it already is one today.
Not disagreeing with you, but a nullptr-to-reference cast would at least crash immediately (unless you have a compiler that takes "undefined behavior" too literally). Here's another contrived example:
const char *c = std::string("oops").c_str();
I'm not a c++ expert but I'm pretty sure 'c' now points to freed memory. The real problem is that the code will usually work until a customer runs it. And solutions like valgrind aren't always optimal (consider code coverage and execution speed) or even necessarily available, depending on your platform.
Rust eliminates this class of errors (and several others) entirely, unless you are abusing 'unsafe' (which you can at least grep for in your code) as you mentioned.
I would like Rust to succeed. In several ways, it is basically a 'better' C++ without the C baggage that a lot of people seem to want, and it is clear that Rust's developers have put a lot of thought into it. Still, the language has its warts and oddities. My biggest concern is that support for implementing intrusive data structures (you can Google that, but the Linux kernel's double-linked lists is an example) seemed to be possible, but not Easy, and I think it should be. I also haven't wrapped my head around Rust's lifetimes yet, but it looks clunky. Other things (slow compiler, incomplete library support) should get better with time.
I wish the Rust guys the best of luck, and look forward to using it.
As a data point of one, I'm still running with the 4GB of OCZ ram I bought from newegg (I think) in 2009 and have had no problems. The reviews on that product were also decent.
After reading reviews of their SSD drives, though, I'd avoid those.
I guess the message here (if any) is, pay attention to the reviews on the product. If people say it's crap, it probably is.
Money isn't everything to everyone. If you were being paid $500.00 per hour to shovel out a barn, wouldn't you take a job that offered something more fun like programing with python even if it paid $490.00 per hour?
Depends on the job. Which one do I take to wade through the least amount of bullshit? I'm burnt out enough that I might try the barn for a year just for the variety.
Unfortunately I've had the opposite experience. Wine mostly works, and it's amazing it works as well as it does, but something is always broken just enough to make things suck.
In my case, I tried the Portal demo recently, and had random freezes every 10 sec or so that made the game unplayable. (Plus insanely slow startup on a system equipped w/an SSD, but I could deal with that.)
I was looking forward to trying a Linux version of the demo so I could buy the game if it worked. Oh well, too bad for me.
Going offtopic, but another good thing about CISC is that you can optimize such that the most common instructions have the shortest instruction lengths possible. This slightly reduces the disc space and memory used by programs.
Why in the world would a judge hear a case when the outcome could effect his own wealth?
Not to distract from the topic at hand, but you do not appear to be familiar with the rich history of Louisiana politics. Try googling "Louisiana political corruption". (some of the links do say they've been getting sick of it post-Katrina.)
One of the good things about living in Texas is that it is always acceptable to hold the door open for anybody, and more generally than that, it's never impolite to be polite.
The assailant apparently claims he was being harassed constantly. In that case, I would expect a small-dick accusation regardless of the actual size of the package. (well, unless he was hung like a horse)
Thanks for the thoughtful and comprehensive reply.
I realize and understand that C99 is not a C++ standard and that VC++'s priority is C++ support. Of course, my priorities are different. I shouldn't claim that VC++ is bad for everybody, but it is bad for me.
Speaking of VLAs specifically, they have been broken in GCC until very recently
It is true VLAs are/were 'broken' in GCC in the sense that they are not fully C99 conformant. That has been documented in the info pages for a long time. However, speaking practically, for the simple declarations I have used, I have never had a problem. Perhaps I ought to double-check that:P
it's simply non-portable in practice
I agree that non-portability across compilers would be a problem, except that of course GCC itself is so incredibly portable, and is also the preferred compiler on many non-Windows platforms.
FWIW, I am not a C99 stickler -- I only care about the parts of it that I use, and I specifically don't worry about free-form variable declarations because there is an easy fix -- declare your variables only after a block begins.
VLAs have no "easy fix" -- the closest alternative is alloca(), which my manpage claims is "buggy" on many unspecified systems, and of course, it's not really portable or standard either. Using malloc() is slower, uglier (since if you're doing it right you'll want to check the return value), and has the potential to fragment your memory.
I apologize if these points have already been debated to death in the flamewars -- I don't read that group. I also expect you are already aware of these points and were simply trying to make yours, in which case, this was a superfluous post. Oh well:P
What exactly is bad about VC++ compiler? Can you be more specific? Are you unhappy about it not supporting C++ exception specifications (which no-one uses anyway)? Do you have a problem with optimization quality (in my experience, VC++ inlines things better and deeper than g++)?
VC++ doesn't support variable-length arrays. IOW it pukes on
void foobar(int i) { int myarray[i]; }
Variable-length arrays are part of the C99 standard. That's 10 years old at this point and it's a pattern I employ often. I am unsure of the status of this in VC++ 2010 (coming Real Soon) but last I heard, it still wasn't in.
Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers).... Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event.
I don't understand this. It's true Linux does not have kqueue. (as I recall Linus thought it was "ugly"... whatever) But in theory (because I haven't actually used them), to achieve the same effect under Linux, you would use timerfd() + signalfd() + (your normal i/o fds like sockets etc.)... and then epoll_wait()/poll()/select() on all of the fds you were interested in. In this way, one thread could wait for multiple different types of events, including timers and signals.
Would you please point out the flaws w/the above that make it impossible or impractical to achieve the functionality needed by Grand Dispatch? I would be enlightened -- thanks in advance.
I did run iBCS, and while it seemed to work well for what it did, it is not a panacea for everything.
For example, anything that was dynamically linked would still have dependencies on the original system libraries. So you get to copy all those over, worry about licensing issues (if you're trying to redistribute, anyway), and hope something didn't break on the way. In my experience, a c++ widget-generating app we were trying to run encountered both of those roadblocks, and we determined it was better to go another route -- java, hah!
You can lend friends money. Just not money you would mind losing. It's like gambling basically.
Side note: I once loaned a small amount of money to an annoying "friend" who then apparently fell off the face of the earth. It was worth the money. Although I suppose I could have achieved the same effect by just being a d*ck about his sob story, but that eats at your conscience a little more.
Though I imagine the problem for larger computations could be that you're limited to writing functional-style code, at which point you might be better off using a language designed for it?
Point taken, assuming it has to be fast and there is that much critical code.
What optimizations does gcc actually do on pure functions, having identified them?
Well, it doesn't dispatch them:-) from what I read in the documents, all it might do now is common subexpression elimination.
I was eating vermicelli at a Vietnamese restaurant, with a bunch of kids running around the tables, and Hannibal was playing (muted) on their big screen TV.
Slashdot Mirror
Your assumption, that Office 2016 and Skype For Business are unrelated, is incorrect.
The GP is likely referring to how Skype For Business 2016 is bundled with the Professional Plus edition of Office 2016.
IOW, (s)he meant "update to the latest Skype For Business". So, most likely not shilling.
watts per gram ? Since when is that a measurement standard?
It isn't, yet. But, I first heard of "performance per watt" when Transmeta debuted their first CPU, and similarly thought "who (expletive) cares about that"? Today, performance per watt actually matters in some applications (parallel systems, possibly data centers ...).
Point is, somebody may find a compelling use for these devices if they can be made practical, be they solar-powered robo-flies or whatever.
That defer keyword looks like the mother of all hidden bugs.
At first glance it looks to me like Apple ripped defer straight from Go. I think it has its use -- in a language that doesn't support RAII. But I prefer the latter.
I agree, if we change "about ten years" to "at *least* ten years". Tongue only slightly in cheek. C++ took 25 years (C++11) to become, IMO, a compelling improvement over C.
I disagree with basically everything the coward said -- particularly wrt the Rust community which I think is great -- but I don't use Rust (yet), either. The things that irk me the most about Rust are the lifetime annotations, the fact that it's non-trivial to write a linked-list implementation, and a few issues that will go away after further development (overly restrictive borrow checker and compiler speed). The place it would come in most useful -- working in a corporate-ish environment with morons who don't understand ownership issues and who need a compiler to slap sense into them -- is also the place it is currently (due to novelty, immaturity, and inertia) the least adopted.
But, if Rust can get over some of its present hurdles, it has the potential to become a really good language. And, many would say it already is one today.
What makes you think elemental lithium is any safer than elemental sodium? Pro-tip: it isn't.
That depends on how you're measuring "safer". For example, sodium is more reactive than lithium in water.
Not disagreeing with you, but a nullptr-to-reference cast would at least crash immediately (unless you have a compiler that takes "undefined behavior" too literally). Here's another contrived example:
const char *c = std::string("oops").c_str();
I'm not a c++ expert but I'm pretty sure 'c' now points to freed memory. The real problem is that the code will usually work until a customer runs it. And solutions like valgrind aren't always optimal (consider code coverage and execution speed) or even necessarily available, depending on your platform.
Rust eliminates this class of errors (and several others) entirely, unless you are abusing 'unsafe' (which you can at least grep for in your code) as you mentioned.
I would like Rust to succeed. In several ways, it is basically a 'better' C++ without the C baggage that a lot of people seem to want, and it is clear that Rust's developers have put a lot of thought into it. Still, the language has its warts and oddities. My biggest concern is that support for implementing intrusive data structures (you can Google that, but the Linux kernel's double-linked lists is an example) seemed to be possible, but not Easy, and I think it should be. I also haven't wrapped my head around Rust's lifetimes yet, but it looks clunky. Other things (slow compiler, incomplete library support) should get better with time.
I wish the Rust guys the best of luck, and look forward to using it.
As a data point of one, I'm still running with the 4GB of OCZ ram I bought from newegg (I think) in 2009 and have had no problems. The reviews on that product were also decent.
After reading reviews of their SSD drives, though, I'd avoid those.
I guess the message here (if any) is, pay attention to the reviews on the product. If people say it's crap, it probably is.
What, dare I ask, is a salad shooter?
Just google "salad shooter". It's a kitchen gadget.
K&R is perhaps the single ugliest coding style I have ever seen or used.
Let me introduce you to the GNU coding standards. Please pay particular attention to the crazy way they indent the braces in the function body.
Money isn't everything to everyone. If you were being paid $500.00 per hour to shovel out a barn, wouldn't you take a job that offered something more fun like programing with python even if it paid $490.00 per hour?
Depends on the job. Which one do I take to wade through the least amount of bullshit?
I'm burnt out enough that I might try the barn for a year just for the variety.
Do they have to be in "Airplane" mode?
If the airliner has to transform to Robot Mode to make this work, I can foresee a lot of problems.
Is that because you don't like Compellent, or don't like Dell? (I don't work for either of these companies ...)
Unfortunately I've had the opposite experience. Wine mostly works, and it's amazing it works as well as it does, but something is always broken just enough to make things suck.
In my case, I tried the Portal demo recently, and had random freezes every 10 sec or so that made the game unplayable. (Plus insanely slow startup on a system equipped w/an SSD, but I could deal with that.)
I was looking forward to trying a Linux version of the demo so I could buy the game if it worked. Oh well, too bad for me.
Going offtopic, but another good thing about CISC is that you can optimize such that the most common instructions have the shortest instruction lengths possible. This slightly reduces the disc space and memory used by programs.
Why in the world would a judge hear a case when the outcome could effect his own wealth?
Not to distract from the topic at hand, but you do not appear to be familiar with the rich history of Louisiana politics. Try googling "Louisiana political corruption". (some of the links do say they've been getting sick of it post-Katrina.)
One of the good things about living in Texas is that it is always acceptable to hold the door open for anybody, and more generally than that, it's never impolite to be polite.
The assailant apparently claims he was being harassed constantly. In that case, I would expect a small-dick accusation regardless of the actual size of the package. (well, unless he was hung like a horse)
Thanks for the thoughtful and comprehensive reply.
I realize and understand that C99 is not a C++ standard and that VC++'s priority is C++ support. Of course, my priorities are different. I shouldn't claim that VC++ is bad for everybody, but it is bad for me.
Speaking of VLAs specifically, they have been broken in GCC until very recently
It is true VLAs are/were 'broken' in GCC in the sense that they are not fully C99 conformant. That has been documented in the info pages for a long time. However, speaking practically, for the simple declarations I have used, I have never had a problem. Perhaps I ought to double-check that :P
it's simply non-portable in practice
I agree that non-portability across compilers would be a problem, except that of course GCC itself is so incredibly portable, and is also the preferred compiler on many non-Windows platforms.
FWIW, I am not a C99 stickler -- I only care about the parts of it that I use, and I specifically don't worry about free-form variable declarations because there is an easy fix -- declare your variables only after a block begins.
VLAs have no "easy fix" -- the closest alternative is alloca(), which my manpage claims is "buggy" on many unspecified systems, and of course, it's not really portable or standard either. Using malloc() is slower, uglier (since if you're doing it right you'll want to check the return value), and has the potential to fragment your memory.
I apologize if these points have already been debated to death in the flamewars -- I don't read that group. I also expect you are already aware of these points and were simply trying to make yours, in which case, this was a superfluous post. Oh well :P
What exactly is bad about VC++ compiler? Can you be more specific? Are you unhappy about it not supporting C++ exception specifications (which no-one uses anyway)? Do you have a problem with optimization quality (in my experience, VC++ inlines things better and deeper than g++)?
VC++ doesn't support variable-length arrays. IOW it pukes on
void foobar(int i) { int myarray[i]; }
Variable-length arrays are part of the C99 standard. That's 10 years old at this point and it's a pattern I employ often. I am unsure of the status of this in VC++ 2010 (coming Real Soon) but last I heard, it still wasn't in.
Agreed. In addition, since I have fairly addictive personality and enough addictions already ... I don't need to start an MMORPG habit.
Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers). ... Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event.
I don't understand this. It's true Linux does not have kqueue. (as I recall Linus thought it was "ugly" ... whatever) But in theory (because I haven't actually used them), to achieve the same effect under Linux, you would use timerfd() + signalfd() + (your normal i/o fds like sockets etc.) ... and then epoll_wait()/poll()/select() on all of the fds you were interested in. In this way, one thread could wait for multiple different types of events, including timers and signals.
Would you please point out the flaws w/the above that make it impossible or impractical to achieve the functionality needed by Grand Dispatch? I would be enlightened -- thanks in advance.
I did run iBCS, and while it seemed to work well for what it did, it is not a panacea for everything.
For example, anything that was dynamically linked would still have dependencies on the original system libraries. So you get to copy all those over, worry about licensing issues (if you're trying to redistribute, anyway), and hope something didn't break on the way. In my experience, a c++ widget-generating app we were trying to run encountered both of those roadblocks, and we determined it was better to go another route -- java, hah!
You can lend friends money. Just not money you would mind losing. It's like gambling basically.
Side note: I once loaned a small amount of money to an annoying "friend" who then apparently fell off the face of the earth. It was worth the money. Although I suppose I could have achieved the same effect by just being a d*ck about his sob story, but that eats at your conscience a little more.
Though I imagine the problem for larger computations could be that you're limited to writing functional-style code, at which point you might be better off using a language designed for it?
Point taken, assuming it has to be fast and there is that much critical code.
What optimizations does gcc actually do on pure functions, having identified them?
Well, it doesn't dispatch them :-) from what I read in the documents, all it might do now is common subexpression elimination.
The first time I saw the "brain" scene ...
I was eating vermicelli at a Vietnamese restaurant, with a bunch of kids running around the tables, and Hannibal was playing (muted) on their big screen TV.