﻿/*
	© 2014-2016 FrankHB.

	This file is part of the YSLib project, and may only be used,
	modified, and distributed under the terms of the YSLib project
	license, LICENSE.TXT.  By continuing to use, modify, or distribute
	this file you indicate that you have read the license and
	understand and accept it fully.
*/

/*!	\file Workflow.Annual2014.txt
\ingroup Documentation
\brief 工作流汇总报告 - 2014 年度。
\version r917
\author FrankHB <frankhb1989@gmail.com>
\since build 464
\par 创建时间:
	2014-01-01 00:46:52 +0800
\par 修改时间:
	2016-06-07 20:29 +0800
\par 文本编码:
	UTF-8
\par 模块名称:
	Documentation::Workflow::Annual2014
*/

// See "Meta.cpp" for meta descriptions.

$import $WORKFLOW;
$LINE-WIDTH-RESTRICT 0;

$WORKFLOW:
// Following lines are only for logging informal project information.
// See Meta.txt for formal project information.
// See ChangeLog.*.txt for accepted contents.

$2014-01:

report.impl:
The MinGW.org and MinGW-W64 runtime can be distinguished by predefined macros, though version macros are not predefined:
	See http://sourceforge.net/mailarchive/forum.php?thread_name=CAEwic4b-B8%3DQ%3DSV2ptwO36SsCQW%2B6b0N%3DX41t3NHPoDQV%2BKeTw%40mail.gmail.com&forum_name=mingw-w64-public.
	See also http://sourceforge.net/p/predef/wiki/Compilers/.
There may be some wrong impression of border thickness due to the colors.
	It is easy to see the left vertical line of boundary of the checkbox is thicker in setting panel with violet background.
	When the panel background color is some lighter, here is no such illusion.
	Indeed they have the same thickness. It would be obvious after zoomed (esp. > 2x).
	Actually, no rendering code of checkbox has been changed.
Both the runtime from MinGW.org and MinGW-W64 support multiple versions of Microsoft VC++ library(MSVCRT). There are some issues:
	Different verstions of MSVCRT define different symbols with some subtle problems. So they should be same in different toolchain configurations for best compatibility.
		Both of them support at least version 6.0, which is probably the most wide-adopted by Microsoft Windows(they came by default install). The library file name is "msvcrt.lib" for Microsoft VC++, accordingly "msvcrt.dll" of the dynamic library and "libmsvcrt.a" as static library for both runtime.
			Though acceptable, but deployment depend on it is not good. The are not publicly guaranteed to be compatible within different versions of Windows.
		For newer versions, the dyanmic libraries name schema is "msvcrXX.dll", in which "XX" is the corresponding concatenated Microsoft VC++ main and minor version numbers. For example "msvcrt90.dll" is of VS2008.
			The architecture names (such as "x86" or "amd64") are not related of the file names.
			They are required to be deployed along with the applications, or the end users might able to install corresponding version of Microsoft VC++ Redistributable Package.
		MinGW.org uses 6.0 as default. Things about MinGW-W64 are some complicated, see below.
		Currently MinGW.org's distribution has "libmsvcrt.a", "libmsvcp60.a"(the C++ runtime of Microsoft VC++ 6.0), and "libmsvcr70.a" to "libmsvcr100.a"(the whole "XX" are 70, 71, 80, 90, 100). It also has corresponding debug versions for latter, i.e. "libmsvcr70d.a" to "libmsvcr100d.a". No newer MSVCRT are supported.
		On the other hand, MinGW.org's distribution also has "libmsvcrt.a", "libmsvcp60.a", and "libmsvcr80.a" to "libmsvcr100.a", but neither other versions("libmsvcr70.a", "libmsvcr71.a") nor debug libraries. However, it has "libmsvcr110.a", which MinGW.org's does not supported.
	There is one extra library, "oldname.lib", to contains the original version of symbol names deprecated by Microsoft (such as POSIX-specific functions, because they are not strictly comforming to ISO C), to map to new names(usually added prefix underscore).
		They are also different in MinGW.org's and MinGW-W64's runtime. There are "libmoldname.a" and "libmoldnameXX.a"("XX" here is also the version numbers, see above) for the former, and only one "libmoldname.a" for the latter.
		See http://sourceforge.net/mailarchive/message.php?msg_id=30556805.
	Most notable problem is backward compatibility. For example if new "secure" functions(ISO TR 24731-1) like "scanf_s" are used, MSVCRT older than version 8.0 can not be used.
		Actually it is not version 6.0 of MinGW-W64's "libmsvcrt.a". It even exports "__gmtime32" comes from version 8.0.
	Both toolchains use the same built-in specs in compiler driver for use of these libraries, i.e. "-lmsvcrt".
		For better compatiblity, lirary not older than "libsvcrt80.a" should be put explicitly in the linker options to override the default linked "libmsvcrt.a".
		Allocation and deallocation should always be carefully matched within the boundary, i.e. make sure the allocation function and deallocation function for same storage are from the same library.
		Using 2 C runtime library and directly overriding symbols are dangerous.
			Note that libgcc, startfiles or some other library with "atexit" or thread-local storage can be involved with C runtime library's free storage allocation.
		Specs file can be used to specifying completely substition of the C runtime library. It is safer but less convenient.
	Both define the macro "__MSVCRT_VERSION__" in <_mingw.h> to control what version of MSVCRT used.
		If not explicitly specified (i.e. not defined "__MSVCRT_VERSION__" before inclusion of <_mingw.h> or through command line option), both would defined a hard-coded integer value.
		The default values in the libraries are different. It is "0x0600" in MinGW's but "0x0700" in MinGW-W64's.
		A subtle problem is, which not only effected by the version macro. One notable extra macro is "__STRICT_ANSI__", which introduced by several GCC compiler options like "-ansi" or "-pedantic".
		There is a horrible bug in the MinGW.org's <time.h>: if "__MSVCRT_VERSION__ >= 0x800" and "__STRICT_ANSI__" is also defined, then some ISO C functions like "time" are not declared.
			This directly caused <ctime> of libstdc++ (which has 'using ::time;', etc) unusable.
			Maybe more similar bugs, also in different headers.
	The "YFramework.dll" can compiled from b464 after some changes in "YCLib/FileSystem.cpp" but cannot be linked as DLL without changes of some project options.
		The error is of the unresolved symbol "_gmtime32", comes from "pngwrite.o" in "libFreeImage.a".
			It is introduced directly by a call of "gmtime" in function "png_convert_from_time_t" when the configure macro "PNG_CONVERT_tIME_SUPPORTED" is defined.
				The "PNG_CONVERT_tIME_SUPPORTED" configuration is not supported by every platforms, for example Windows CE.
				It is considerable to remove "PNG_CONVERT_tIME_SUPPORTED" in "pnglibconf.h". But it is not a fix for the problems here.
			Currently FreeImage is built with MinGW-W64 toolchain.
			Actually both toolchains can map "gmtime" to "_gmtime32".
			The reason of failure for MinGW.org is that "_gmtime32" is not contained by "libmsvcrt.a" of MinGW.org's, but do contained by MinGW-W64's.
	There are several optional version of MSVCRT containing "_gmtime32", but no one are proper for this scene.
		No MSVCRT 7.0 and 7.1 available for MinGW-W64 toolchain.
		The deployment of MSVCRT 8.0 and 9.0 makes a lot of trouble, if there is no manifest provided.
			For side-by-side assemblies, see http://msdn.microsoft.com/en-us/library/ms235624%28v=vs.80%29.aspx.
			For newer Microsoft VC++ deployment, see http://stackoverflow.com/questions/6623780/visual-c-2010-changes-to-msvc-runtime-deployment-no-more-sxs-with-manifest.
		For MSVCRT 10.0, symbols "_wstat", "_imp__findfirst" and "_imp__findnext" are not defined.
		No MSVCRT 11.0 or newer available for MinGW.org toolchain.
	Though rebuilt libraries are needed sooner or later, now it is better to have a fix in the project configurations.
		For maintaince reason, the configuration should be the same, without need for users to select one out of two set of configurations.
		Note that a value of "__MSVCRT_VERSION__" not less than 0x0800 causes bugs in MinGW.org's headers when "__STRICT_ANSI__" is defined.
			If this macro is set, only 0x0600 to 0x0700 can be used.
			This macro can be set explicitly to 0x0600 for compatibilities (also for library rebuild).
		For convenience and sanity, no manifest should be introduced.
			There is even no dependency on MSVCRT other than "libmsvcrt.a" in MinGW-W64. It is only to be compatible with the buggy MinGW.org runtime.
			Though introduced a newer dependency, it is somewhat acceptable. YFramework might use some features in that newer version of MSVCRT.
			To introduce manifest only for MinGW.org's compatibility is too expensive.
		Note that mix use of different versions of MSVCRT is dangerous.
		It is relatively safe to use a newer library together with older headers.
		So the final resolution is to implement a custom "_gmtime32" function for MinGW.org toolchain.
