Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Sunset of C and C++

blog.biicode.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: The Sunset of C and C++

#11

Post by pfultz2 »

drodri wrote: post #10
pfultz2 wrote: post #7

Earlier quoted context omitted.

> 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 ma…

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.

Re: The Sunset of C and C++

#12

Post by drodri »

pfultz2 wrote: post #11
drodri wrote: post #10

Earlier quoted context omitted.

> 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 ma…

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.

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.

Re: The Sunset of C and C++

#13

Post by pfultz2 »

drodri wrote: post #12
pfultz2 wrote: post #11

Earlier quoted context omitted.

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.

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…

> 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).

Re: The Sunset of C and C++

#16

Post by drodri »

pfultz2 wrote: post #13
drodri wrote: post #12

Earlier quoted context omitted.

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…

> 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…

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

Post reply on HN