The Sunset of C and C++
blog.biicode.com
The Sunset of C and C++
1–10 of 16 posts
Re: The Sunset of C and C++
#2Some of the worries the author puts forward are warranted. Here's something that might help: http://ccodearchive.net/
Re: The Sunset of C and C++
#3Some of the worries the author puts forward are warranted. Here's something that might help: http://ccodearchive.net/
Interesting project, yes, I also like the idea of having a common consensus for generating config.h files. Any idea why it is just C? Cause extending it to C++ seems trivial, and cannot find the rational about this.
IMHO, most dev tools have practically no real need to distinguish between C and C++
Re: The Sunset of C and C++
#4Microsoft might be cooking some Midori into C# 7 as well.
Re: The Sunset of C and C++
#5I think the point here is that depending on Boost (Or similar libraries) should not be a problem.
Consider python's pip. Bootstrapping a python codebase is simple, just run pip install -r requirements_file.txt. The bootstrapping itself may take some time, but it's automatic and simple to do.
We need exactly the same for C and C++. Bootstrapping huge C/C++ libs will never be done in a couple of minutes, compiling those take time. But the process of triggering that bootstrap can (and should) be simple and natural (I think we achieved that with boost on biicode. Of course everything can be improved). That's what a C/C++ dependency manager means. Forget to elide large compile times, that's a matter of how the language works. But let's try to make gluing C/C++ libraries together an easy to "call" task.
Re: The Sunset of C and C++
#6I think the point here is that depending on Boost (Or similar libraries) should not be a problem. Consider python's pip. Bootstrapping a python codebase is simple, just run pip install -r requirements_file.txt. The bootstrapping itself may take some time, but it's automatic and simple to do. We need exactly the same for C and C++. Bootstrapping huge C/C++ libs will never be done in a couple of minutes, compiling thos…
I partly disagree. Depending on boost, as-is, is still a problem from the point of view of engineering, and the example in the post is relevant. It shouldnt be necessary to retrieve hundreds of megabytes for implementing some serial-port functionality. The problem, of course it is not boost fault, or boost developers. Boost is fantastic. The problem is that is has been developed without environment tools like cargo, pip, maven, or whatever. If we had something similar for C and/or C++ before boost was developed, I'd bet we had a SerialPort lib, independent, portable, efficient, focused and well tested, and BoostAsio would just depend on it, instead of developing inside that logic.
Totally agree about that we need something as pip for C and C++, I think it is the point of the post.
Re: The Sunset of C and C++
#7I think the point here is that depending on Boost (Or similar libraries) should not be a problem. Consider python's pip. Bootstrapping a python codebase is simple, just run pip install -r requirements_file.txt. The bootstrapping itself may take some time, but it's automatic and simple to do. We need exactly the same for C and C++. Bootstrapping huge C/C++ libs will never be done in a couple of minutes, compiling thos…
I partly disagree. Depending on boost, as-is, is still a problem from the point of view of engineering, and the example in the post is relevant. It shouldnt be necessary to retrieve hundreds of megabytes for implementing some serial-port functionality. The problem, of course it is not boost fault, or boost developers. Boost is fantastic. The problem is that is has been developed without environment tools like cargo,…
> If we had something similar for C and/or C++ before boost was developed, I'd bet we had a SerialPort lib, independent, portable, efficient, focused and well tested, and BoostAsio would just depend on it, instead of developing inside that logic.
That's backwards. A SerialPort library would depend on Asio since it defines sync and async streams and the utilities built around that. It seems bad design for a SerialPort library to reimplement those basic utilities.
A dependency manager allows for finer modularity. So instead, Asio could be split into multiple libraries: Asio.Core, Asio.Serial, Asio.Network, etc. Its ok we have to bring in two smaller libraries instead of one large libary, since we have a dependency manager to handle this for us.
Also, a lack of a dependency manager in C++ has lead to developing of large monolithic libraries. So instead of managing dependencies, the library gives you everything plus the kitchen sink, so the user won't need to use another library. Of course, this is not scalable.
The other side-effect from a lack of a dependency manager in C++ is the developing of unnecessary header-only libraries(like Boost.Signals2). This just slows down compilation.
A real viable dependency manager in C++ will be a game changer, and recently. there is a lots of serious talk about it. In fact, there are like 3 difference talks that are directly related to dependency managing at C++Now 2015.
Re: The Sunset of C and C++
#8BTW, Asio can be used without needing boost. In fact, the non-boost version is the actual maintained version. A script is applied to boostify it. It would be nice if Asio could be added to biicode.
Re: The Sunset of C and C++
#9Some of the worries the author puts forward are warranted. Here's something that might help: http://ccodearchive.net/
Interesting project, yes, I also like the idea of having a common consensus for generating config.h files. Any idea why it is just C? Cause extending it to C++ seems trivial, and cannot find the rational about this. IMHO, most dev tools have practically no real need to distinguish between C and C++
>Any idea why it is just C?
I'm not exactly sure, but I believe it's mostly due to the author's[1] background.
Re: The Sunset of C and C++
#10Earlier quoted context omitted.
I partly disagree. Depending on boost, as-is, is still a problem from the point of view of engineering, and the example in the post is relevant. It shouldnt be necessary to retrieve hundreds of megabytes for implementing some serial-port functionality. The problem, of course it is not boost fault, or boost developers. Boost is fantastic. The problem is that is has been developed without environment tools like cargo,…
> If we had something similar for C and/or C++ before boost was developed, I'd bet we had a SerialPort lib, independent, portable, efficient, focused and well tested, and BoostAsio would just depend on it, instead of developing inside that logic. That's backwards. A SerialPort library would depend on Asio since it defines sync and async streams and the utilities built around that. It seems bad design for a SerialPort…
> That's backwards. A SerialPort library would depend on Asio since it defines sync and async streams and the utilities built around that. It seems bad design for a SerialPort library to reimplement those basic utilities.
IMO, the first layer could be a proper abstraction of the basic OS serial port functionality, without any notion of sync/async issues. Well, it will typically be sync. Keep it simple, it could be maybe just 2-6 files, depending on the approach to tackle different OSs. A common interface for open, config (baud, and the like), send, receive bytes, close. Lets call it SerialPortHW
Then, sync and async streams can be defined, or at least their interfaces and common functionality, which would be independent on any notion of physical transportation as SerialPortHW. Les call it AsyncStreams. In no way SerialPortHW has to depend on AsyncStreams (SerialPortHW->AsyncStreams), and the opposite is the same. They do not read logical, the concept "SerialPortHW" does not have implicit a requirement to know anything about async issues. If a function is slow to send bytes over the wire, it is slow, so what. It is fully functional, well defined, stand-alone and independent functionality that deserves its own entity.
Then, if the async serial port funcionality is desired, another component, lets call it AsyncSerialPort can be built composing/deriving AsyncStreams and SerialPortHW.
Sorry for the long response, I love arguing about SW design :)