Currently object files compiled with '-ffunction-sections -fdata-sections' for GNU ld with '--gc-sections' doesn't work for MinGW PE-COFF targets. It might be fixed in future.
	See https://sourceware.org/bugzilla/show_bug.cgi?id=11539.
	See http://cygwin.com/ml/binutils/2012-08/msg00216.html.
	See http://sourceforge.net/mailarchive/forum.php?thread_name=CALc40c_v46OnoopJXWbPpQk651JAxWU3UYFmDJy998mPKzD9DA%40mail.gmail.com&forum_name=mingw-w64-public.
Skin is the top level of GUI an application's shell to reflect look and feel. For a reusable GUI toolkit, a visual style is a set of visualized features for UI elements, being a major part of the skin.
YFramework should implement the visual style support. It has been planned from very early reversions.
	Basically, the styles are not for each widgets. They are only effective to style-related widgets.
	The major interface is of namespace "YSLib::UI::Styles", providing abstraction to be stored within the GUI state.
	The previously implemented interface is the palette, which contains a vector of colors to be used in style-related widgets rendering.
	Now the visual style states should be implemented as sets of runtime swichable states.
		The style should be swichable by user code via the GUI state interface. It is the wrapper of the major interface.
		For convenience, the type "string" is used as the key to identify a style.
		It is intended that switching of styles should take effect on classes of widgets. For each paticular instance of widgets, it should be possibly doable to switch in future.
		Switching to a different style should be efficient. That means iteration of each widgets to modify the state is generally inacceptable.
		The basic idea is to bind each styled rendering process as an event handler with parameter type 'PaintEventArgs&&' and to be added to event 'Paint' of the target widget instance.
		The binding of event handler needs a type containing the common implmentation against to code bloat. If per widget style state can also supported here if necessary.
		There should be a way to identify the widget class types. Indexable RTTI type ('std::type_index') is preferred for convenience.
		Choice has been made for the lower layer of the implemention details:
			Static polymorphism is not feasible for some runtime-determinated properties.
			Both interface types(i.e. polymorphic classes having only pure virtual member functions) and manually indexing of handlers are feasible.
			Pros of interface types:
				It is flexible to describe complex details.
				Different sets of explicitly-typed shared state can be stored in the implementation directly.
				Type safety is easily gained through function signatures.
				Inheritance can reduce some common code.
			Cons of interface types:
				Probably more code to write. In the worst case, each interface type should provided to corresponding style-related widget class manually, being hard to reuse.
				Some extraordinary code bloats, linear complexity of total number of style-related widgets.
				Performance decreased for unnecessary virtual calls, though can be optimized away, but not guaranteed and likely not. Note that dispatch of event handler calls are already polymorphic in runtime through 'std::function'.
				It is difficult to use because the concrete interface type should be get statically. This causes it impossible to store all interface types for different widget classes together within the same GUI state without some tricks.
					Type erause or base interface type can be used. Both are expensive in performance and inconvenient to implement.
					Explicitly casts should be used for each binding, obviously inconvenient.
				The ABI is likely complex and not steady. Modifying interface of per class interface is very likely to leads to the user code to be built again.
			Pros of manually indexing of handlers:
				It is simple and direct for event handler binding.
				Code generation and performance is easier to control by the user.
				It is flexible and convenient to use.
				The ABI is likely simpler, and steady when no modification to the indices.
				Indices can have aliases through enumerator or 'const' object declarations.
			Cons of manually indexing of handlers:
				Some lower level details can not be exposed through the interface, which can be inconvenient to use.
				The handler type is limited to event 'Paint'. If needed, the major style interface should be modified.
				Shared states can be supported through the interface should be unique.
					If needed, some additional interface should be added to the GUI state.
					Type erasure or similar techniques can be used to get some intended effects.
				Almost no higher level of optimization at all. The implementation of the language is not aware to the indexing.
			For current requirements, the latter is better.
				It is easy to implement and use.
				It is not very hard to add functionality. Although if needed, the major interface might be modified, but not very probable.
				Indices are not needed to be assigned manually if using enumeration type.
ISO C++11 still uses copy elision for some cases as C++03. There are some special rules.
	See ISO C++11 12.8/31 for conditions.
	If these requirements are met, move constructor of a class can be selected by the overloading resolution without explicitly using 'std::move' or rvalue reference cast. See ISO C++ 12.8/32 for details.
	See also http://isocpp.org/blog/2012/12/quick-q-a-unique-ptr-is-not-copyable-so-why-can-i-return-one-by-value-stack.
Since now ISO C++11 is mandated '<::' to be distinguished as '<' and '::' but not '<:' and ':' if the consequence character is not '>' or ':' , no need to always add space to between '<' and '::'.
	G++ 4.7.1 has not supported.
	G++ 4.8.2 is conforming.

$2014-02:

report.impl:
Trailing path delimiters are allowed in YCLib::FileSystem.
	IEEE POSIX-1003.2 allowed trailing slashes.
		See http://mail-index.netbsd.org/tech-kern/2002/04/28/0016.html.
	Windows API 'FindFirstFile' does not expect trailing delimiters in pattern, so preprocessing of the path string is needed.
		Some implementations may only consider one delimiter. See 'diropen' implemented by MinGW.org.
Both slashes and backslashes can be supported as file system delimiter by Windows API.
	Adding prefix '\\?\' can ignore 'MAX_PATH' limitation and enable large path support.
		Not all API support it.
		Currently, YCLib do not explicitly use it.
	See http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx.
There are some issues against aggresive optimization of moving an object in several contexts.
	For initialization of exception objects, the copy elision would not be performed.
		See N3690 comment CA 23 and CWG 1493.
		See also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3771.pdf.
	Currently moving from returned object is tied closely to the criteria for copy elision.
		See N3690 comment US 13 and CWG 1579.
		Explicit use of 'std::move' can be a workaround.
		This issue was accepted.
	See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3852.html for N3690 comments list.
	There was no consensus for the suggested change for other contexts. See N3690 comment US 12.
	Therefore, explicitly use of 'std::move' and 'std::move_if_noexcept' only should occured when necessary.
	See also $2014-01 in this document.
'YSTest402r16.nds' cases DeSmuME 0.9.9 x64 crash for unknown reasons.

$2014-03:

report.impl:
Now for YSLib::UI, the default UI event handlers treat the senders to be processed instead of destination widgets where the identity of the sender and the destination widget is true.
	The old rules mean 'this == e.GetSender()' is always true for calling of some events in implementation of YSLib::UI.
		There is no guarantee or guidelines to specify either sender or destination widgets to be used actually in the hanlders in or not in implementation of YSLib::UI.
	The new rules mean senders should always to be considered to be processed at first.
		Actually, the senders are the widgets to be process as possible as it can, i.e. if no dynamic cast needed, 'e.GetSender()' is used instead of '*this' in implementation of YSLib::UI.
	User-provided handlers now can use this assumption to transfer different senders.
	Note that for user-called event, 'this == e.GetSender()' might be false.
	For source different than destination like close button in 'DialogPanel' or widget in 'HoverUpdater', this transformation is obviously not correct for logical reason.
Note that default constructor of instances of 'std::chrono::duration' and similar types are defaulted.
	The underlying values might not always be initialized if there default-initialization is no initialization(see ISO C++ 8.5.3 for details).
	Use interface like 'std::chrono::duration_value::zero()' to get specific zero values.
	Currently there are several use of these types with explicitly default-initialization, which is indeterminated, but not direct used before assignment.
	Consider to use explicit initialization in class definitions to emphasize they are already initialized, if necessary.
Some event-based invalidation of "YSLib::UI::Control" class is removed.
	This is because these invaliadation operations are not always necessary. They are also harmful to performance when not needed.
	Even if the operation is handled, other handlers for painting with same or lower priority might need a more invalidation when more area should be invalidated.
	Invalidation should be performed for controls that painted with different look between focused and non-focused states.
		These controls are all style-related.
		They are "Thumb", "TextList", "ProgressBar", "DialogBox", "DialogPanel", and their derived classes.
			For derived classes, no explicit handlers need to be added. These base classes are directly derived from "Control".
	For "LostFocus" event, following cases are considered:
		For "DropDownList", no further invalidation is needed. The detacher has nothing to do with dropped down list itself.
		For "Menu", no further invalidation is needed. Only the hiding operations perform the invalidation, which is done in "MenuHost::HideRaw".
			But it should be used for focus border painting.
		For "TextBox", a further invalidation is needed and added in the handler for focus border painting.
			Note that the invalidation for caret is not enough.
	For "GotFocus" event, only one case is considered:
		For "Menu", further invalidation for showing is needed. It should be used also for focus border painting.
		For "TextBox", a further invalidation is needed and added as a new handler for focus border painting.

$2014-04:

report.impl:
Call by value or by rvalue refernce for a callable object, a call wrapper or an iterator might be significant different.
	For the notion of call wrappers, see ISO C++11 20.8.1, which was intially introduced in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1673.html.
		A call wrapper "holds" a callable object, not necessarily "owns" a callable object. Be cautious for the lifetime of the underlying callable object.
	Note a call wrapper is MoveConstructible; a call wrapper can be not CopyConstructible; A simple call wrapper is CopyConstructible. See ISO C++11 20.8.2/4.
		Exceptions are strictly restricted to be thrown. No exception are allowed to be thrown in copying a simple call wrapper.
		For moved-only types(which is not CopyConstructible), it should be treated as forwarding call wrapper, i.e. passed as '_fCallable&&'.
		Otherwise, for simplicity, a callable object should be passed by '_fCallable', except when necessarily treated as forwarding call wrapper by design.
			Most uses of callable objects or call wrappers are plainly passed by value.
				Such as the function parameter of the constructor of 'std::function' with exactly 1 parameter.
				The function templates in algorithm library accept callable objects or simple call wrappers passed by value.
			The are two important exceptions:
				The 1st parameter for the constructor of 'std::bind'.
					The forwarding call wrapper should have been accepted by design.
					See http://wg21.cmeerw.net/lwg/issue817 for details.
				The 1st parameter for the constructor of 'std::thread'.
					The use cases and reasons are similiar.
					See http://wg21.cmeerw.net/lwg/issue929 for details.
	As of ISO C++ 12.8/32, if the object designated as lvalue is a parameter, it would be firstly moved even if the copy elision criteria in ISO C++ 12.8/31 are not met.
		If used as forwarding of a passed by value callable object, no redundant 'std::move' should be used.
		See also $2014-01 and $2014-02 in this document.
	Similarly, in the standard library, the iteraors in the algorithms are passed by reference primarily.
	For simplicity in YSLib, if and only if noncopyable callable object is intendedly acceptable by design, pass-by-value '_fCallable' should always be used instead of '_fCallable&&'.
		This also means most callable objects should be CopyConstrictible.
		The major general exception is for forwarding function templates, which have templated function parameters like '_tParams&&...'. Some examples:
			General forwarding function templates like 'ystdex::seq_apply', 'ystdex::unseq_apply' and 'ystdex::call_projection::call' in YBase::StandardEx::Functional. They are used for reordering the evaluation as well as forwarding the parameters, so just behave as 'std::bind'.
			General forwarding call wrappers as 'ystdex::expanded_caller', also the helper 'ystdex::make_expanded', in YBase::StandardEx::Functional.
			Forwarding functions templates in YTest::Timing.
			Callers which use 'ystdex::expanded_caller' as underlying implementation in YSLib::Core::YEvent.
	For simplicity in YSLib, an iterator should be passed by value, unless it is an iterator adaptor to generally provide adaption for any other iterator types.
		The general iterator adaptors include, for example, 'ystdex::any_iterator' or 'ystdex::transformed_iterator'.
		All current declarations are conforming. No modification need to be performed.
Unless otherwise specified, the assumption of a resonably reliable C++ implementation should be used for YSLib.
	Differently to Boost, no defensive programing techniques are encouraged to be used to make a poor implementation work.
		Such as double-destruction protection on exception classes.
Rules for exception handling should be uniformed.
	Exceptions handling should generally make use of custom exception classes.
		Pay attention to implicitly declared special member funtions.
		The following rules are forced:
			Make sure no resource could leak.
			Make sure the destructor is virtual.
			Make sure the move constructor, if any, have nothrow guarantee.
		For YSLib, the exception objects should be MoveConstructible or at least CopyConstructible with trivially copy can be performed. See below for reasons.
	Boost exception handling guidelines are reviewed. See http://www.boost.org/community/error_handling.html.
		Note it is pre-ISO C++11.
		However, currently most of these rules are not used in YSLib.
			YSLib follows closely to ISO C++ standard library.
	It's good to make exception classes derived from 'std::exception'.
		YSLib follows this guideline.
		But no assumption should be make generally in user code.
	Virtual inheritance with tagging is not used as Boost library. Because:
		It is somewhat less efficient both in time and space.
			This is a minor reason, but it nodoubtly exists.
		It might be complex and error-prone.
		The tag dispatching is not always useful.
		States of context might be significant, data members in different subobjects stored in the same exception object may be used.
	There should be no exception thrown during copy-initialization of an exception object.
		Otherwise, 'std::terminate' would be called on copy-initialization failure in throw-expression.
		The stricter "not embedding" rule (Boost exception handling guideline 3) is only necessary when the move constructor is not usable.
			It is reasonable to not embed a subobject without nothrow-copy guarantee into an exception object for pre-C++11 code.
		Make the exception object movable, ideally only the initially creation of the excetpion object is concerned with the copy failure.
		Note the replacing of copy by move operation based on copy elision criteria is not applicable for caught-by-value exception objects.
			See $2014-02 report.impl about non-mandantory of move exception objects.
		But anyway, for 'std::bad_alloc', even calling of 'std::terminate' is still probably acceptable. Note this handler can be set by 'std::set_terminate'.
		Some standard library classes, notably 'std::exception', are following this guideline. Some others are not guaranteed, like 'std::runtime_error', which uses object of 'std::string' as a constructor parameter.
		See also http://stackoverflow.com/questions/15831029/not-using-stdstring-in-exceptions.
		Because the YSLib exception objects are MoveConstructible or can be copied trivially, "not embedding" rule is not forced.
	Ideally the constructor used other than copy-initialization should throw no exceptions. But this is also not always true.
		Some standard library classes, notably 'std::exception', are following this guideline. Some others are not guaranteed, like 'std::runtime_error', whose constructors are without 'noexcept'.
		This guideline is also not forced on YSLib exception objects.
	The 'what' member function should be overriden only necessary.
		It is usually memroy-sensitive to format the message string.
		YSLib rarely override the 'what' member function.
	For both implemention and semantics reasons, do not use 'catch(...)' without rethrowing unless really necessary. See also Documentation::CommonRules @5.14.2.

$2014-05:

report.impl:
	Select carefully between 'const_iterator' and 'iterator' for ODR issue. See http://wg21.cmeerw.net/lwg/issue1214.
