- std::variant<Dublin, Jerusalem, Melbourne, Prague, Austin, ...> - 2 Updates
- Creating mutex pointer in c++ - 3 Updates
- peformance of wait notify concept of condition variable - 4 Updates
- My Object oriented Stackful coroutines library for Delphi and FreePascal version 2.0 is here.. - 1 Update
- How to Improve Visual C++ 2017 Libraries Using PVS-Studio - 1 Update
| woodbrian77@gmail.com: May 04 10:51AM -0700 On Wednesday, May 3, 2017 at 12:39:05 PM UTC-5, Mr Flibble wrote: > Subject: std::variant<Dublin, Jerusalem, Melbourne, Prague, Austin, ...> > Using a variant to hold different cities is egregious. All cities are of > the same type: "city". This compiles: #include <variant> int main () { ::std::variant<int, int, int> v; } ------------------- The reason for using variant is to convey that I'm only planning to give one talk where I travel to your location at my expense. Maybe there will be more in the future, but I'm not planning on that at this time. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 04 10:22PM +0100 >> Using a variant to hold different cities is egregious. All cities are of >> the same type: "city". > This compiles: Just because code compiles it doesn't mean code is correct. > { > ::std::variant<int, int, int> v; > } You have obviously totally missed the point I was making. [snip] /Flibble |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: May 03 11:37PM -0700 On Wednesday, May 3, 2017 at 10:57:57 PM UTC+5:30, Bonita Montero wrote: > > std::unique_lock<std::mutex> lock(*ptr); > Or with C++17's class template deduction: > std::unique_lock lock( *ptr ); hi, Is it any differnent than the previous approach? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 04 10:24AM +0200 >> std::unique_lock lock( *ptr ); > hi, > Is it any differnent than the previous approach? It works only with compilers that support C++ with the class template deduction feature. This is only a convenience-feature. The resulting code is exactly the same. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 04 01:07PM -0700 On 5/4/2017 1:24 AM, Bonita Montero wrote: > It works only with compilers that support C++ with the class template > deduction feature. This is only a convenience-feature. The resulting > code is exactly the same. I agree that it is a convenience. Not sure if I totally like it or not, but its is very convenient for sure. My skills in C++ can be old-school from time to time. I like Alf P. Steinbach's code because it helps me visualize newer features. :^) Common now, try to give proper attributes wrt quoting others. Pretty Please? ;^o |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 03 05:30PM -0700 On 5/2/2017 5:09 AM, Bonita Montero wrote: > allowed to terminate immediately without any aschronous behaviour, > although I'm issuing asynchronous reads, i.e. ReadFile() returns > true. So the I changed the single-threaded code: [...] The race-condition mucks up the waters, but once its hooked up to IOCP, even if ReadFile or WSARecv complete immediately aka they returned TRUE and 0 respectively, an IOCP event is guaranteed to be scheduled. Read all of: https://msdn.microsoft.com/en-us/library/windows/desktop/ms741688(v=vs.85).aspx The completion routine is scheduled. When hooked up to IOCP, this means that a message is in the queue. GQCS will pick it up. Now, in the context of creating windows servers, we can use the fact that a WSARecv completed immediately to issue a couple of more overlapped receives to allow for more efficient handling of fast connections. A friend of mine called it "burst mode". I suppose we can do the same for files. Fwiw, I have always used TransmitPackets when ever I could wrt sending memory and/or files. Also, again, can you please add proper attributions to your posts? Thanks Bonita. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 04 09:00PM +0200 I was talking about the extension of the file with the single-threaded version of my test-app. MSDN states the following on asynchronous I/O that extends a file: "On Windows NT, any write operation to a file that extends its length will be synchronous." (http://bit.ly/2qwJA7w) So WriteFile returns FALSE and GetLastError() also returns ERROR_IO_PENDING as expected, but the write-operation is nevertheless finished after WriteFile returns. And I was right to assume that an asynchronous I/O-operation may pro- ceed synchronously: "Be careful when coding for asynchronous I/O because the system reserves the right to make an operation synchronous if it needs to." http://bit.ly/2qwJA7w So deciding to handle two different cases upon the return-value of ReadFile is correct. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 04 09:03PM +0200 And see the source-code of the first listing of http://bit.ly/2qwJA7w This code does the same thing I wrote: it handles the I/O-postprocessing depending on the return-value of ReadFile!!! |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 04 12:09PM -0700 On 5/4/2017 12:03 PM, Bonita Montero wrote: > And see the source-code of the first listing of http://bit.ly/2qwJA7w > This code does the same thing I wrote: it handles the I/O-postprocessing > depending on the return-value of ReadFile!!! Will read it. Thank you. |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: May 03 11:42PM -0700 On Wednesday, May 3, 2017 at 3:32:41 AM UTC+5:30, rami17 wrote: > . > Thank you, > Amine Moulay Ramdane. no no you did write man congrats |
| Ian Collins <ian-news@hotmail.com>: May 04 04:29PM +1200 On 05/ 4/17 09:50 AM, Richard wrote: > dereference errors. I'm in the process of fixing those. Finding > these through manual testing would have been prohibitively tedious and > exhausting. You use naked pointers, shocking! :) -- Ian |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment