

The Sunset of C and C++ - MordodeMaru
http://blog.biicode.com/c-cpp-biggest-threats-modern-ecosystem/

======
Manu343726
I 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.

~~~
drodri
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.

~~~
pfultz2
> 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.

~~~
drodri
> 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 :)

~~~
pfultz2
Well since Asio is generic there is no coupling between the interface and
implementation. However, from a user perspective, they will most likely use
both(even its just for sync reading), since Asio provides other utilities such
as buffered reading and reading until a certain character is found.

~~~
drodri
The likelyhood of using both is not enough reason to embed them in the same SW
component.

Concerns have to be decoupled as mush as possible. It is even more likely that
the user will use some serialization, and there is no point at all to
implement serialization inside the library! Because then, also it is likely
that the user want to make some CRCs to check message integrity, or cypher de
message so lets embed such funcionality in the library too :)

I have developed and used code many times using a serial port (robotics,
industry), and in many occasions such extra async framework or the streams are
not used. I know they are quite convenient and useful for many many cases, but
it is still a separate concern than implementing the low level "hardware"
comunication, and thus deserve decoupling it its own component, exactly the
same as serialization. In that way, when using Async for network sockets, the
SerialPortHW concept wouldnt be involved at all, it would be in a different
concept not included in the current project.

~~~
pfultz2
> It is even more likely that the user will use some serialization

Serialization is beyond the scope of what I am talking about. I am talking
about reading bytes from a serial port.

> In that way, when using Async for network sockets, the SerialPortHW concept
> wouldnt be involved at all

But that is my whole point about Asio being split into smaller libraries such
as Asio.Core, Asio.Network, and Asio.SerialPort. So you can use
Asio.SerialPort without needing Asio.Network.

> in many occasions such extra async framework or the streams are not used.

You didn't read and write bytes to the serial port? What did you use it for?

> it would be in a different concept not included in the current project.

Its important for the library to implement the same "concepts"(or type
requirements) for better consistency and composability(the only exception is
iostreams which is horrible for both usability and implementations).

~~~
drodri
> But that is my whole point about Asio being split into smaller libraries
> such as Asio.Core, Asio.Network, and Asio.SerialPort. So you can use
> Asio.SerialPort without needing Asio.Network

Yes, totally agree about it. And I think I see your point now, agree also that
libraries must implement concepts in a consistent way, and streams are indeed
the way to go for reading/writing bytes. Maybe, what I am uncorfortable about
is having that Asio.SerialPort explicitely coupled with async stuff like
promises/futures.

Put it other way round, I think maybe the Asio.SerialPort should actually be
something like HW.SerialPort, and this define a very low level library that
acts just as an API to the HW, thus no promises here, as the OS does not
handle that. Other languages like Node, Python could actually use and wrap
this library to access the HW, and built their own async features. Then, it is
perfect to have an Asio.SerialPort that builts both sync and async streams,
using in the low level the HW.SerialPort. Maybe something in the line of:
[https://github.com/wjwwood/serial](https://github.com/wjwwood/serial), but
maybe with a more C++ style std::strings, streams (sync). Not sure, anyway, I
will review my ideas, maybe I have to review my concepts about async and in
which part of the stack should they be implemented, lets think about it.

------
pfultz2
BTW, 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.

------
throwaway829086
Some of the worries the author puts forward are warranted. Here's something
that might help: [http://ccodearchive.net/](http://ccodearchive.net/)

~~~
drodri
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++

~~~
throwaway829086
>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.

[1] -
[https://en.wikipedia.org/wiki/Rusty_Russell](https://en.wikipedia.org/wiki/Rusty_Russell)

------
M8
Microsoft might be cooking some Midori into C# 7 as well.

------
pdelapuente
Very interesting