There are some similar measurement values for a given image with proper underlying image buffer, both are rectangular in sense of rasterization as pixels.
	Width is the magnitude of the logical image or buffer area in horizontal, or X-axis for 2D coordinates.
	Height is the magnitude of the logical image or buffer area in vertical, or Y-axis for 2D coordinates.
	Stride is generally the distance of two entities measured in a single unit.
		It can be the distance between two pixels in either horizontal or vertical of an image.
		For a buffer, the stride is the width of the buffer area.
			Usually it is in pixels.
			It could be sometimes in memory units(esp. bytes) , so being a synonym of the pitch of the buffer, see below.
	Pitch is a particular kind of measurement for a buffer in several different units.
		It is often the synonym of the stride, which is in pixels.
		It is more often measured in bytes for the underlying scanline of the contiguous memory area.
	E.g for stride vs. pitch: http://msdn.microsoft.com/en-us/library/windows/desktop/aa473780%28v=vs.85%29.aspx.
	See also: http://www.gamedev.net/topic/496278-pitch--stride-/.
	For images, it is clear the width is the same as the stride between horizontal edge of the pixels.
		In this sense the width is equal to the stride.
		However, usually only width is used to be clear.
	For image buffers, YSLib uses stride to refer the width in pixels, and pitch to refer the width in bytes, or bits if explicitly specified.
		The meaning of stride is harmonized with Android NDK API.
		The meaning of pitch is harmonized with FreeType.
It seems that ::eglSwapBuffers hangs in SharedBufferStack waitForCondition is a bug of Android platform or underlying Linux kernel.
	See: https://code.google.com/p/android/issues/detail?id=20833.

$2014-06:

report.impl:
There is nothing can be done with "channel '*' ~ Failed to receive dispatch signal.  status=-11" error log message from "NativeActivity" on Android.
	See https://code.google.com/p/android/issues/detail?id=41755.
		From http://ps3computing.blogspot.ca/2012/12/anr-application-not-responding.html.
			From http://stackoverflow.com/questions/18316046/when-build-with-latest-android-ndk-nativeactivity-spams-to-log-on-touch-events.
Behavior changed in ::ANativeWindow after Android 4.0 (API level >= 14), and different way to get native window size should be used.
	See http://www.klayge.org/2013/01/23/%E5%9C%A8android%E6%A8%A1%E6%8B%9F%E5%99%A8%E4%B8%8A%E7%9A%84%E4%B8%80%E4%BA%9B%E5%B0%8F%E9%99%B7%E9%98%B1/.
Call-by-value for parameter with object type for classes types should be refined when the overhead is significant.
	Not all class type object can be passed by value.
	Note that copy elision is not available. See $2014-04 report.impl for references.
	A notable exception is unifying assignment, when copy-and-swap idiom is needed and the move constructor is implemented with little overhead.
		See http://stackoverflow.com/questions/8968452/who-coined-the-term-unified-or-unifying-assignment-operator.
		Because at least one copy operation is performed, the parameter is needed.
		Since the swapping operation is inteneded to provide nothrow guarantee, there should be a nothrow exception-specification.
			Note that even if exception is thrown by initialization of the parameter, the exception-specification is not affected.
		The standard library is not using this style.
			See https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines#specifying-implicitly-generated-special-member-functions.
		For simplicity in YSLib (including YBase), using this style is preferred.
There are multiple issues for IME(Input Method Editor) support in Windows.
	Input methods are supported through IMM32, TSF(Text Service Framework) and CUAS(Cicero Unaware Application Support) APIs.
		IMM32 should be used for most compatibility for desktop enviornments.
			Though it is not supported in Windows Store apps, see: http://msdn.microsoft.com/en-us/library/windows/apps/hh967425.aspx.
		TSF is a new set of API to substitute IMM32.
			Though only supported from Windows NT 6 systems, it can be used and suggested to be used in Windows Store apps by Microsoft.
			It may be superior in features and extensibility.
			It is not only about text input through keyboard devices. Other input methods and natural language technologies are also provided.
				This might cause troubles if only keyboard input processing is intended.
			The API is COM-based.
				This brings some complexity on code usage and library dependencies.
		CUAS is not as common as above other APIs.
			Since the XP tablet is not the target, it is mentioned only for minor subtle issues.
		YSLib now mainly uses IMM32. TSF is a candidate in future if the extra functionality is really needed.
	Asian IMEs of different languages behaves different.
		Now only Chinese IMEs are considered. General support should be added in future.
	Candidate and composite windows may be combined as a single window or not.
		For simplicity, now only the candidate window is directly touched in YSLib.
	Following to text input cursor/caret is a mess.
		All OS versions, IMEs and applications count.
		Different IMEs do not always obey the interface requirement.
			Chinese IMEs might ignore ::ImmSetCandidateWindow calls, so Win32 caret APIs have to be used.
		Behavior are not precisely equivalent. If the cursor switched by mouse when IME candidate window is shown, the IME candidate window can follow the cursor or not.
			For examples, tested with Baidu Pinyin IME 2.10.2.93:
				In contexts concerned with Win32 native edit controls, it follows. These at least include:
					Text fields in native common dialogs;
					Text fields (e.g. combo box to input path, text box to rename a file, etc.) in Windows Explorer except the search box (see below);
					Editor of Notepad;
					Editor of Visual Studio 2013.
					wxWidgets text boxes of Code::Blocks svn9778 in Windows 2012 R2;
				In most other editors, it doesn't. These at least include:
					wxScintilla editor Code::Blocks 13.12 in Windows 7;
					wxWidgets text boxes of Code::Blocks 13.12 in Windows 7;
					Editor of EditPlus 3.60;
					Dialogs and text editor of Android Studio 0.6.1;
					Default editor control, address bar and search box of Firefox Nightly 33.0a in Windows 2012 R2;
				In some other contexts, it just disappears. These at least include:
					Search box in Windows Explorer;
					Search box in Windows Start Menu in Windows 7;
					Search box in Windows Start Screen in Windows 2012 R2;
					Default editor control, address bar and search box of Firefox Nightly 33.0a in Windows 7;
					Editor of MdCharm 1.0 in Windows 7.
				Note in some other contexts, the application is aware of IME with explicit visual effect(e.g. underlines), at least include:
					Dialogs and text editor of Android Studio 0.6.1.
				In Windows 2012 R2, wxScintilla editor of Code::Blocks svn9778 doesn't work at all, even before composing the input string). Seems a bug.
				In Windows 2012 R2, (Qt-based) editor of MdCharm 1.0 and text field in Konversation 1.5 make the candidate window following only when switch fast enough. Seems a bug.
			Currently YSLib chooses a simple implements that behaves like Scintilla of Code::Blocks as default, as well as disablility in Windows 2012 R2.
	See also comments in https://src.chromium.org/viewvc/chrome/trunk/src/ui/base/ime/win/imm32_manager.cc.

$2014-07:

report.impl:
The type of handles varied.
	For the prehistoric era lacking of Documentation::Workflow of YSLib, shell handles are of the opaque handle type 'HSHL'.
	From b175, 'GHHandle<YShell>' took place of 'HSHL'.
		The shell class 'YShell' is the interface, and should not be hidden.
	From b201, 'GHHandle' was renamed to 'GHandle'.
		Because the prefix 'H' was redundant with meaning of the 'Handle'.
	From b210, 'GHandle' was replaced by 'shared_ptr'.
		There was no need to reinvent the wheel of handle type.
		There was also no need to reinvent the wheel of things like 'shared_pointer_cast'.
			Though in Helper::ShellHelper, there are still some historical interfaces available. They are not deprecated, but also to be not encouraged to use.
		The sharing semantics should be explicit, as the interface.
			The 'shared_ptr' is currently an alias of 'std::shared_ptr' introduced by YSLib::Adaptor::YReference.
			Note that is not the reference counting. It is reserved to the implementation.
	Since b243, the base shell class 'YShell' was renamed to 'Shell'.
		Prefix of framework class prefix was restricted.
	As a handle type, directly use of methods of the pointee is not provided.
	However, since the 'shared_ptr<Shell>' is the public interface as well as the shell class itself, use of these method form shell is allowed.
		This rule also fit for types with similiarily explicit use of template-id and type-id, unless otherwise explicitly stated.
	In future, these types are going to be unchanged reasonably, unless some better interface is discussed and used.
Both libstdc++-4.8 and standard library of Microsoft VC++ 2013 have <memory> indirectly including <typeinfo> and <new>.
	This is the implementation details, which is not in the synopsis of the standard. Don't rely on it.
