look at the implementation of MyHistorcalScheduler.Run(). ToObservable() will schedule all StockQuotes right away with a DueTime of 0 (because you ignore the StockQuote.Data value completely). AdvanceTo() then throws.
I am not sure what is the right implementation of GetQuotes(). I am guessing that
when called it should not block but return right away (with the IObservable<StockQuote>), regardless whether iterating over the sequence of stock quotes blocks or not
when called several times it should produce the sequence serveral times from the beginning
it should call OnNext of the observer at StockQuote.Date measured in the clock time of the passed scheduler
one call of OnNext should be finished before calling the next time (might conflict with the point obove)
First of all, this is what we do: we are developing applications that control sophisticated, laser based, optical measurement systems that acquire 100 MBytes/s and more of data, processing it real time, storing, analyzing and visualizing it. We currently use DirectShow (for dataflow parallelism of the data acquisition), DirectX (for live video and overlay), ATL (for component based architecture), MFC, boost, OpenGL (for 3D visualization) and .NET (interop via COM).
I appreciate the work that was already done for VS 2010 like lambdas, rvalue references, the update of the STL to use move semantics, ConCRT, PPL and the agents library, debugging (parallel threads, tasks, profiler). This is great stuff! We are currently looking into using ConCRT and PPL of off-load work from the UI thread and maybe agents to replace DirectShow for the acquisition part. And we are looking into replacing the UI part written in MFC by C# WindowsForms or WPF.
Comparing development in C# / .NET with native C++, our experience is, that productivity in C# / .NET is much higher (1.5 x to 2 x) because of tools and libraries.
What we miss most in VC++ 2010 is: code coverage, unit tests, refactoring, support for XML comments, code metrics. I know that for most of these there are third party solutions but having it all at your fingertips and fully integrated like in C# is a great benefit. I hope the rumors are right, that VS next is addressing some of these and I hope it will be available in VS professional and not only in ultimate, which is unaffordable.
The other topic, which is at least as import, is libraries. Mohsen's statement (joke?) about BCL == STL touches the core issue: STL provides great containers and algorithms that are comparable to or even better than the BCL versions. But what we need is much more. Look at code created by the MFC app or ATL simple COM object wizards and compare it to C# code (Windows Forms, COM visible objects). The C++ version is not C++ (at least not modern C++). It is cluttered by macros (MESSAGE_MAP etc.), unsafe types (WPARAM, LPARAM, BSTR, SAFEARRAY), needs a separate language (IDL) and lots of boilerplate code. In contrast the C# version is succinct, seamless and uses the CLI types (string, arrays) decorated with few attributes. Writing COM objects in C# is much more productive than doing the same with ATL / C++, set the non deterministic destruction and deployment (where to put the type library, reg-free COM) aside. The same is true when comparing Windows Forms and MFC.
To do Windows application development in VC++ we have to deal today with std::string, BSTR, _bstr_t, CComBSTR, CString, CAtlString, LPCTSTR, OLESTR, char*, wchar_t*, TCHAR*, _T(). Arrays: SAFEARRAY, CComSafeArray, built-in arrays, std::vector, raw pointers, etc. Error handling is another example: HRESULT, _com_error, IErrorInfo, GetLastError(), DWORD, BOOL, INVALID_HANDLE, exceptions, etc. Resource management: new, delete, DEBUG_NEW, ::SysFreeString, ::CoTaskMemAlloc, ::GlobalAlloc, etc.
This is insane!!!
What is desperately needed are STL / PPL / boost like libraries that use RAII for resource management, exceptions for error handling, containers that are STL compatible and that are named consistently.
You have invested lots of resources for designing the .NET framework. Why not take this investment and port parts of the framework to native C++? I am not talking about interop or wrapping it, I am talking about native C++ libraries with modern interfaces that do the same thing and use similar names for classes and types.
Top priority list would be:
network (UDP, TCP/IP, HTTP)
XML parsing and writing
serialization (binary and XML)
UI (Windows Forms or WPF like)
Instead of the .NET reference types use C++ pImpl pattern with std::shared_ptr to the mplementing class (like task<T> of the ConCRT extras sample pack). Then we get performance, safeness and deterministic destruction for free.
Speaking of task<T>: throughout the framework use a consistent model for asynchronous method calls, like TAP for .NET. Implement a full blown task<T> type like .NET's Task<T> (the version of the ConCRT extras pack 0.4 is a step in the right direction but error handling, proper cancellation support and support for scheduling continuations on the UI thread are missing). Implement all asynchronous methods by returning task<T>.
That would be a huge productivity boost! And having that library on Windows Phone, and Windows XP - Windows 8 would allow developers learning it once and apply it everywhere.
The corner cases you talked about made all this rvalue and lvalue stuff a little clearer to me. Keep on going!
I would love to hear more about dynamic memory allocation optimization in the STL. E.g are there any tricks used in the associative containers and list used to make allocation of objects (nodes) of the same size fast?
Can "normal" users achieve the same using custom allocators?
Regarding the comments about std::vector<std::<vector>>: their are cases where you have jagged data and not all vectors are of the same size and where elements have to be inserted after creation. We wrote a little helper container small_vector for those cases that avoids dynamic allocation when it contains only a few elements and falls back to std::vector when there are more (a bit like std:string does).
This gave us a 2x to 5x speed up compared to std::vector<std::<vector>>.
thanks a lot for this excellent introduction to STL. I can't wait to see more. I also very much appreciate how much progress C++ made in VS 2010.
I have a question: you briefly mentioned some gotchas when using for each. Did you mean the C++/CLI for each (int i in v), that is also available in unmanaged code? I am working on our coding guidelines and I would be interested what those gotchas are and
what you recommend instead. BOOST_FOREACH? Waiting for C++0x's for (int i : v)?
I am well aware of the STL for_each or transform algorithms, but in my eyes it is much clearer to write e.g.