| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10
Comments:
<0> pizza is ready... brb
<0> they do everything different, that's their way to bind victums to their products
<1> NT and up does it to some extent, but a socket is still a totally different animal from a file handle, as far as I know.
<1> For example, serial and parallel ports are files.
<2> I thought sockets programming was quite similar. I've done some sockets stuff (simple though) in linux and didn't find any major differences
<1> Nagualito: It's similar, but you exchange socket handles with other types of stream handle.
<1> I think that's the main incompatibility.
<1> Boost provides some facilities to facilitate custom stream cl*** development, but I've never tried it. Sounds handy.
<2> oh I see. sounds better in Linux then:)
<0> Are you talking about non-blocking sockets application, Nagualito? I guess not, because that is never 'simple'.
<2> I think what I did in linux wasn't non-blocking, but it's been a long time
<1> Oh, there's that, too. In UNIX, you can just select on an fd set that covers all IO. Again, Windows I/O isn't general enough for that.
<0> which is main problem-- I wanted to write a library once that would shield non-blocking I/O and timing from the OS, therefore I tried to learn how this works in windows.
<1> You can select() against stdin, stdout, and some sockets, add a time limit, and still be perfectly reponsive to all interaction without wasting CPU time.
<0> I couldn't find out... and imho, that was because it isn't possible :/
<1> In Windows, you get to mess with callbacks or the Windows message queue, and other such happiness. Which wouldn't be bad if it were documented worth a damn.
<0> it's possible, I think if you restrict yourself to 64 clients or so... but that wouldn't be usable for -say- an ircd
<1> Is that the FD_SET limit under Windows? 64 handles?
<3> yes, by default
<0> Over my dead body that I will code something that looks for socket I/O in a GUI event loop...
<3> Under WIndows you have far more efficient I/O models:
<1> Run: Would be kind of bad in a DLL, wouldn't it?
<3> Overlapped I/O with event objects - or Overlapped I/O with Input Output Completion Ports
<3> nobody has to use the WSAAsyncSelect model (which uses a message loop)
<3> in fact, the IOCP model where you have one thread per processor is far more scalable than anything most UNIX systems have (select, epoll etc)
<0> Obviously, you can also use multiple threads under UNIX.
<3> you don't want too many threads, though:
<3> http://www.microsoft.com/mspress/books/sampchap/5726a.asp#126
<0> I know
<3> (see Table 6-3)
<3> illustrates scalability between the different socket server I/O strategies available under Winsock 2.0
<0> I've studied this topic quite deeply
<0> There is still something in the boost wiki about this from me I think... lemme see if I can find it back.
<3> the IOCP/Overlapped I/O model is available only on NT5+ systems - but the point is: the GUI message loop is the _worst_ way to do things on Windows
<3> (and the 64-limit doesn't apply to Overlapped I/O with IOCPs)
<1> auto_ptr: Interesting.
<3> it does if you use Overlapped I/O with event objects (i.e. WSAEventSelect)
<0> I was looking into Overlapped I/O with Input Output Completion Port, but I couldn't figure out how to make it work compatible with how UNIX works (this is NOT a trivial thing)
<3> Run: agreed, but why is compatibility a requirement? are you planning on porting the server?
<0> Hmm, I found a mail of that time
<0> http://lists.boost.org/Archives/boost/2004/09/71944.php
<0> (the black text is mine)
<0> but where is the damn wiki link?
<3> and it seems that most developers under Win32 still choose the worst I/O model for the job
<3> (but, porting the model to non-NT systems has never been a concern of mine, though)
<1> I don't know that Run's app needs to be all that scalable. One socket per IRC net, right?
<0> auto_ptr: Perhaps we could write this much needed library together...
<3> I'm intrigued: what is the library?
<0> I know a lot about UNIX, you know a lot about windows... the design is very hard: you need to be very knowledgable about both to even be able to come up with the right API / design.
<0> I've tried this before with boost developers - but that got stuck.
<1> Run: You attempted a generic networking library?
<1> That, I think, would be really neat.
<0> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing
<0> This is what I was looking for, I guess:
<0> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing/Glossary
<0> I wrote that
<3> interesting
<1> Neat.
<1> Compatibility aside...
<1> I wonder if you could do iostreams-style IO in a general way.
<1> To include the networking features.
<0> iostreams are pretty damn general, they are C++
<1> I don't see why not. I guess the main problem is the multiplexing.
<0> An ostream is nothing but a hook for operator<< to write custom cl***es to a streambuf - which is nothing else but a dynamic buffer (in memory).
<1> I've written my own socket streambuf before.
<0> Well, then you should know that the 'ostream' part of your question isn't the problem.
<1> It was less intuitive than I expected, though.
<1> It's been a while.
<1> But anyway, I guess once you've got multiplexing out of the way, you just can just perform I/O with the <<>> operators as usual, testing after each operation to see whether you had enough data.
<1> If not, return and wait for the next I/O notification call.
<1> Another common problem is remembering where you are in the sequence of operations.
<0> um... yeah... well... where was I?
<0> TODO 2: Need a way to figure out if the user is (still) on a given question channel.
<1> Anyway, my point was going to be: I wonder if there's any nice way to represent the notion of this sequence of input/outputs and the way that you want to return to the correct point in the sequence as more data arrives, or as the output buffer empties.
<1> Do you want to have a bunch of function objects and have them swap each other out as the target of the I/O callback, or what?
<1> Seems better than a swtich() or some other conditional.
<1> I wonder if there any good books written on the subject.
<3> I was positive there was an initiative to document the BIO stuff of OpenSSL in depth... seems I was mistaken
<1> Vawjr was telling me once that there's something inherently wrong with the optional exception-on-failure mechanism in iostreams.
<1> Not sure what he meant, exactly.
<1> But, apparently, he doesn't like the idea of setting exceptions() so as to throw on I/O errors.
<1> vawAFKhome: Knock, knock.
<1> Fridays. Bah.
<3> Saturday, here.
<1> auto_ptr: I forget, is exception-throwing inherently inefficient?
<1> Probably not something you want to do in a loop, as I recall.
<3> it isn't inefficient: you should throw an exception where you need to throw an exception
<3> whether it is in a loop shouldn't factor into how it affects the method's exception-safety guarantee
<1> Anyway, I guess that isn't essential. I was thinking, maybe if you break each chunk of I/O into a different callback cl***, you might have some mechanism to communicate to the muxing mechanism how much buffer it is that you need before the next callback.
<1> Well, but then that doesn't help much with text data.
<4> stupid C++ question -- if operator= is not defined, does it get implemented in terms of the copy constructor (***uming copy c'tor isn't explicit)
<5> no
<5> how could you implement operator= in terms of a copy constructor?
<5> operator= only works on an object that's already constructed
<4> well by calling the copy constructor
<5> calling the copy constructor on what??
<4> on the already-existed object
<3> Fudge: no: but there is a default operator= provided; don't forget the copy constructor is called when the object has no state - when operator= is called, the object has state
<4> well then what does the explicit keyword do?
<5> you can't call a constructor on an already constructed object - that's silly
<4> ok
<4> i got it
<4> thanks
<3> Fudge: mycl*** foo() { return 5; } mycl***(int); would allow that. explicit mycl***(int); would not allow that
<3> explicit mycl***(int); would only allow mycl*** foo() { return mycl***(5); }
<0> Fudge: Perhaps you are confused by the fact that Object obj = init; does NEVER call the operator=, but uses Object(type of init const&)
<5> explicit disallows implicit argument conversion
<4> Run, yeah that's waht got me
<4> so it is not a weird idiom to sometimes (when appropriate) implement the copy c'tor in terms of operator=(const SameType &)?
<0> Actually... it does: Object obj(Object(init));
<0> So, when Object(int) (***uming 'init' has type int) is explicit, it won't work.
<0> operator= is only used when you do: obj1 = obj2; and has nothing to do with a copy constructor, although also here there could be an implicit conversion.
<3> now consider where you would want the behaviour of 'explicit'
<0> Ie, obj1 = 3; would do: obj1.operator=(Object(3)); when operator=(int) doesn't exist.
<0> you add 'explicit' when you don't want those implicit type conversions.
<4> oh so it constructs int erms of Object(int) then calls operator=?
<4> ok
<3> vector<T> foo() { return 5; } // you would not want something like that
<0> If operator=(int) doesn't exist, yes.
<3> hence vector::vector(size_type) is marked 'explicit'
<4> now.. for a cl***, operator=(const SameType &) isn't pre-defined for you as it is for a struct, correct?
<0> yes it is
<4> well it's not public though, right?
<3> Fudge: there is a default operator=, a default copy constructor, and a default constructor
<3> vector<T> foo() { return vector<T>(5); } // legal
<5> and a default destructor
<4> ut all those are private for a cl***, right? (by dfault)
<0> a cl*** and a struct are totally the same thing, except for the fact that a struct is by default public, and a cl*** private... one more more obscure thing that I forgot.
<3> Fudge: they aren't...
<4> what?!
<5> it would be silly for the default constructor to be private by default
<4> for a cl***?!
<4> oh maybe protected then
<5> nope
<0> The compiler generated default constuctor, copy constuctor and operator= are of course public.
<3> Fudge: they're public...
<4> woah
<5> then you couldn't instantiate any cl***es unless you defined a public constructor - which would defeat the purpose of having it automatically generated
<4> i did not know that
<4> so if you want to get rid of the default constructor you haev to explicitly make it private?
<5> why do you want to get rid of it?
<0> Or add any other constructor.
<5> if you define any constructor, the default one doesn't get generated
<4> ah ok
<4> good
<4> but operator= does...?
<5> I don't remember
<0> that's called when you do: obj1 = blah;
<0> It can do anything if you write it yourself.
Return to
#c++
or
Go to some related
logs:
#MissKitten
#php
#skype
#linux
#php
wbbbbb
#php
#javascript
xms disk
paradoks namlu
|
|