There are some implementation bugs related to std::enable_if.
	For example, in Microsoft VC++, there are several:
		http://connect.microsoft.com/VisualStudio/feedback/details/632440/bug-enable-if-got-c2893-error,
		http://connect.microsoft.com/VisualStudio/feedback/details/811603/weird-behavior-of-std-enable-if-t-produces-c2995-in-visual-c,
		http://connect.microsoft.com/VisualStudio/feedback/details/894682/c-std-enable-if-breaks-within-template-alias.
	In Microsoft VC++ 2013, 'ystdex::exclude_self_ctor_t' or its direct implementation (using std::enable_if_t) would be wrongly ignored.
		This would cause swapping a 'ystdex::pod_storage' leading to infinite recursive calls of constructor template, which makes ystdex::any unusable.
		Currently workaround is not researched, as of the buggy Microsoft VC++ 2013 is still temporaily supported only for successfully compiling YBase, but not for actually working.
	In Clang++, std::enable_if using with template parameter pack trapped into a bug http://llvm.org/bugs/show_bug.cgi?id=11723.
		Workaround: http://stackoverflow.com/questions/24454664/is-there-a-nicer-workaround-for-enable-if-bug-in-clang-bug-11723.
		YSLib didn't be involved in it yet.
For prefix comparison, implementation varies.
	The current implementation of 'ystdex::begins_with' has switched to using 'std::equal'. This gains the chance to be optimized such as using '__builtin_memcmp' in libstdc++.
		Note a length check is necessary.
			For most cases, even the lengths are checked it is even faster.
			The current implementation uses 'ystdex::string_length', which using 'size' member function for instances of 'std::basic_string'. It's generally fast.
	The old implementation implementation of 'boost::starts_with' uses naive comparing. It's stable but considered not as efficient as the method above.
	Comparing using 'std::mismatched' has also been considered. However, it has less chance to be optimized as 'std::equal'.
		For example, libstdc++-4.8 does not dispatching iterator tag to optimize 'std::mismatch' as it does with 'std::equal'.
		For boolean result checking whether the specified prefix exists or not, the position information returned by 'std::mismatch' is unnecessary.
	See http://stackoverflow.com/questions/1878001/how-do-i-check-if-a-c-string-starts-with-a-certain-string-and-convert-a-sub for a variety of implementations.
There are issues about LTO of gcc-4.9.
	See https://gcc.gnu.org/gcc-4.9/changes.html for details.
	Since gcc-ar from MSYS2 distribution has no plugin support, the default object generated by GCC 4.9 is not suited use.
	The flag '-ffat-lto-objects' is set for compatibility like previous version of GCC.
		If not set this option, undefined reference would be found and static linking would fail.
	As a result, the debug configurations have very significantly reduced of output size, i.e. about 1/5 for each binary file of YSLib.
		However, as been tested, GDB can't break in breakpoint any more. So it is still only fit for release configurations.
		See also http://sourceforge.net/p/mingw-w64/mailman/message/32551209/.
The SHBuild tool might encounter 0xC0000005 error.
	This issue probably occurs, may be very often.
	This is abnormal, but has the nothing to do with SHBuild itself. Currently SHBuild builds tasks with only a simple 'std::system' call.
	This issue can be seen if using ConEmu, but not cmd.exe.
		It should be a bug of Windows. See https://code.google.com/p/conemu-maximus5/wiki/MicrosoftBugs.
		Check "Inject ConEmuHk" as workaround, as suggested by the above page.
		Make sure ConEmu has been updated. As tested on Windows 2012 R2, ConEmu x64 140104 doesn't work even with this workaround, but ConEmu x64 140707 works well.
From the source of GCC LTO wrapper, the job server code is hard coded to call make.
	GNU make is actually expected since there seems rare similar support.
	It seems be OK to call with '-flto=jobserver' without GNU make.
On Windows, CPU usage is not the same in performance monitor(perfmon.exe) and task manager(taskmgr.exe). It's the normal case.
	In task manager the CPU usage is often higher than the CPU time in performance monitor.
		System idle process may take much.
	They use different ways. See http://social.technet.microsoft.com/Forums/en/perfmon/thread/0435e7c5-3cda-41a0-953e-7fa462fde03b.
	Task manager is not precise as perfomance monitor. There may have some bugs. See http://windowsitpro.com/windows/jsi-tip-8404-cpu-usage-task-manager-may-be-incorrect.
Distinguishing platforms should be care.
	The platform "Win32" is somewhat fuzzy.
		Win32 is initially for Windows that runs on 32-bit IA-32 or x86 systems.
			For example, Intel 80386.
				The perhaps most common architecture name correspondingly called "i386" on UNIX-like systems, but now superseded by newer like "i686", and Linux (which is initially targeting i386) dropped i386 support.
		Then Win32 also runs on systems being compatible with them, subsequently AMD64 and Intel EM64T, collectively called "x86_64" as the architecture name, or simply "x64".
		But "32" in "Win32" is not truely only describing the CPU architecture.
			Win16 can be run on Win32 by WOW(Windows on Windows), so a program targeting Win16 can still run on Win32. The 32-bit x86 is backward compatible with old 16-bit architecture, this is a necessary but not sufficient condition.
				The "system" directory of Win16 is called "system32" on Win32.
			What a Win32 program runs is called Win32 subsystem in Windows NT.
			And similarly, Win32 programs can be run on Win64, not only attributing to backward compatibility of x86_64 with x86.
				The "system" directory of Win64 is still called "system32", and it is still in Win32 subsystem.
			Win16 support has been abandoned by Win64.
			Windows on IA-64 (Itanium) do not be compatible with x86 Windows, but they might be also called "Win64".
			Windows on non-Intel platforms (i.e. ARM) are significantly different (as runtime environment), though they are also on 32-bit architecture (and Win32 subsystem), they are normally not called "Win32".
		Microsoft VC++ and some other C/C++ implementations predefined some macros to identify the system.
			The macro "_WIN32" is both defined for Windows versions targeting x86 and x64.
			The macro "_WIN64" is only defined for Windows versions targeting x64.
		Things even more complicated for MinGW platforms.
			MinGW is short of "minimal GNU on Windows", forked from Cygwin (Cygnus POSIX-compliant platform on Windows).
				It is firstly a set of GNU tools.
				Then a runtime.
				And finally a set of toolchain targeting x86 Win32, mostly identified as "i686-pc-mingw32", differentiated with Cygwin's "i686-pc-cygwin".
				It is not devoted for POSIX compliance like Cygwin does, but literally like "minimal", a workable environment to use GNU tools.
			Because unwilling of supporting x64 Windows targets, someone forked MinGW and named it MinGW-W64.
				The "w64" is the vendor name, but not the architecture name.
				The "32" in "mingw32" is also kept, and it is also not the architecure name.
				Things like "x86_64-w64-mingw32" seems to be a little weird, but it should be clear only the first one of triplet indicates the architecture.
			To not being confused, the original MinGW is called "MinGW.org".
				The base features are mainly compatible, though may be with different quality.
				The two library has different implemenation details and feature set in minority.
					For example, MinGW.org support BSD-variant "DT_*" macro while MinGW-W64 not.
				Currently they are both maintained, but by different people.
				Only MinGW-w64 is officially supported by GCC team (though as a secondary platform). The leader maintainer, Kai Tietz, has the commit permission of the official GCC repository.
				MinGW.org runtime is mainly maintained by Keith Marshall.
				They don't think same, e.g https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015.
				For generally use, MinGW-W64 is recommended by YSLib.
				See also $2014-01 in this document.
			The MinGW-w64 targeting both x86 and x64 Windows. There even exists mixture, i.e. multilib support, or cross-compilers between x86 and x64 Windows editions.
			Do not be confused with MSYS.
				MSYS stands for "minimal system".
				It's larger than MinGW generally. It has shells and other base library dependencies (e.g. the MSYS runtime).
				Comparing to MinGW, it is more like Cygwin and a little heavyweight.
					MSYS shared code from Cygwin as the upstream.
					MSYS2 is more like Cygwin than original MSYS.
				The target triplet is also different, like "i686-pc-msys".
				To build and deploy programs in Windows, MinGW comes first rather than MSYS. Only when the compatiblity concerns, use MSYS might be proper.
			For MinGW targets, there are also predefined macros.
				The marco "_WIN32" and "_WIN64" are supported on both x86 and x64 editions of Windows and x64 Windows only, respectively.
				Similarly, there are macros "__MINGW64__" and "__MINGW32__".
					The macro "__MINGW32__" is supported by variety versions of MinGW like "mingw32" system name does.
					The macro "__MINGW64__" is only supported on x64 Windows with MinGW-W64.
		To detect these platforms by conditional macro definitions, the order is significant.
			The macro "_Win64" should be prior to "_Win32".
			Same as "__MINGW64__" to "__MINGW32__".
	To reduce misconception of MinGW platforms, the macro "YCL_MinGW" is now used to identify all MinGW platforms.
		As other macros "YCL_*" representing a general feature set, but not identifying the concrete platfroms.
		Old macro use of "YCL_MinGW32" should be smoothly migrated by simple renaming, because no significant difference is ever depended on.
		On the other hand, the macro "YCL_Win32" is not renamed to "YCL_Windows" or "YCL_Win", because Win32+Win64 are just not the whole world of Windows.
	The macro "YF_Platform_*" are still used for denoting the concrete platforms.
	The platform extension is for concrete platfroms.
		So no change should be made on directories.
			Just create "MinGW64" for new MinGW64 files.
		However, the header "MinGW32.h" might be migrated for all MinGW platforms in future. Other header may be shared for other Windows platforms.

