From: Nelson, E. - 2 <eri...@ba...> - 2010-01-22 19:03:48
|
Thanks for the help... It's working now, and I'm playing with it some more. I'm not sure if it matters, but in connection.hpp, in the connection constructor, there's a bit of code like try { socket_.set_option(tcp::no_delay(true)); // Don't delay writing } catch (system::system_error & e) { handler_.log(e.what()); } And the set_option call *always* seems to throw boost::asio::error::bad_descriptor. Not sure if it matters. One other thing I noticed (and don't personally care about) is the cpp-netlib coding style, like curly brace placement. I'm not sure if there are boost coding guidelines or not, or if they are enforced or not, but cpp-netlib looks a little different than other boost source code. Again, I'm perfectly happy with however it is, but if the goal is to move cpp-netlib into boost and boost cares (I don't know that either of those assumptions are true), it's probably easier to start doing it "the boost way" sooner rather than later. Thanks Erik |
From: Glyn M. <gly...@gm...> - 2010-01-22 19:20:47
|
Hi Erik, 2010/1/22 Nelson, Erik - 2 <eri...@ba...> > Thanks for the help... It's working now, and I'm playing with it some > more. > > I'm not sure if it matters, but in connection.hpp, in the connection > constructor, there's a bit of code like > > try { > socket_.set_option(tcp::no_delay(true)); // Don't delay > writing > } catch (system::system_error & e) { > handler_.log(e.what()); > } > > And the set_option call *always* seems to throw > boost::asio::error::bad_descriptor. Not sure if it matters. > > One other thing I noticed (and don't personally care about) is the > cpp-netlib coding style, like curly brace placement. I'm not sure if > there are boost coding guidelines or not, or if they are enforced or > not, but cpp-netlib looks a little different than other boost source > code. Again, I'm perfectly happy with however it is, but if the goal is > to move cpp-netlib into boost and boost cares (I don't know that either > of those assumptions are true), it's probably easier to start doing it > "the boost way" sooner rather than later. > > There isn't really a "boost way", I think, the closest it gets is in the guidelines: http://www.boost.org/development/requirements.html But that stops short of specifying how the source code should be formatted, but focuses on portability and license issues. Different boost libraries seem to be formatted differently, depending on each author's preferences. The coding style sometimes bothers me too (not so much curly braces placement as indenting), but I get that all the time when I look at other people's code ;) If you think its a going to be a hindrance then perhaps we could open a discussion about guidelines. Maybe consistency would be important at least, because this project could potentially be large and the nature of the design doesn't lend itself to highly readable code. Glyn |
From: Dean M. B. <mik...@gm...> - 2010-01-23 08:25:23
|
On Sat, Jan 23, 2010 at 3:20 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Erik, > > 2010/1/22 Nelson, Erik - 2 <eri...@ba...> >> >> Thanks for the help... It's working now, and I'm playing with it some >> more. >> >> I'm not sure if it matters, but in connection.hpp, in the connection >> constructor, there's a bit of code like >> >> try { >> socket_.set_option(tcp::no_delay(true)); // Don't delay >> writing >> } catch (system::system_error & e) { >> handler_.log(e.what()); >> } >> >> And the set_option call *always* seems to throw >> boost::asio::error::bad_descriptor. Not sure if it matters. >> This actually matters and is a bug. Thanks for reporting it, it's issue #5 on GitHub now. It would be cool if we used the Github issue tracker instead for things like these. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-22 19:42:25
|
Glyn Matthews wrote: > The coding style sometimes bothers me too (not so much curly braces placement as indenting), > but I get that all the time when I look at other people's code ;) If you think its a going to be a hindrance > then perhaps we could open a discussion about guidelines. > Maybe consistency would be important at least, because this project could potentially > be large and the nature of the design doesn't lend itself to highly readable code. I'm with you- I only like my own code. And if I haven't read my own code for a while, then I don't even like my own code. :) I don't have any interest in a discussion... you guys are doing the work. My parents always told me to never complain when someone else is working and I am benefitting. Erik |
From: Glyn M. <gly...@gm...> - 2010-01-23 11:42:26
|
On 22 January 2010 20:33, Nelson, Erik - 2 <eri...@ba...>wrote: > Glyn Matthews wrote: > > > The coding style sometimes bothers me too (not so much curly braces > placement as indenting), > > but I get that all the time when I look at other people's code ;) If > you think its a going to be a hindrance > > then perhaps we could open a discussion about guidelines. > > > Maybe consistency would be important at least, because this project > could potentially > > be large and the nature of the design doesn't lend itself to highly > readable code. > > I'm with you- I only like my own code. And if I haven't read my own code > for a while, then I don't even like my own code. :) > > I don't have any interest in a discussion... you guys are doing the work. > My parents always told me to never complain when someone else is working and > I am benefitting. > Perhaps, but I still think that the point you bring up is a valid one. I added a wiki page @ http://wiki.github.com/glynos/cpp-netlib/c-network-library-style-guidelinesin any case. This will eventually cover some broad aspects such as directory/namespace structure and stuff about tags/traits and concepts where consistency matters. G |
From: Dean M. B. <mik...@gm...> - 2010-01-23 15:06:39
|
On Sat, Jan 23, 2010 at 7:42 PM, Glyn Matthews <gly...@gm...> wrote: > > > Perhaps, but I still think that the point you bring up is a valid one. > > I added a wiki page @ > http://wiki.github.com/glynos/cpp-netlib/c-network-library-style-guidelines > in any case. This will eventually cover some broad aspects such as > directory/namespace structure and stuff about tags/traits and concepts where > consistency matters. > This makes sense and somehow I feel like I should be the one writing this document. ;) Or at least I should be leading the discussion. :D Up to this point I haven't found the need to write down the conventions I use in the code though so it would be good to follow a set of guidelines so that we can somehow bring some order into the "chaos". :D Thanks for doing this Glyn! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-25 19:38:11
|
Dean Michael Berris wrote: > It would be cool if we used the Github issue tracker instead for > things like these. ;) I've never used Github... I need to get that figured out. |
From: Dean M. B. <mik...@gm...> - 2010-01-25 19:39:58
|
On Tue, Jan 26, 2010 at 3:37 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> It would be cool if we used the Github issue tracker instead for >> things like these. ;) > > I've never used Github... I need to get that figured out. > It might be a good idea to start now. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
From: Glyn M. <gly...@gm...> - 2010-01-25 19:54:44
|
Hi Erik, 2010/1/25 Nelson, Erik - 2 <eri...@ba...> > Dean Michael Berris wrote: > > It would be cool if we used the Github issue tracker instead for > > things like these. ;) > > I've never used Github... I need to get that figured out. > It's very straightforward to use the issue tracker, simply go to http://github.com/mikhailberis/cpp-netlib/issues and you'll be able to create an issue there. G |