3 ms·

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

by pfultz2 12y ago

> 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 12y ago
> 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 12y ago
  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 12y ago
    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 12y ago
      > 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).

by pfultz2 12y ago

drodri 12y ago

> 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 12y ago
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 12y ago
  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 12y ago
    > 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).