$2014-08:

report.impl:
Initialization should be cared.
	There are several changes in ISO C++1y for initialization.
		For value-initialization, as per WG21 N3936, from the resolution of CWG 1301, the explicitly defaulted default constructors (declaring with '= default') are considered to ensure zero-initialization for classes without default constructor.
			See http://wg21.cmeerw.net/cwg/issue1301.
			It differentiates with explicitly deleted constructor (declaring with '= delete') or user-provided ones.
			Note for ISO C++11, The '= default' is not enough to ensure a value-initialized with no unitialized non-static data members. This is not intended.
			It seems G++ 4.8 and Clang++ 3.3 have implemented it, see http://stackoverflow.com/questions/24043897/c11-value-initialization-with-defaulted-default-constructor.
		List-initialization was also effected by CWG 1301.
			Aggregate initialization takes the first place for aggregates despite of default constructor.
			See http://stackoverflow.com/questions/23882409/c14-value-initialization-with-deleted-constructor.
	Note it is not enougth for arbitrary class type objects (even with '= default' constructor) using member declaration as 'T x{}' to ensure initialized.
		The defaulted default constructor does not ensure performing initialization for each data members in subobjects.
			As per WG21 N3936 8.4.2/5, the definition an explicitly defaulted special member function shall be provided as implicit definition.
			As per WG21 N3936 12.1, the implicitly defined default constructor performs initialization would be performed by a user-written default constructor for that class with no ctor-initializer and an empty compound-statement.
			As per WG21 N3936 12.6.2/8, a non-static data member without brace-or-equal-initializer in class definition and no mem-initializer in ctor-initializer can be default-initialized, which can be with no initialization at all.
		For example, when 'T' is 'std::atomic<int>'.
			Since it is explicitly stated "in an uninitialized state" in 29.6.5/4 in ISO C++11 and WG21 N3936, for ISO C compatible semantics.
	There are still ways to avoid redundant initiliazation of member data for default-initialization and value-initialization via default constructors (but perhaps not copy initialization).
		Several cases are significant, e.g. for containers as buffer.
			Since containers using allocators to construct elements, and at least the default allocator uses value-iniitialization to construct object, so it effects.
			Another solution is to provide user-provided allocators which provides 'construct' overriding the default implementation to eliminate unnecessary initialization.
				But this has effect on the container types, and may be not obvious enouth.
		The element type should usually be a class type declared like 'struct T {D data; T(){}};' where the data type D meets the requirements for container elements.
		This is somewhat complex but still feasible for many cases.
			However, G++ can produce code to perform zero-initialization.
				At least for 4.8.2 and 4.9.1, specifying the optimization option '-Og', '-O1' or above. But '-O0' is expected.
				It is not clear whether this behavior is intended.
The "template-parameter" can be a "template-parameter" thus being declared with "brace-init-list" in default argument for non-type parameter, but no similar synax is allowed for "template-argument".
	This is inconsistent, but precisely defined in ISO C++.
	Clang++ 3.4.2 still wrongly rejects the use of '= {}' for template non-type parameter 'bool' at template declarations. The diagnostics reads "expect expression".
It is intended to make the strong exception guarantee wider in whole YFramework::YSLib.
	All APIs should meet the basic guarantee, i.e. no resource would leak.
	However, currently not all APIs are convinced to be.
	Thus only GUI rendereing is documented as meeting the strong guarantee after reimplemented 'TextBox::Refresh' which could previously make the 'Text' property unspecified after an exception threw.
For types satisfying 'CopyConstructible' and 'Swappable' requirements but not 'CopyAssignable' requirement, a wrapper could be used to support additional assignment operation.
	For example, the closure types.
	See http://stackoverflow.com/questions/12672372/boost-transform-iterator-and-c11-lambda for example of usage.
	If 'Swappable' requirement is supported for the type, copy-and-swap idiom can be used to ensure strong exception safety guarantee.
	Otherwise, 'std::ref' can be used for local variables of type lacking of 'CopyAssignment' requirement support, as a workaround when the support is needed to be properly used.
		For example, like transformer of the 'boost::transform_iterator' or 'ystdex::transformed_iterator'.
Though it might probably a problem for 'std::make_shared' to enlarge the binary size of a file, but this is an implementation-specific problem.
	It seems now this has little impact on devkitPro r42 with optimization enabled.
	Thus the interface should be simpler.
	On the other hand, 'std::make_shared' providing opportunity to optimize the allocation, which is not done by naive 'new' and constructing.
	The 'ystdex::make_shared' is now only providing an extra overloading for instances of 'std::initializer_list' as parameter.
A bug found in 'FetchStringWidth' of module 'YSLib::Service::TextLayout' in YFramework of b529.
	Wrong behavior is only observed behavior for release builds on menu widths.
		The 'release' configuration (statically linked) in platform 'MinGW32' shows a large with. All other release configuration seems to suggest a zero value of width.
	The reason is not clear and not further investigated yet.
		The libstdc++ code seems to be OK. Perhaps there are bugs in 'ystdex::make_transform' and so on, or there are bugs concerned with optimized code generation of G++.
Function 'cbegin' and 'cend' are preferred to 'begin' and 'end' in some cases.
	They are expected to return an iterator to indicate boundary of a range.
	These functions, as well as instances of corresponding function templates defined by ISO C++ [iterator.range] since C++11, are collectively for range access.
		Note 'cbegin' and 'cend' are defined since ISO C++14.
	The type of accessed range usually meets Container requirements.
		Instances of 'std::initializer_list' are excluded.
	Note that 'begin' and 'end' are usually 2 overloaded functions respectively.
		One is for const-qualified range, and the other is for cv-unqualified range.
		The 'auto' keyword cannot deduce the const-qualified version for cv-unqualified range.
	The 'cbegin' and 'cend' are only expected for const-qualified range.
		The 'auto' keyword is OK to deduce for const-unqualified range.
	In general, 'begin' and 'end' are friendly in compatibility aspect.
	However, 'cbegin' and 'cend' may be more precise and clear to show the intent.
	For associative containers, ISO C++ [associative.reqmts]/6 explicitly points out the 'iterator' and 'const_iterator' type can be same, and one can always use 'const_iterator' to avoid ODR violation.
	When the iterators indicating the range boundary are needed, the general rules are:
		Only use qualified-id of these names when really necessary.
		When using non-members, names with ADL (unqualified-id) are preferred.
		For range typed by type parameter in a template or in a macro, non-member templates are always preferred to member functions; otherwise, member functions are always preferred than non-member templates.
		For range typed by type parameter in a template or in a macro, if range with no 'cbegin' or 'cend' are intended to be excluded (e.g. SFINAE), 'cbegin' and 'cend' shall be used.
		Otherwise, if there is no 'cbegin' and 'cend' available, or non-const iterator is explicitly needed, 'begin' and 'end' shall be used.
		Otherwise, for implementation of functions by directly forwarding calls, corresponding names shall be used.
		Otherwise, 'cbegin' and 'cend' shall be used.
	There may exist some bugs for implementations.
		For example, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278.
		Use 'begin' and 'end' instead of 'cbegin' and 'cend' as workaround when necessary.
