Nitpick: Qt is not a "custom drawn toolkit", it is a "custom behavior apart from drawing" toolkit. The drawing into a bitmap is done by platform libraries, that's why you can't get OS X look if you run Qt on Windows.
In a rebreather system, you need to scrub CO2. Instead of using a finite-life chemical scrubber, you can use the CO2 and water to make methane and oxygen. All of water's *and* CO2's oxygen is returned back into the system that way. Basically, the CO2+H2O process is the only one that doesn't require chemical consumables (other than for an optional chemical thermal energy source). It's the only thing that can, realistically work "infinitely long" only when provided with energy and nothing else. Even if the electrical power has to be provided by a tether, it's still much less cumbersome than having fluids going through the tether.
Microsoft themselves doesn't use what passes for "native widgets" on Windows in any new development. Seriously. Only their legacy code with Windows 95/NT roots (explorer, old control panel items, legacy utilities) still uses it. There's really no reason to use native widgets on Windows. WPF is the new native, for better or worse, and Qt does a similar thing in Qt Quick 2 controls. Qt's widgets module does as well, although the renderer is still CPU-bound, not GPU-bound. If you really need to use native controls, you can, from within Qt, but what for?
I don't even know what "updates" to native widgets would you care for. Microsoft hasn't (and can't) alter their legacy controls functionality much if at all, and as far as look and feel goes, Qt has to be updated for new major Windows releases anyway. That's not new, and hardly a problem - someone else does this work:) By the way, Qt still uses native APIs to style the controls, that's why you don't get OS X or XP & newer look-and-feel with Qt on anything but the very platform it runs on. Heck, you can't get XP look-and-feel with Qt on anything but XP, in fact. That's also why, if you attempt to use stylesheets to restyle the controls proper, you lose all of the native style, since it's all-or-nothing - just as you can't programmatically change the thickness of a button's border on Windows XP, neither can you on OS X.
Qt 5 does allow you to use signals/slots without that information as well.
Not quite. Qt 5's templated QObject::connect enforces that the objects in question are valid QObjects and a signal-method call still needs the information generated by moc for the target object. This is necessary for the thread safety, at least - you don't want a random target object disappearing under you, as it would if it were non-QObject. The internal implementation also assumes that calls to slots have a valid method index, and that comes from moc-generated metadata.
If you want to call a method on a random non-QObject, you have to wrap it in a lambda, otherwise it won't compile. You also better be using a shared smart pointer, otherwise your code will have undefined behavior (likely it'll crash) as soon as the target object ceases to exist.
QSharedPointer<NotAQObject> p(foo);// foo better be a shared pointer, too! connect(src, &SrcClass::aSignal, [=](int arg0){ p->member(arg0); });
The copy of the shared pointer embedded in the lambda-generated functor will be destroyed in src's destructor.
Yep. The best the C++ standards folk has come up so far is a bunch of proposals that try to get some of moc's functionality into C++. Normal people, who have some perspective, would call moc visionary and ahead of the time (if Common LISP is ignored, of course). Clueless people, well, remain clueless. It makes me a bit happy that I could, if I were looking for work, sell myself to the employers with full knowledge that a large bunch of behind-the-times folk are proclaiming that staying less productive is somehow better. Good for me, bad for the GP:) The educator in me cringes, the employee side of me smiles.
You do know that Qt has had accessibility support for quite a while now, in both Qt 4 and Qt 5? You do realize that WPF itself is not using the native winapi controls, and is peddled as the "new native way" of doing controls on Windows? You do realize that Qt does way more beyond mere native-looking-skinning of controls? It does actually re-implement platform-specific behaviors on a lot of controls, often in ways that are much simpler to code for than whatever native legacy boondoogle of an API someone at MS or Apple has conceived?
There is something to be said for having uniform principles for the design of an application framework, and Qt is reasonably good in that department. My experience is that the non-nativeness of Qt-provided controls is something that is hard to notice if it can be noticed at all, if the application developer has done their homework.
There is no way other than having a meta-platform that can abstract things away from the physical platform it runs on. A platform is not merely the UI. If you really want to write cross-platform code that has native-API-using GUIs, you'll still find yourself having to use a platform abstraction for all the non-GUI stuff like events, threads, containers, strings/internationalization, etc. Even if this abstraction is provided by the standard C++ library, it's still an abstraction, and you can still choose who provides it - compiler vendors are just one in a crowd here.
There is a very good reason that Qt has its own object model etc. It's because all those things, done natively, are full of inconsistencies, bugs you have to work around, and other shortcomings that have you, the brave cross-platform coder, having to re-do things again and again.
No, using Qt core and networking for non-GUI platform abstraction is no different from using Boost. Just that with Qt you have the option of using the gui stuff, and platform-specific extras, and qt quick, and a whole bunch of other goodies that you get nowhere else.
There is nothing wrong, of course, with doing the core of your application using Qt's core and networking modules, and doing the UI natively. Often, though, you'll find that the native way will not give you as many advantages as you thought you had.
Never mind that even some "native" ways of doing things do it exactly the way Qt does it. For example, WPF on.net is not using native legacy winapi windows controls, since they render everything using GPU acceleration and conceptually are much closer to Qt Quick 2 controls. So even your own "stay native" argument flies in the face of what the "native" platform vendors are themselves doing!!
Qt 5 and C++11 play ball together, there's much less of boost needed beyond application-specific stuff if you use Qt. I'd suggest you have a look at Qt, it provides you with a whole lot of functionality. It'll cost the "boost guys" as much time as it cost Qt folks to come up with Qt: in other words, what you ask for is completely unrealistic unless you've just won a lottery and have some money to burn on developers.
Never mind that boost by itself still can't provide what Qt has provided for a long, long time now: introspection into the methods available on an instrumented object. It also has a metatype system that lets you construct and destruct instances of registered types, completely under program control and without having to sprinkle type-specific knowledge all across the project. This makes for much easier integration with scripting languages, for example.
moc exists not because C++ is a shitpile, it simply takes some manual, boring boilerplate out of the code you write. Boilerplate that's all over code that uses GTK, by the way. Code generators exist to make you more productive. Some platforms even go as far as giving you a compile-time code generation support: C++ has a rather limited, functional-style metaprogramming. In LISP you get the full power of the language available at compile time, and to me that's still unmatched by any other mainstream platform.
You're someone who doesn't value your own productivity if you resort to calling code generators hacks. It's not a hack, it's something that lets the machine do the work a machine can do, instead of forcing a human intervention in generating introspection data. Calling moc a hack is like calling a lexer or parser generator a hack. Now I'm not commenting on the quality of the moc code itself, just on the general approach of leveraging computers in all aspects of software development, not merely to run the resulting machine code.
The pure-C api is what makes it harder to use, because you have humans doing the work otherwise done by a C++ compiler. If that's not retarded, I don't know what is.
Do you even know what "existing toolkits" looked like at the time? They were solid crap. I'm no fan of GTK, but man, reuse of platform-provided functionality in a multi-platform toolkit is usually something you do at the beginning and then quickly backpedal on. There is a very good technical reason why Qt comes with its own raster rendering code, its own event loop, its own containers and atomics, and a host of other things: the platform stuff, if present, is broken in its own way on each platform Qt runs on. Or, if it's not broken, the standards the platform libraries follow simply leave too much to undefined- or implementation-defined behavior to, you know, actually use in practice. For C++ standard library that may be a bit of a less of a problem with modern compilers, but remember that even Qt 4 has to compile on some very broken compilers and very quirky platforms.
Never mind that you're replacing a simple tank with something that's way, way more likely to malfunction. Tanks generally either work or blow up. We've got it figured out quite well how not to have them blow up, so they generally just work. I don't even think that mechanical tank failure is worth even talking about in diving. It practically never happens. It's so rare that a whole lot of insurers would be probably very happy to insure you for a whole lot of money just for that possibility, and it would be a cheap policy. They'd think they are stealing from you.
Once one pulls their head out of their ass and you know, looks at a fucking real rebreather, one realizes that the source of oxygen is not even nearly a problem. There, solved it for you. The majority of comments under this article are just completely depressing because they indicate that most people here firmly believe in fairytales and can't even look out of their window for crying out loud. Don't they teach anything in schools these days??
The working prototype is called a scuba rebreather, and the oxygen tank in those rebreathers is not a limitation of any sort. At the current technology level of rebreathers, it simply makes no sense to optimize the source of oxygen. It's like optimizing machine code of an exponential algorithm that runs on Ns in the millions.
For any sort of oxygen-from-the-water system to have a flying chance in hell, we need to improve the rebreather technology first. This guy simply doesn't have a fucking clue about the area he has barged in.
A design concept is for something that has a flying chance in hell of being made. This thing is too small even if we had some quite exotic technologies at hand. It's so bogus it's depressing to anyone who hasn't got their head firmly up their ass when it comes to reality of the world we live in.
Why does everyone and their puppy call it an interesting concept? It's fiction, pure and simple, and not interesting at that. It's old boring stuff, rehashed in movies, in books, dreams, and whatnot. It doesn't deserve front page exposure anywhere.
I've seen a prototype multi-tank system that adjusts the mixture as the dive progresses, giving zero-decompression-time when a certain dive profile is followed, for a 50m working depth technical dive. But that's quite cutting edge and still carries somewhat higher risk than a system with a fixed mixture. The less components, the better the likely outcome.
Actually his statements suggest that it's quite possible, just not in the form-factor claimed
A rebreather uses oxygen from a tank. You suggest replacing a simple tank with whatever this fictional thing is. Does that make any sense to you? Because to me that sounds like something a lunatic might say. Reality -dig it.
It's not a concept. It's fiction. Get over it. Don't pretend otherwise. Fiction, and boring fiction at that. Don't call it anything else. Repeat: fiction, boring.
Slashdot Mirror
Nitpick: Qt is not a "custom drawn toolkit", it is a "custom behavior apart from drawing" toolkit. The drawing into a bitmap is done by platform libraries, that's why you can't get OS X look if you run Qt on Windows.
In a rebreather system, you need to scrub CO2. Instead of using a finite-life chemical scrubber, you can use the CO2 and water to make methane and oxygen. All of water's *and* CO2's oxygen is returned back into the system that way. Basically, the CO2+H2O process is the only one that doesn't require chemical consumables (other than for an optional chemical thermal energy source). It's the only thing that can, realistically work "infinitely long" only when provided with energy and nothing else. Even if the electrical power has to be provided by a tether, it's still much less cumbersome than having fluids going through the tether.
Microsoft themselves doesn't use what passes for "native widgets" on Windows in any new development. Seriously. Only their legacy code with Windows 95/NT roots (explorer, old control panel items, legacy utilities) still uses it. There's really no reason to use native widgets on Windows. WPF is the new native, for better or worse, and Qt does a similar thing in Qt Quick 2 controls. Qt's widgets module does as well, although the renderer is still CPU-bound, not GPU-bound. If you really need to use native controls, you can, from within Qt, but what for?
I don't even know what "updates" to native widgets would you care for. Microsoft hasn't (and can't) alter their legacy controls functionality much if at all, and as far as look and feel goes, Qt has to be updated for new major Windows releases anyway. That's not new, and hardly a problem - someone else does this work :) By the way, Qt still uses native APIs to style the controls, that's why you don't get OS X or XP & newer look-and-feel with Qt on anything but the very platform it runs on. Heck, you can't get XP look-and-feel with Qt on anything but XP, in fact. That's also why, if you attempt to use stylesheets to restyle the controls proper, you lose all of the native style, since it's all-or-nothing - just as you can't programmatically change the thickness of a button's border on Windows XP, neither can you on OS X.
Qt 5 does allow you to use signals/slots without that information as well.
Not quite. Qt 5's templated QObject::connect enforces that the objects in question are valid QObjects and a signal-method call still needs the information generated by moc for the target object. This is necessary for the thread safety, at least - you don't want a random target object disappearing under you, as it would if it were non-QObject. The internal implementation also assumes that calls to slots have a valid method index, and that comes from moc-generated metadata.
If you want to call a method on a random non-QObject, you have to wrap it in a lambda, otherwise it won't compile. You also better be using a shared smart pointer, otherwise your code will have undefined behavior (likely it'll crash) as soon as the target object ceases to exist.
QSharedPointer<NotAQObject> p(foo); // foo better be a shared pointer, too!
connect(src, &SrcClass::aSignal, [=](int arg0){ p->member(arg0); });
The copy of the shared pointer embedded in the lambda-generated functor will be destroyed in src's destructor.
Yep. The best the C++ standards folk has come up so far is a bunch of proposals that try to get some of moc's functionality into C++. Normal people, who have some perspective, would call moc visionary and ahead of the time (if Common LISP is ignored, of course). Clueless people, well, remain clueless. It makes me a bit happy that I could, if I were looking for work, sell myself to the employers with full knowledge that a large bunch of behind-the-times folk are proclaiming that staying less productive is somehow better. Good for me, bad for the GP :) The educator in me cringes, the employee side of me smiles.
You really should keep your mouth shut if you neither understand what C++ can and cannot do, and what moc actually does.
Basically, Qt is doing controls on Windows the same way Microsoft is doing controls on Windows these days. So stop with the FUD.
You do know that Qt has had accessibility support for quite a while now, in both Qt 4 and Qt 5? You do realize that WPF itself is not using the native winapi controls, and is peddled as the "new native way" of doing controls on Windows? You do realize that Qt does way more beyond mere native-looking-skinning of controls? It does actually re-implement platform-specific behaviors on a lot of controls, often in ways that are much simpler to code for than whatever native legacy boondoogle of an API someone at MS or Apple has conceived?
There is something to be said for having uniform principles for the design of an application framework, and Qt is reasonably good in that department. My experience is that the non-nativeness of Qt-provided controls is something that is hard to notice if it can be noticed at all, if the application developer has done their homework.
There is no way other than having a meta-platform that can abstract things away from the physical platform it runs on. A platform is not merely the UI. If you really want to write cross-platform code that has native-API-using GUIs, you'll still find yourself having to use a platform abstraction for all the non-GUI stuff like events, threads, containers, strings/internationalization, etc. Even if this abstraction is provided by the standard C++ library, it's still an abstraction, and you can still choose who provides it - compiler vendors are just one in a crowd here.
There is a very good reason that Qt has its own object model etc. It's because all those things, done natively, are full of inconsistencies, bugs you have to work around, and other shortcomings that have you, the brave cross-platform coder, having to re-do things again and again.
No, using Qt core and networking for non-GUI platform abstraction is no different from using Boost. Just that with Qt you have the option of using the gui stuff, and platform-specific extras, and qt quick, and a whole bunch of other goodies that you get nowhere else.
There is nothing wrong, of course, with doing the core of your application using Qt's core and networking modules, and doing the UI natively. Often, though, you'll find that the native way will not give you as many advantages as you thought you had.
Never mind that even some "native" ways of doing things do it exactly the way Qt does it. For example, WPF on .net is not using native legacy winapi windows controls, since they render everything using GPU acceleration and conceptually are much closer to Qt Quick 2 controls. So even your own "stay native" argument flies in the face of what the "native" platform vendors are themselves doing!!
Qt 5 and C++11 play ball together, there's much less of boost needed beyond application-specific stuff if you use Qt. I'd suggest you have a look at Qt, it provides you with a whole lot of functionality. It'll cost the "boost guys" as much time as it cost Qt folks to come up with Qt: in other words, what you ask for is completely unrealistic unless you've just won a lottery and have some money to burn on developers.
Never mind that boost by itself still can't provide what Qt has provided for a long, long time now: introspection into the methods available on an instrumented object. It also has a metatype system that lets you construct and destruct instances of registered types, completely under program control and without having to sprinkle type-specific knowledge all across the project. This makes for much easier integration with scripting languages, for example.
moc exists not because C++ is a shitpile, it simply takes some manual, boring boilerplate out of the code you write. Boilerplate that's all over code that uses GTK, by the way. Code generators exist to make you more productive. Some platforms even go as far as giving you a compile-time code generation support: C++ has a rather limited, functional-style metaprogramming. In LISP you get the full power of the language available at compile time, and to me that's still unmatched by any other mainstream platform.
You're someone who doesn't value your own productivity if you resort to calling code generators hacks. It's not a hack, it's something that lets the machine do the work a machine can do, instead of forcing a human intervention in generating introspection data. Calling moc a hack is like calling a lexer or parser generator a hack. Now I'm not commenting on the quality of the moc code itself, just on the general approach of leveraging computers in all aspects of software development, not merely to run the resulting machine code.
The pure-C api is what makes it harder to use, because you have humans doing the work otherwise done by a C++ compiler. If that's not retarded, I don't know what is.
Do you even know what "existing toolkits" looked like at the time? They were solid crap. I'm no fan of GTK, but man, reuse of platform-provided functionality in a multi-platform toolkit is usually something you do at the beginning and then quickly backpedal on. There is a very good technical reason why Qt comes with its own raster rendering code, its own event loop, its own containers and atomics, and a host of other things: the platform stuff, if present, is broken in its own way on each platform Qt runs on. Or, if it's not broken, the standards the platform libraries follow simply leave too much to undefined- or implementation-defined behavior to, you know, actually use in practice. For C++ standard library that may be a bit of a less of a problem with modern compilers, but remember that even Qt 4 has to compile on some very broken compilers and very quirky platforms.
Yeah, a site full of completely impractical stuff, even if it was possible.
It's all hype and fantasy. The battery too. What made you think otherwise?
IIRC, tanks don't leak. It's the fittings and all the other stuff. I can't see a leaking tank that isn't on its way to explode any second now.
Never mind that you're replacing a simple tank with something that's way, way more likely to malfunction. Tanks generally either work or blow up. We've got it figured out quite well how not to have them blow up, so they generally just work. I don't even think that mechanical tank failure is worth even talking about in diving. It practically never happens. It's so rare that a whole lot of insurers would be probably very happy to insure you for a whole lot of money just for that possibility, and it would be a cheap policy. They'd think they are stealing from you.
Once one pulls their head out of their ass and you know, looks at a fucking real rebreather, one realizes that the source of oxygen is not even nearly a problem. There, solved it for you. The majority of comments under this article are just completely depressing because they indicate that most people here firmly believe in fairytales and can't even look out of their window for crying out loud. Don't they teach anything in schools these days??
The working prototype is called a scuba rebreather, and the oxygen tank in those rebreathers is not a limitation of any sort. At the current technology level of rebreathers, it simply makes no sense to optimize the source of oxygen. It's like optimizing machine code of an exponential algorithm that runs on Ns in the millions.
For any sort of oxygen-from-the-water system to have a flying chance in hell, we need to improve the rebreather technology first. This guy simply doesn't have a fucking clue about the area he has barged in.
A design concept is for something that has a flying chance in hell of being made. This thing is too small even if we had some quite exotic technologies at hand. It's so bogus it's depressing to anyone who hasn't got their head firmly up their ass when it comes to reality of the world we live in.
Why does everyone and their puppy call it an interesting concept? It's fiction, pure and simple, and not interesting at that. It's old boring stuff, rehashed in movies, in books, dreams, and whatnot. It doesn't deserve front page exposure anywhere.
I've seen a prototype multi-tank system that adjusts the mixture as the dive progresses, giving zero-decompression-time when a certain dive profile is followed, for a 50m working depth technical dive. But that's quite cutting edge and still carries somewhat higher risk than a system with a fixed mixture. The less components, the better the likely outcome.
Actually his statements suggest that it's quite possible, just not in the form-factor claimed
A rebreather uses oxygen from a tank. You suggest replacing a simple tank with whatever this fictional thing is. Does that make any sense to you? Because to me that sounds like something a lunatic might say. Reality -dig it.
It's not a concept. It's fiction. Get over it. Don't pretend otherwise. Fiction, and boring fiction at that. Don't call it anything else. Repeat: fiction, boring.