Note that C++ isn't necessarily type safe either. It's not at all difficult to cast an object pointer to the wrong type and crash. It's no harder than it is in C.
Of course not, that should be pretty obvious to anybody that understands that C++ is a superset of C (clue is in the title), it wouldn't really be a superset then would it? But if you're interested in strict type safety then you wouldn't be doing static (c-style) casts and if you need to do type-casting you would be using C++'s dynamic_cast.
That distribution kicked in the patent clause of GPL. Thus estoppling all licensing claims their patents against Linux.. I.E. They authorized duplication, distribution, and use by their Employees/Sub-contractors/etc all of which are 3rd parties to M$ corporate patent port folio.
I don't think that's correct, what are you considering to be the definition of "distribution" in this context? If my employer installs software on their machines I don't need a license to it, nor do I have any claim to it because my employer is the licensee, not me, they didn't distribute it to me. Just like if I use my friend's TIVO I am not a licensee of the Linux kernel within it and he is not bound to supply me with the sourcecode should I request it because he has not distributed it to me.
Also you mentioned "duplication" and "use by their employees/sub-contractors" neither of which appears to have any relevance to the GPL so I'm not sure why you said that, is there a reason you believe that has some relevance here?
We've already seen what patents they are, they've been revealed in court and were made public by the Chinese government. The question is whether they are valid.
You don't actually believe it would cost them $79 (the RRP of the separate adapter) to integrate mini-displayport like you get on other offerings at that pricepoint do you? There's no real reason to remove features like that from this price-point except to try to up-sell the Pro models.
No, OpenGL (maintained by the Khronos Group) suffers from the problems that Mantle, Metal, DX12 and Vulkan (also maintained by the Khronos Group) exist to solve. Vulkan is the future of OpenGL.
If you want to use auto, go to a dynamically typed language.
No, you misunderstand what auto is, it has nothing to do with dynamic typing. It's type is deduced at compile-time, in fact you can find out its type with static analysis.
How does that apply here? The yet-to-be-released Mantle is AMD-specific (or at least to get the most out of it you need GCN architecture which is AMD-only), Metal is Apple-specific, DirectX 12 is Microsoft-only (and thus far seems to be exclusive to Windows 10) so the only actual one that is a platform and vendor -agnostic specification here is Vulkan.
It strikes me that when you said "Vulkan would be the one to provide a compiler" that you may not have meant the one that compiles ahead-of-time or JIT compiler that compiles the bytecode to machine code and that perhaps you meant the compiler that creates the SPIR-V code. If that's the case then why would "Vulkan" or Khronos or the IHVs provide the compiler? This is a compiler that creates SPIR-V code from... well pretty much any language, so why would "Vulkan" provide this compiler?
This would do exactly the opposite. You don't compile bytecode, you compile to byte code. The entire point is that byte code is interpreted at runtime.
So it isn't the opposite, a compiler (this may be a JIT compiler) most definitely is needed. And no, it is not necessarily interpreted at runtime, for example - and I'll use LLVM because since SPIR-V was based on LLVM - how do you think you get from C++ code to native code through Clang/LLVM? Yes bytecode is generated but it isn't interpreted at runtime. Just because there is a bytecode step doesn't mean it is interpretted at runtime, so what makes you believe Vulkan is going to use JIT compilation (rather than compiled ahead of time)?
Vulkan would be the one to provide a compiler.
How can "Vulkan" provide a compiler for every GPU architecture? You mean Khronos or the IHV implementation of Vulkan (which would of course be part of their vulkan driver). It makes sense for the driver for a particular architecture to provide the compiler for that architecture, where else would the compiler come from?
That is where the market has gone even for phones with replaceable batteries. Nobody is carrying around an actual spare battery anymore.
Especially when it means you have to charge the battery in the phone, swap that battery out with the flat one then charge that one in the phone. Unless you're also going to carry around a battery charger so you can charge your spare batteries without your phone. These days if you carry around a USB charging cable you're pretty set.
A good point if you live somewhere close to an Apple Store. Not everyone does.
Of course, if there was a Microsoft Store or a Samsung Store nearby I would probably consider them too...assuming they offer the same process (not sure if they do).
Need vs. want. The OP said he'd trade a bit more thickness for more battery life. Nothing you've said is an argument against that.
I know what he said, I'm not "arguing against" his assertion that he would happily have more thickness if it meant more battery life, I don't think he was lying when he said that.
In my experience, most people don't have/use them, and most people rely on the battery in their phone. It's not clear where your claim comes from - do most people you know have them?
Most people who use them. In my experience yes indeed most people rely on the battery in their phone and don't need additional batteries, much less to the point at which they are worried about the efficiency of their additional power source.
the point is i shouldnt have to rely on a 3rd party to do the job of my product.
But that product doesn't do what you want it to do but you can buy an accessory that does make it do what you want it to do. So either buy something different or buy this product and the accessory.
as for thinness, I dont want that! Gimme a phone 2x as thick as current top tier phones (or about 1/2 as thick as old nokia candy bar phones) and give me 4X the battery life. I want some heft in my phone. not zach morris phone thick, but old candy bar phone thick
Just get a battery boost pack. Mophie (and others im sure) are already announcing their products for these new samsung phones.
VR, I see as having other problems. Oculus has had how long to release their VR stuff? It's gotten long enough that the only product is the Galaxy Gear, while plenty of people are using it for development and research.
The problem is the simulator sickness effect that people get when the messages from your eyes don't match what your inner ear is telling your brain. Oculus have been working on this for a long time and even warned Sony not to release a Playstation VR accessory until this has been resolved lest it taint the VR experience for the public.
The Oculus Rift is brilliant and I'm sure these others will be equally good but they still aren't practical in the market until the simulator sickness problem is resolved.
Again you have a strange definition of "millisecond".
No, the approval time is a few hundred milliseconds. Where are you getting this 5 or 10 seconds from? It sends the details to the bank and the bank sends the response, that doesn't take 5 or 10 seconds.
A few milliseconds doesn't even cover the time it takes the checkout operator to press the button that sends the transaction to the EFT processor for you to insert your card (my country uses chip and pin, my current card doesn't even have a magstripe).
Read what was actually written rather than interpreting it as something else "Every transaction approval I've had for the last 15 years has been nearly instantaneous."
Lets not even consider those smaller stores who need to key in the price manually because the EFTPOS system isn't linked to the register
Yes, let's not since that wasn't what was being discussed.
Slashdot Mirror
Note that C++ isn't necessarily type safe either. It's not at all difficult to cast an object pointer to the wrong type and crash. It's no harder than it is in C.
Of course not, that should be pretty obvious to anybody that understands that C++ is a superset of C (clue is in the title), it wouldn't really be a superset then would it? But if you're interested in strict type safety then you wouldn't be doing static (c-style) casts and if you need to do type-casting you would be using C++'s dynamic_cast.
That distribution kicked in the patent clause of GPL. Thus estoppling all licensing claims their patents against Linux.. I.E. They authorized duplication, distribution, and use by their Employees/Sub-contractors/etc all of which are 3rd parties to M$ corporate patent port folio.
I don't think that's correct, what are you considering to be the definition of "distribution" in this context? If my employer installs software on their machines I don't need a license to it, nor do I have any claim to it because my employer is the licensee, not me, they didn't distribute it to me. Just like if I use my friend's TIVO I am not a licensee of the Linux kernel within it and he is not bound to supply me with the sourcecode should I request it because he has not distributed it to me.
Also you mentioned "duplication" and "use by their employees/sub-contractors" neither of which appears to have any relevance to the GPL so I'm not sure why you said that, is there a reason you believe that has some relevance here?
I keep hearing about Microsoft's Android patents but I still don't know what they are?
There's a link in here.
We've already seen what patents they are, they've been revealed in court and were made public by the Chinese government. The question is whether they are valid.
Wouldn't that mean Microsoft should be going after Google, and not Kyocera? Google produces the software, after all.
If that were how patents worked then I'm sure Microsoft would have shut down Linux long ago.
You don't actually believe it would cost them $79 (the RRP of the separate adapter) to integrate mini-displayport like you get on other offerings at that pricepoint do you? There's no real reason to remove features like that from this price-point except to try to up-sell the Pro models.
No innovation? There's nothing else like them in the market.
Since when is that the definition of "innovation"? A physical keyboard isn't innovative, a square screen isn't innovative.
OpenGL comes to mind
No, OpenGL (maintained by the Khronos Group) suffers from the problems that Mantle, Metal, DX12 and Vulkan (also maintained by the Khronos Group) exist to solve. Vulkan is the future of OpenGL.
If you want to use auto, go to a dynamically typed language.
No, you misunderstand what auto is, it has nothing to do with dynamic typing. It's type is deduced at compile-time, in fact you can find out its type with static analysis.
Necessary link http://xkcd.com/927/
How does that apply here? The yet-to-be-released Mantle is AMD-specific (or at least to get the most out of it you need GCN architecture which is AMD-only), Metal is Apple-specific, DirectX 12 is Microsoft-only (and thus far seems to be exclusive to Windows 10) so the only actual one that is a platform and vendor -agnostic specification here is Vulkan.
It strikes me that when you said "Vulkan would be the one to provide a compiler" that you may not have meant the one that compiles ahead-of-time or JIT compiler that compiles the bytecode to machine code and that perhaps you meant the compiler that creates the SPIR-V code. If that's the case then why would "Vulkan" or Khronos or the IHVs provide the compiler? This is a compiler that creates SPIR-V code from ... well pretty much any language, so why would "Vulkan" provide this compiler?
This would do exactly the opposite. You don't compile bytecode, you compile to byte code. The entire point is that byte code is interpreted at runtime.
So it isn't the opposite, a compiler (this may be a JIT compiler) most definitely is needed. And no, it is not necessarily interpreted at runtime, for example - and I'll use LLVM because since SPIR-V was based on LLVM - how do you think you get from C++ code to native code through Clang/LLVM? Yes bytecode is generated but it isn't interpreted at runtime. Just because there is a bytecode step doesn't mean it is interpretted at runtime, so what makes you believe Vulkan is going to use JIT compilation (rather than compiled ahead of time)?
Vulkan would be the one to provide a compiler.
How can "Vulkan" provide a compiler for every GPU architecture? You mean Khronos or the IHV implementation of Vulkan (which would of course be part of their vulkan driver). It makes sense for the driver for a particular architecture to provide the compiler for that architecture, where else would the compiler come from?
Carrying jumper cables is like carrying around a USB charging cable, but you don't carry around a spare charged car battery.
That is where the market has gone even for phones with replaceable batteries. Nobody is carrying around an actual spare battery anymore.
Especially when it means you have to charge the battery in the phone, swap that battery out with the flat one then charge that one in the phone. Unless you're also going to carry around a battery charger so you can charge your spare batteries without your phone. These days if you carry around a USB charging cable you're pretty set.
A good point if you live somewhere close to an Apple Store. Not everyone does.
Of course, if there was a Microsoft Store or a Samsung Store nearby I would probably consider them too...assuming they offer the same process (not sure if they do).
Need vs. want. The OP said he'd trade a bit more thickness for more battery life. Nothing you've said is an argument against that.
I know what he said, I'm not "arguing against" his assertion that he would happily have more thickness if it meant more battery life, I don't think he was lying when he said that.
In my experience, most people don't have/use them, and most people rely on the battery in their phone. It's not clear where your claim comes from - do most people you know have them?
Most people who use them. In my experience yes indeed most people rely on the battery in their phone and don't need additional batteries, much less to the point at which they are worried about the efficiency of their additional power source.
Uh, no. Those things are inefficient.
But they are efficient enough for most people.
Never mind that your battery is too weak or that you have a broken leg, crutches FTW!
When the choice is crutches or nothing I'd go crutches...until I get to a charger.
the point is i shouldnt have to rely on a 3rd party to do the job of my product.
But that product doesn't do what you want it to do but you can buy an accessory that does make it do what you want it to do. So either buy something different or buy this product and the accessory.
Anyway, many people want function over fashion, and would prefer a few mm thicker in exchange for a bigger battery.
Which is why there are battery booster packs. See the problem is solved for both groups of people with one phone design.
as for thinness, I dont want that! Gimme a phone 2x as thick as current top tier phones (or about 1/2 as thick as old nokia candy bar phones) and give me 4X the battery life. I want some heft in my phone. not zach morris phone thick, but old candy bar phone thick
Just get a battery boost pack. Mophie (and others im sure) are already announcing their products for these new samsung phones.
That's one of the biggest reasons I have an iPhone as my primary smartphone, I know I can just walk in and get it fixed or replaced on the spot.
VR, I see as having other problems. Oculus has had how long to release their VR stuff? It's gotten long enough that the only product is the Galaxy Gear, while plenty of people are using it for development and research.
The problem is the simulator sickness effect that people get when the messages from your eyes don't match what your inner ear is telling your brain. Oculus have been working on this for a long time and even warned Sony not to release a Playstation VR accessory until this has been resolved lest it taint the VR experience for the public.
The Oculus Rift is brilliant and I'm sure these others will be equally good but they still aren't practical in the market until the simulator sickness problem is resolved.
Again you have a strange definition of "millisecond".
No, the approval time is a few hundred milliseconds. Where are you getting this 5 or 10 seconds from? It sends the details to the bank and the bank sends the response, that doesn't take 5 or 10 seconds.
A few milliseconds doesn't even cover the time it takes the checkout operator to press the button that sends the transaction to the EFT processor for you to insert your card (my country uses chip and pin, my current card doesn't even have a magstripe).
Read what was actually written rather than interpreting it as something else "Every transaction approval I've had for the last 15 years has been nearly instantaneous."
Lets not even consider those smaller stores who need to key in the price manually because the EFTPOS system isn't linked to the register
Yes, let's not since that wasn't what was being discussed.