English allows bare passive clause, which omits the auxiliary verb (typically 'is').
	See http://en.wikipedia.org/wiki/English_passive_voice.
	In YSLib, for English passive voice in assertion strings or titles, this form is preferred to canonical form (e.g. "file not found"), even in a separate sentence.
	For formal descriptions otherwise, auxiliary verbs should not be omitted.

$2014-09:

report.impl:
There is some confilicts in 'ForwardIterator' requirements onwards ISO C++11 with some iterator adaptor implementations.
	It requires that the iterator shall satisfy the 'DefaultConstructible' requirements.
		If the underlying iterator does not satisfy 'DefaultConstructible', it is hard to implement efficiently.
			However, if the underlying iterator does not satisfy 'ForwardIterator' requirements, an explicitly defaulted default constructor is enough.
	It requires that the 'reference' member should be a reference type.
		This is generally hard to implement for underlying iterator does not store a long-lived object as result.
		For example, 'boost::transform_iterator' is not strictly conforming to this.
			See $2014-08 for other issues related to iterator requirements and 'boost::transform_iterator'.
		This is a currently known problem, but not treated as a defect. See http://wg21.cmeerw.net/lwg/issue2107.
	To reasonably resolve these problems, 'ystdex::transformed_iterator' in YBase::StandardEx::Functional now provide a third template parameter to allow the user to specify the 'reference' type.
		If not explicitly specified, default argument 'void' is used, like 'use_default' in Boost iterator library.
			Note now it is not conforming to ISO C++ if 'ForwardIterator' requirements are required and the default argument is used.
		It is convenient and efficient for users to pass a callable object returning an object (rather than reference to a long-lived object) as transformer in default cases.
Keys of associative containers are const-qualified.
	This means they are usually readonly.
	It is important to make the strict weak ordering stable to guarantee the container to work.
	Nothing implied it would be OK to 'const_cast' it and back even the order is maintained. The implementation is free to cache the keys.
	The key is not free to modify. It leads to several problems.
		See http://stackoverflow.com/questions/3884572/how-to-modify-key-values-in-stdmap-container.
			This is also the same problem met in implementation of tree list in YFramework::YSLib::UI.
		See http://wg21.cmeerw.net/lwg/issue839 and http://wg21.cmeerw.net/lwg/issue1041.
		See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3645.pdf for proposal to resolve this issue (but not in the current standard).
		See http://stackoverflow.com/questions/5743545/what-is-the-fastest-way-to-change-a-key-of-an-element-inside-stdmap for the problem and the status of the paper above.
		The available resolustion are:
			First, to erase and re-insert the value.
				See http://stackoverflow.com/questions/3884572/how-to-modify-key-values-in-stdmap-container to the first method.
				This is generally not efficient for multiple keys/values.
				Function template 'ystdex::replace_value' has already reflect this resolution.
				Anothor implementation is http://www.codeproject.com/Articles/36326/How-To-Update-Your-Const-Key-Fields-in-a-Map-Multi. It is not preferred to 'ystdex::replace_key' because:
					It is for a range rather than a single element, so generally less efficient.
					It is limited to map types.
					It explicitly use 'key_comp'. This is unnecessary.
					It is for pre-ISO C++11, so no 'emplace_hint' is used to perform better.
			Second, to construct a new container then copy or move the elements e.g. by 'std::move'.
				See http://stackoverflow.com/questions/9585083/how-to-move-all-pairs-from-one-stdmap-to-another for examples.
				This is generally more efficient than the first method.
Implementations of clocks are cared.
	For Windows systems, QPC is preferred for high resolution uses.
		The related Windows APIs are fit for Windows 2000 or later, e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx.
		See http://stackoverflow.com/questions/22942123/is-queryperformancefrequency-acurate-when-using-hpet for some reasons.
		See http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx for deteils.
		For Windows 8, the RTC is buggy to be reliable for overlocking benchmarking.
			See http://hwbot.org/news/9824_breaking_windows_8_benchmark_results_no_longer_accepted_at_hwbot/.
	In current libstdc++ (in inline namespace 'std::chrono::_V2' or somewhat earlier), the static 'now' function of clocks in <chrono> uses different configurations.
		The 'std::high_resolution clock' is alias of 'std::system_clock'.
		For 'std::system_clock', if '_GLIBCXX_USE_CLOCK_REALTIME' is not defined, it uses fallback 'std::time' call.
		For 'std::steady', if '_GLIBCXX_USE_CLOCK_MONOTONIC' is not defined, it uses one in 'std::system_clock'.
		Otherwise, both are implemented as following, respectively:
			If '_GLIBCXX_USE_CLOCK_GETTIME_SYSCALL' is defined, it is implemented as a system call.
			Otherwise, 'clock_gettime' is used.
		The libstdc++ for MinGW-W64 is implemented on top of 'clock_gettime' with corresponding clock id ('CLOCK_REALTIME' or 'CLOCK_MONOTONIC') in winpthreads.
			The winpthreads implementation uses different Win32 APIs to implement 'clock_gettime' for years.
				For 'CLOCK_REALTIME', 'GetSystemTimeAsFileTime' is used.
				For 'CLOCK_MONOTONIC', QPC APIs are used.
				For 'CLOCK_PROCESS_CPUTIME_ID', 'GetProcessTimes' is used.
				For 'CLOCK_THREAD_CPUTIME_ID', 'GetCurrentThread' is used.
				So it should be resonably high accurate at least for 'std::steady_clock' in <chrono>.
			It is tested to be significantly worse than 'boost::chrono' (using QPC APIs) on accuracy with 'i686-4.8.2-release-win32-dwarf-rt_v3-rev0.7z' even using 'std::steady_clock'.
				See http://sourceforge.net/p/mingw-w64/mailman/message/31672495/.
				However, the zero results can not be reproduced on Windows 2012 R2 x64 machine with current MSYS2 GCC 4.9.1.
					But it can be reproduced using 'std::system_clock' instead of 'std::steady_clock'.
					As per the libstdc++-v3 source in GCC repository, the reason seemed to be the 'std::steady_clock' is an alias before 'std::chrono::_V2' was introduced.
				See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 for the issue.
			As a side note, function '_pthread_time_in_ms' around inside winpthreads, which used '_ftime'.
				It is improved by a recent update in git master branch of MinGW-W64 winpthreads repository at 2014-09-27 02:00:15: "winpthread: use GetSystemTimeAsFileTime instead of _ftime".
					Quoted: First, _ftime is not present in all msvcrt versions, then, _ftime is the "current local time".
					The modified function was "_pthread_time_in_ms".
					This is certainly not updated in released version of MinGW distributions.
	See also http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking#GetSystemTimeAsFileTimeandGetsystemTimePreciseAsFileTimenbsp for variable interfaces of getting the real time suited for benchmarking.
	YFramework implementation for getting real time in Windows is adjusted.
		Whether the timers in ISO C++11 standard library are usable or not, at least the multimedia timer APIs are no longer needed because the mainly targeting systems are rare to be the exception cases. So it is now removed.

dep.merge:
Boost.Trie(https://github.com/ithlony/Boost.Trie): tentatively rejected.
	This is a project of Boost GSoC 2013.
	Despite the whole Boost had been rejected before($2012), it was probable to be accepted to merge. However, it is not proper now.
	It is not being actively developed for months.
	It was considered not peer review ready, see https://groups.google.com/d/topic/boost-devel-archive/KjerA9jlLbo for some details.
	There seems to be no documentation ready.
		No stable interface is clearly stated.
		No characteristics like complexity is clearly stated and ensured.
	The standard container like 'std::map' are used directly in the data structure as members.
		Though acceptable, just a note: many operations would be limited by the QoI of the standard library.
		Many operations would be more expansive than standard library calls, and often beated the purpose to introduce a trie (to replace a 'std::set' or 'std::unordered_set', etc).
		It is also not very memory-efficient, e.g. duplicate node sizes were stored.
tx-trie(https://code.google.com/p/tx-trie/): rejected.
	It is not being actively developed for years.
	It is for paticular string type and not templated.
	There exists quality problems, e.g. macro names pollution, directly used unqualified-id of C standard library functions, memory allocation, etc.
marisa-trie(https://code.google.com/p/marisa-trie/): considerable, tentatively shelved.
	It has some similar problems of interface like tx-trie. However, it seems to be fit for other use.

$2014-09:

report.impl:
Now ar from MSYS2 supports linker plugin.
	So removed '-ffat-lto-objects' option for compiler by defualt and use 'gcc-ar' to replace 'ar'.
		If use 'ar' with '-flto' enabled there would still be unresolved symbols.
	See $2014-07 for previous details.
Multiple tap operations are studied.
	This is ordinarily called "click".
		However, multiple click is often triggered at last tap down rather than up, like in Windows desktop or text controls.
		Otherwise it can be triggered on subsequent tap up events, e.g. image preview in Tencent QQ.
	The behavior may differs across platforms, see http://en.wikipedia.org/wiki/Double-click.
	For Windows, this is primarily for mouses. See register path: HKEY_CURRENT_USER/Control Panel/Mouse for settings.
	There is an area setting for allowed error with initial tap with subsequent ones.
		However, sometimes this is ignored and only precise subsequent (without any move) taps are allowed to avoid collision with dragging operations, e.g. for text selection.
	Triple click is to select text in a line in general, and mostly used by browsers and text editors, see http://en.wikipedia.org/wiki/Triple-click.

$2014-10:

report.impl:
There is a bug on DST(daylight savings time) calculation on Windows CRT call of 'stat' family across file systems.
	This can cause strange bugs on file system caching.
		See comments in "src/fcstat.c"(previously in "src/fccache.c") from the FontConfig project(http://www.freedesktop.org/wiki/Software/fontconfig/).
		See https://bugzilla.gnome.org/show_bug.cgi?id=154968 Comment 30, also https://bugs.freedesktop.org/show_bug.cgi?id=8526.
	See http://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting for details.
	See http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx for other general information.
	New CRT source "fstat.c" and "fstat64.c" from Microsoft VC++ 2013 shows that the implementation has been changed.
		The Win32 API 'FindFirstFile' was not used any longer.
		Also the code for Window Store App uses different APIs for time conversion.
			'FileTimeToSystemTime' and 'SystemTimeToTzSpecificLocalTime' was used instead of 'FileTimeToLocalFileTime' and 'FileTimeToSystemTime'.
				It is reasonable because some APIs is not available.
			It is uncleay why the desktop platform did not use these functions.
				These functions seems to be having good compatibility with enough precision.
				The possible difference of behavior between these platforms are to be investigated.
There are issues which make the flattened object files hardly be linked directly.
	The linked '.a' files are not the same as '.o' files.
		For statically linking they are OK.
		GNU ld complains about there is no index when trying to generate a DLL.
			Even after explicit 'ranlib' call, the result is the same.
			However, an archive linked directly with '.o' has no such problem.
	GNU ar supported linker script.
		See https://sourceware.org/binutils/docs/binutils/ar-scripts.html#ar-scripts for usage.
		It can be used to workaround this problem, but still cumbersome with limitation, e.g. no '+' can be in the name or the '.a' file.
		See also https://lists.gnu.org/archive/html/help-make/2008-03/msg00043.html.
	Thus it should generally directly be avoided. Direct use of '.o' to build shared library is preferred.
		The performace is also significantly better for directories containing a few source files, because less archives should be built and waiting before linking can be reduced.
Sometimes 'LANG=C' should be expicitly specified in the command line to prevent corrupted output from some tools built without NLS support.
	For example, 'ar' from MSYS2 does not play with zh-CN locale well, while 'gcc-ar' has no problem.

$2014-11:

report.impl:
There should be general no explicit exception-specification for destructors. However, exceptions of this rule are also allowed.
	In gerenal, throwing an exception in a destructor is thought to be bad practice.
		It would terminate the program during stack unwinding.
		There is no good way to distinct it in the implementation of a destructor.
			See http://www.gotw.ca/gotw/047.htm.
		ISO C++ standard library follows this practice by Destructible requirements which explictly forbids exception exceptions propagated out of the destructors.
	However, if the assumption of never throwing exception in stack unwinding is true, this is somewhat acceptable.
		See https://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/ and http://www.kolpackov.net/projects/c++/eh/dtor-1.xhtml.
		The root reason is that destructors are not necessarily used in RAII style.
		To be simple, this should still be avoid in most cases: do use destructor to reclaim resources but not to perform arbitrary operations.
	In ISO C++11 there is a subtle change in implictly specification for destructors.
		See https://akrzemi1.wordpress.com/2013/08/20/noexcept-destructors/.
		Do explicitly specify 'noexcept(false)' to allow throwing in destructors, if ultimately needed.
	WG21 N3166 proposed to add noexcept specification on destructors by default.
		This is not accepted by ISO C++11.
Note the 'std::reference_wrapper' is not equal to 'boost::reference_wrapper'.
	The latter is simpler. 'std::reference_wrapper' has more interface about nested types and 'operator()', thus it needs a compelete type as template argument, otherwise the behavior is undefined.
		See https://groups.google.com/a/isocpp.org/forum/?_escaped_fragment_=topic/std-discussion/_tavlfXkOrc#!topic/std-discussion/_tavlfXkOrc.
	Currently G++ 4.9 with libstdc++ allows the invalid use and would not detect the ODR violation.
	Microsoft VC++ denies this use with subtle diagnostics.
		See https://connect.microsoft.com/VisualStudio/feedback/details/750448/std-reference-wrapper-fails-with-undefined-types.
	YBase now has introduced 'ystdex::lref' to simulate 'boost::reference_wrapper' allowing incomplete type as template argument, among with 'ref' and 'cref'.
		Only limited interface is supported.
			Standard library interface inconsistent with incomplete template argument are not supported.
			Boost specific member 'get_pointer' is not supported.
			Specialization of 'wrapped_traits' is added.
			Constructor has overloaded to support conversion from 'std::reference_wrapper'.
				This allowed both instances of 'std::reference_wrapper' and 'ystdex::lref' to be the function argument type.
				To minimize dependencies, no further conversions is supported specially.
				If more generic interface is needed, SFINAE with 'ystded::wrapped_traits' can be used.
		The declaration 'ystdex::lref' is introduced in namespace "YSLib" by using-declarations in YSLib::Adaptor::YReference unconditionally. However, the 'std::ref' and 'std::cref' are not quite same.
			They clashed with names in 'std'.
			In library code they should be always used with qualified prefix, otherwise the ADL can make troubles when the behavior of found entity are not equivalent as expected.
				Note 'ystdex::ref' and 'ystdex::cref' are different with 'ystdex::make_*' for smart pointers.
					The latter ones are overlapped with their 'std::' counterparts (if any) because they exposing same kind of functionality and return same expected types.
					The use cases in templates where the ADL effects are rare. Even in these cases, prefix can be explicitly used.
					The difference about prefix in semantics is implementation details rather than interface requirements.
			They are easy to misused to construct a 'ystdex::lref' and passed it to function templates which only handles 'std::reference_wrapper' specially.
				For examples, as 'std::bind' arguments or 'operator()' is used. In these cases the 'std::' should be used explicitly.

$2014-12:

report.impl:
Keyboard input processing is complicated. There are a few key codes on Linux as options.
	See https://www.berrange.com/tags/key-codes/.
	See https://stackoverflow.com/questions/8737566/rolling-ones-own-keyboard-input-system-in-c-c.
Convention of term "stride" used by XCB image is coordinized with YSLib. (See also $2014-05.)

////

