﻿/*
	© 2015-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.Annual2015.txt
\ingroup Documentation
\brief 工作流汇总报告 - 2015 年度。
\version r525
\author FrankHB <frankhb1989@gmail.com>
\since build 564
\par 创建时间:
	2015-01-02 09:40:31 +0800
\par 修改时间:
	2016-06-08 11:58 +0800
\par 文本编码:
	UTF-8
\par 模块名称:
	Documentation::Workflow::Annual2015
*/

// 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.

$2015-01:

report.impl:
Note that 'va_args' and 'va_end' cannot be encapulased using RAII/RRID.
	ISO C explicitly specified they shall match in a function.
	Since constructor and destructor are functions, they can not be used.
UAC is annoying for program which aquireing no administrator privilege but containing some patterns in file name e.g. 'patch.exe' or 'install.exe'.
	See https://github.com/bmatzelle/gow/issues/156.
The function 'std::quick_exit' is mostly a workaround of cleanup when the thread cancellation is not supported in C++.
	See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2440.htm.
	Do not register callbacks through 'std::at_quick_exit' unless the states of threads are all known.
		Note these callbacks shall not raise signals according ISO C11, otherwise the behavior is undefined.
	The similar thing also fit for 'std::exit' and 'std::atexit'.
		However, it is generally more difficult to avoid.
		In fact, current libgcc exploited 'atexit' to make the destructors to be called.
Win32 console would call 'ExitProcess' by default during window close or handling 'Ctrl+C', etc.
	See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx.
	This might probable not preferred because this call would mostly make the C/C++ runtime a mess.
	This call can inform the loaded DLLs to be terminated, but also might lead to deadlock when DLLs are not used properly.
	A clean call of 'TerminateProcess' on current process would be better if not all states of each thread are known.
		However, it would not touch the C/C++ runtime states, either.
	So C/C++ standard library functions or other runtime functions are generally preferred for C/C++ applications.
		Use 'SetConsoleCtrlHandler' function to change default behavior for the attached console.
			See http://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx.
		YSLib now use it to workaround the unexpected behavior.
			The exit code 'STATUS_CONTROL_C_EXIT' is used for 'CTRL_C_EVENT' and 'CTRL_CLOSE_EVENT' to retain old behavior.
			For 'CTRL_BREAK_EVENT', 'CTRL_LOGOFF_EVENT' and 'CTRL_SHUTDOWN_EVENT' the same code is used, but not tested to be the same as original one.
Since 'ystdex::nptr' is exactly a wrapper but not a smart pointer, it is intended in <ystdex/utility.hpp> but not in <ystdex/memory.hpp>.
The function 'isatty' on POSIX compliant environments and '_isatty' is not the same.
	For POSIX compliant environments, '::isatty' returns whether the file descriptor is associated with a terminal.
		See http://pubs.opengroup.org/onlinepubs/009695399/functions/isatty.html.
	For Win32, '::_isatty' returns whether the file descriptor is associated with a character device.
		See http://msdn.microsoft.com/en-us/library/f4s0ddew.aspx.
	Use Win32 APIs to achieve the functionality of POSIX compliant 'isatty'.
		See http://stackoverflow.com/questions/3648711/detect-nul-file-descriptor-isatty-is-bogus.
	However, both function can exclude some cases not fit for terminal output.
Move-only parameter passing counts.
	See the discussion at http://scottmeyers.blogspot.com/2014/07/should-move-only-types-ever-be-passed.html.
	Both 'T&&' or 'T' have cases. The former is probable more efficient and debugger-friendly, while the latter is simpler (both on coding and behavior).
		For 'T&&', the extra move is delayed to the client code. And there is possible to not move (or even not use) the argument at all.
		For 'T', the move operation is mandated by copy-initialization of the parameter.
	The implicit coding rules used by YSLib are not documentated then, so here is the summary.
		To use mandated move on certain move-only types which has predictable and acception perfomance on the move operation (e.g. instances of 'std::unique_ptr' with default deleter), 'T' is preferred.
		Otherwise, 'T&&' should be used.
	These cases was attented at long before.
		At least in September 2014, these rules were adopted.
			This is reflected by the modification on Documentation::CommonRules (Mercurial changeset 406, build 534; now Documentation::LanguageConvention).
			However, no actual code modification was taken (e.g. on 'YSLib::UI::Widget::SetRenderer').
		These rules are now updated to be more explicit in Documentation::LanguageConvention.
		In fact, 'YSLib::UI::Widget::SetRenderer' was modified in May 2013 (Mercurial changeset 278, build 406) for probable the same rules.
		Now 'YSLib::UI::Widget::SetView' is synchronized to be consistent. Both these functions needed the object of 'unique_ptr' instance always being used.
	For non move-only type, see $2014-04.
The duration (and potentially other instances of 'std::chrono' time types e.g. time points) parameters are now passed by value rather than by reference.
	In general, The default argument binding to reference type of parameter causes odr-used of the argument.
		If the argument is a static data member of class, either declared with const, constexpr or not, an extra definition out of class definition is required to obey ODR, otherwise the program is ill-formed.
		This is necessary by intention. Only value is actually used so lvalue-to-rvalue is expected, and odr-use is not required.
	To elimination the requirement of extra definition, parameter of object type can be used directly instead of parameter reference type.
	However, the static data member of literal types designated with constexpr are used (rather than integral or enumeration types) it might not work.
		To be a constant-expression it should be a non-volatile glvalue performed lvalue-to-rvalue conversion.
			This is required "immediately" by ISO C++11.
			The requirement is relaxted by new working draft, but not all issues are resoved now.
			See http://stackoverflow.com/questions/23491781/when-is-a-variable-odr-used-in-c14.
		Implementations like MinGW G++ 4.9.1 or Clang++ 3.5.1 with both '-std=c++11' and '-std=c++14' are actually not treated them as constant expressions for such use, so the definition are not removed tentatively now.
		See WG21 N4296 5.20/2.7.1 about use for integral or enumeration types.
	For instance of duration used directly in YFramework, the underlying arithmetic types are predicatable, so the costs are generally known and acceptable.
		This may differ in the standard library or other cases (e.g. YBase), which use const lvalue reference of templated object types.
	To be consistently, all parameters use the same form.
	This is not necessary the case of 'YSLib::Drawing::Point' and other types of geometry in YFramework (esp. the cost of copy an object of 'YSLib::Drawing::Rect', for consistency in style), so they are not touched.

$2015-02:

dep.merge:
df.operators(https://github.com/d-frey/operators): partially merged.

report.impl:
The '+' or '+=' expression concerned with random access iterators should be noticed.
	ISO C++ has not required that the preconditions for these operations. However, this check is by original design.
		See http://www.sgi.com/tech/stl/RandomAccessIterator.html#1.
	Note out-of-bound pointer arithmetic is undefined behavior.
		See http://stackoverflow.com/questions/10473573/why-is-out-of-bounds-pointer-arithmetic-undefined-behaviour.
		Since the algorithms implemented to support random iterators are usually allowing pointers, it should be cautious to use these operations.
		Unless otherwise explicitly specified, YSLib uses the strict strategy, i.e. the code shall not use these operations to perform undefined behavior, unless the pointers are prevented to be instantiated intentionally.
		YBase also uses some strict boundary check (esp. assertions) on these operations in implementation of iterators.

$2015-03:

dep.merge:
OpenImageIO(http://www.openimageio.org/): tentatively rejected.
	This is a library focused on image I/O.
		It actually does more, e.g. provides some ISO C99 math functions and POSIX math macros, implementation of 'array_view', etc.
		It embeds some 3rd party code to support XML, SHA1, etc.
		It also encapsulates some system-dependent operations, e.g. threads.
			The threading operations depend on Boost.Thread.
		Its interface is in C++.
			This is good to avoid name clash.
			However, the quality is not always good.
				Error handling totally bypassed exceptions (except for throwing 'std::out_of_range' from 'array_view', etc), and uses thread-specific state instead.
					This is of generally bad style and can be hard to use.
			Sometimes the interface is necessarily bloated, e.g. 'ParamValueList' can actually be an type alias rather than a class.
		The headers are a bit mess.
			There are multiple headers in the same directory doing different works. Not all of them are aiming to image I/O.
			It is somewhat difficult to use it cleanly directly without referencing some use cases.
	The license is 3-clause BSD-like.
		Though 2-clause would be better, it is good to use.
	The binary code of static library is even slightly larger than that of FreeImage for MSYS2.
		It is in doubt to shrink without giving up some functionality.
	It is lacks of GIF support, which is used by YFramework.
		So at least at current, it can not replace FreeImage.

report.impl:
In general, the key state in the event argument of 'KeyDown' event should not be modified in the handler.
	Call of 'GUIState::UpdateChar' would once modify it.
		The key set was combined of multiple keys, which was modified by checked held state.
		This was wrong for a 'KeyDown' event not called by 'KeyHeld' handler.
		Class 'TextBox' was effected. It would occasionally behave normally if the key of least key index was pressed down at last.
			Since the key was determined by the first key index in the key set through call of 'FindFirstKeyInCategroy'.
			For example, right arrow after left arrow would be treated as left arrow but right arrow after left array would be normal, if the key index of the left arrow key is less than the one of right arrow key, which is the case of Win32 and many other platforms.
Be cautious with revision patcher script. Currently the pattern of reversion is hard coded.
	Only certain version number pattern is supported.
		Some versioned files like makefiles should still going to be maintained manully.
	Be cautious with the lines area counts.
		Most files are with the '\version' in first 20 lines, only 3 files are the exceptions: YBase::YDefinition, YFramework::YCLib::YModules, Tools::PredefinedMacroDetector::Main.
		All of them are not touched since the script was used.
		So nothing had been going wrong.
		Set 'PatchEnd' variable when necessary.
			The default value has been adjusted to '30' instead of '20' to cover all of current source files.
	Now version number pattern is restricted to mandate a prefixed number character in the version number.
		Thus the script it self would not be affected even the 'PatchEnd' is set to 30. It should also work for the readme file.
The Clang++ warning '-Wweak-vtables' is mainly for compiling performance.
	See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/024020.html.
	See also http://stackoverflow.com/questions/23746941/what-is-the-meaning-of-clangs-wweak-vtables.
	G++ behave similarly, but Microsoft VC++ does not.
		See http://stackoverflow.com/questions/12024642/placing-of-external-virtual-tables.
	It is enabled by '-Weverything'.
	For client code this might be not important, so no problem to disable.
	However, for libraries with a lot of translation units or being depended deeply, it is better to turn it on.
		YSLib libraries should use these flags if possible.
		YFramework interface type now requires out-of-line destructor provided by user.
		Note to avoid '-Wdeprecated' warnings, the copy or move constructor should be defined.
			This might cause some trouble with '-Wextra' from G++ complaining aboud imlicit call of default constructor in devired classes if it is not explicit initialized.
				As a workaround, (a few) copy constructors now explicitly initialize the base interface subobjects.
Note that '__cplusplus' value is significant across different versions of implementations.
	Paticularly, '__cplusplus > 201103L' is not equivalent to '__cplusplus >= 201402L'.
		ISO C++ working draft did not specify any value between '201103L' and '201402L' for 'cplusplus'.
		However, there exists some implementations use these values.
			For example, some G++ versions uses '201300L' for C++1y mode.
				See https://gcc.gnu.org/ml/gcc-patches/2013-04/msg01452.html.
				MinGW G++ 4.9.1 from MSYS2 is tested and confimed the use of this value when specified '-std=c++14'.
			On the other hand, Clang++ 3.5.1 from MSYS2 uses '201402L' for '-std=c++14'.
		This is important for some feature detection conditions.
			As an example, 'constexpr' on C++14 'std::max' is supported differently by similar conditions.
				Libstdc++ only supports it through macro '_GLIBCXX14_CONSTEXPR' after version 4.9 when '__cplusplus >= 201402L'.
				Libc++ supports it with same condition through macro '_LIBCPP_CONSTEXPR_AFTER_CXX11' except for it can be disabled by define '_LIBCPP_HAS_NO_CXX14_CONSTEXPR'.
			As another example, C++14 'std::integer_sequence' is supported similarly.
				Libstdc++ 4.9 supports it when '__cplusplus > 201103L'.
				Libc++ supports it when '_LIBCPP_STD_VER > 11', effectively equivalent with '__cplusplus > 201103L''.
		YSLib uses it carefullly.
			For different senarios, these different conditions are distinguished.
			Currently the non-standard-compliant macros like '_LIBCPP_HAS_NO_CXX14_CONSTEXPR' are ignored.
			There would be some specific macros like libc++ to control it better in future.
			Utilization of '__has_feature' would be preferred. Note it would be supported by G++ 5, and Clang++ has already supported it.

$2015-04:

report.impl:
ISO C++14 does not allowed arbitiary expressions for template non-type arguments.
	Notably, 'std::integral_constant' using '()' converting to a value is not allowed in these context.
		This is too restrict and cause it can be used almost always with 'static_assert' declarations or 'noexcept' specifications.
	WG21 N4198 stated and resolved this problem.
		See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4198.html.
		The resolution has been merged into working draft WG21 N4296.
	Note the use of '::value' are preferred in several contexts.
		Only certain expression related with 'std::integral_constant' should be considered for refactoring.
		For example, those 'seq_size' call in YBase.YStandardEx.Variadic and implementations of 'and_', 'or_', and 'not_' in YBase.YStandardEx.TypeOperation would not be touched even C++1z is accepted.
Copy constructor of exception classes is reviewed.
	See $2014-02 report.impl of basic rules.
	The standard don't restrict the stored subobjets of standard exception classes to allow optimization.
		See http://wg21.cmeerw.net/lwg/issue254.
		However, actual implementations may directly use reference-counted strings.
			See http://stackoverflow.com/questions/29052647/c11-introduced-exception-constructors-taking-const-char-but-why.
			See http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140428/104370.html.

$2015-05:

report.impl:
Now 'ystdex::nptr' is moved to <ystdex/pointer.hpp> to be specifically categorized as the pointer-related interface.
	Also to implement by using <ystdex/operators.hpp> avoiding too many dependencies introduced to <ystdex/utility.hpp>.
	It is still not ideal to decouple the interface, because now <ystdex/iterator.hpp> is relying on this header. In future, some portion of code in latter would better placed in another new header.

$2015-06:

report.impl:
Binary size matters, particularly to platform DS.
	Substitution of FAT code by custom implementation in 'DSIO' instead of libfat may gain runtime performance, however, makes it worse.
		Informal test release build before substitution showed sizes varied.
			YSTest.nds shrinked 983 KiB to 978 KiB by the raw libfat source substitution because of compiler and linker optimization.
			It bloated to 985 KiB after the complicated ystdex::used_list_cache used instead of naive one.
			After introduced exception handling and some other refactoring tricks, it became 986 KiB.
			After adding some more error checking, it became 988 KiB.
		Use new cache implementation which reduced base class, it reduced to 986 KiB.
			The DSIO uses 'std::map' instead of 'std::unordered_map' as underlying map container.
			Note this also has effect on font cache and image processing cache, except for 'std::unordered_map' is kept because hash function is specified.
			This also made less memory footprint.

$2015-08:

report.impl:
According to ISO/IEC 9899 footnote 268, it is undefined behavior to call 'fseek(file, 0, SEEK_END)' for a binary stream.
	This is also existed in ISO/IEC 9899:TC3 (WG14/N1256) which is referenced by ISO C++11, and older version of ISO C.
	However, it is not mattered in POSIX-compliant systems. ISO C++ standard library streams are also not effected.
	See also http://stackoverflow.com/questions/5957845/using-fseek-and-ftell-to-determine-the-size-of-a-file-has-a-vulnerability.
It is a known issue that current GNU C++ frontend 'cc1plus' would crash when debug option('-g', -g1' or '-ggdb', etc) for some code with nested 'decltype' expression in trailing-return-type.
	Only tested for G++ from MSYS2 package 5.2.0-3. It is used to build stage 2 SHBuild.
		However, stage 1 SHBuild seems to be OK.
	See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67238.

$2015-09:

report.impl:
Be cautious to the fact that some POD structs without constructors might not be initialized without initializer.
	It is clear that only a few types in the standard library is dangerous for the reason, see below. The specification is usually clear enough to distinguish bugs from implementations and user code.
	To serve robustness and make some speicific error easy to be detected, the automatic object of these types should be initialized explicitly for other external libraries.
	To value-initilize these types, '{}' is recommended.
		Note the list-initialization rules is not the same in ISO C++11 and ISO C++14, but here the effect is same, except for the defect concerned below.
		Still be cautious that value-initialization might not be enough, until the resolution of CWG 1368 is adopted by the coding convention.
			For the hole of value-initialization (not initializing some data members), see http://wg21.cmeerw.net/cwg/issue1368.
				It has been fixed in the standard (draft before ISO C++14 published), see https://github.com/cplusplus/draft/commit/7eed4036396d73f7c75719808119d993e840ce8c.
			One of prominent example is using of 'std::atomic' instances.
				This actually caused observable bug with G++ since b399 in YSLib::Helper and was fixed at b499.
			As a workaround, instead of '{}', use '{{}}', etc.
Error handling based on error code should be restricted.
	Error codes are often hard-coded with very limited ability to be extended.
		Interface like ISO C++ <system_error> can make it better somehow.
	Error codes as return values is superseded in many scenes, esp. for code quality.
		Error codes have no force to urge user handling. Using 'catch' everywhere not properly is obviously bad style, but abandon an error code silently is too easy.
			This may be hard to detect.
		Error codes have monadic error neutrality like exceptions.
			This may make code verbose and full of semantic noise.
		They may still useful if return value is always checked by the users.
			For low-level interface, it might be better to provide routines with both exception handling and error codes support.
	Error codes stored as non-automatic objects cause more problems.
		They make functions using them not reentrant.
		Access of static objects may cause data race.
		They may make the optimization difficult, if not impossible.
			The C library <math.h> is a prominent example, although for floating-point arithmetic there are other environment issues.
		Particularly, 'errno' is considered harmful.
			The type 'int' is not extensible.
			The type 'int' is too broad to its meaning.
			The interface using errno is often poor.
				The purpose exposed by interface can be clearer by avoiding using plain 'int'.
			It should be avoided for these reasons, even if it is widely supported.
			Note that 'errno_t' has been removed for a while, since b594.
				Even it is adopted by ISO C11 as library extension and is clearer than plain 'int', the other problems remain.
				General C++ error handling (even with other error codes) is perferred.
				So the style is not supported any longer.
			For portability issues, 'errno' (and 'int' for this purpose) are still allowed, but they should be better not used, or only when extremely necessary.
Deduce of braced-init-list is limited.
	See http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3681.html and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3912.html for background.
	See also https://isocpp.org/files/papers/n3852.html#FI3.
	WG21 N3922 changed the rule after ISO C++14. This is adopted, as per the working paper N4527. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html.
	Clang++ 3.6 and 3.7 would issue an warning [-Wfuture-compat]. See http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150209/123100.html.
	Note G++ 5.2 accepts currently invalid code even for '-std=c++11', deducing it as list-initialization rather than instance of 'std::initializer_list'.
		This would only be conforming after ISO C++14 rules are adopted.
Previously analysis of grammar of template default argument for non-type parameters turns to be wrongly.
	See $2013-10 report.impl.
	Note ISO C++11 [dcl.fct.default]/3 has already forbid non assignment-expression as template default argument for non-type parameters.
	It turned to be a G++ bug. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905.
Atomicity might be a real problem to file system APIs.
	This might cause TOCTTOU access and make inconsistent state in the resulted environment.
		There are no portable way to fix it.
		See https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use.
	Since there are few file systems support transactions, this is hard to achieve on this level.
	Users should be careful by themselves.
	File locks should be considered in future to make life ease.
Readonly attribute is considered in Win32 when removing a file.
	Win32 API 'DeleteFile' prevent deletion of a file.
	Low-level 'unlink' and 'remove' are based on 'DeleteFile' in MSVCRT (at least as in universal CRT source), so do the '_w' variants.
	Thus mearly calling these APIs are not able to remove a readonly file.
	To achieve consistent behavior with other platforms (mostly POSIX), YCLib 'FileIO' API now try removing the readonly attribute at first if it is not a directory.
		This would increase risk of TOCTTOU access.
Multilevel tree deletion actually works well, except for shared files are involved.
	For example, for multilevel tree deletion, if non root directory is opened at 'explorer' in Windows, the view would return to the parent directory of opened directory and the operation would fail (with the previously opened directory already removed).
	These potentional bugs should be further investigated in future.
There are many conditions concerned to copy file.
	'CopyFile' is proveded as a set of overloaded functions in 'YFramework.YSLib.Service'.
		It relies on some APIs in YCLib.FileSystem to make the implmentation easy to use non platform neutral operations.
		The destination and source are basically specified by path strings or file descriptors.
			Other variants can be considered later.
	The API is carefully designed to meet different requirements, particularly:
		Users should be able to specify whether the operation would fail when the destination is already existed.
			At least a parameter should have functionality similar to 3rd 'bFailIfExists' parameter of Win32 API 'CopyFile'.
			For availability, 'CopyFile' actually provides a 'size_t' parameter to allow users specifying maximum allowed link numbers when the destination is already exists.
				Note the call would change the link number of the destination path only when destination is not existed yet, that is, from 0 to 1. The parameter is not used here.
		Link behavior should be considered.
			Users should be able to specify whether the modification of destination is visible through other paths.
				Note the problems only occur on overloadings with the destination specified by a path.
				Thus, providing such functionality through other names is a surprise and bad.
			For hard links, if shared writing is allowed, there need to be no extra operations, otherwise the destination should be removed before the copy.
			For symbolic links, if shared writing is allowed, the link should be followed, otherwise the destination should be removed before the copy.
		To make it clear as the name of the function and to ease the use, several limitations are made by design.
			'CopyFile' creates only one regular file by one successful call, without reading the source file contents before the actual copy.
			'CopyFile' does not remove destination explicitly, except for the link behavior needed above.
		When the destination is not existed, 'CopyFile' can be called directory.
		When uncoditionally deletion of destination is needed, user can call always 'TryRemove' and then 'CopyFile'.
		When the destination is existed as regular file with link number equals to 1, the file are to be opened directly and write by 'CopyFile'.
			The node ID and creation time (if any) shall not be touched.
		New APIs should be designed for some specific operations (e.g. to increase performance) without direct calls of 'CopyFile':
			Batch operations are needed.
			Conditional links are needed.
			Conditional writing, e.g. comparing source of file (to minimize writing) before actual copy, is needed.
	Several preconditions shall be hold, or the operation would fail:
		The destination shall not be on a readonly file system.
		The destination shall be in a directory with write and search permission.
		The source shall be with read permission.
		The destination shall not specify a directory.
			Otherwise it violates the intention of "not removing destination" above.
			This should also fail when destination is a nonempty directory, since tree removing operation is complicated so it is not fit to implement on this level.

dep.merge:
libwibble(https://packages.debian.org/sid/libwibble-dev): tentatively rejected.
	This is a package about some general/low-level C++ utilities for developers.
	The interface is not up-to-date to modern C++ style.
	The functinoality should be covered by YBase and YFramework.YCLib intentionally, though most of them are not done yet.
folly(https://github.com/facebook/folly): tentatively rejected.
	Though used productively and is under actively development, this library is not fit for YSLib as a dependency.
		The API design is awful.
			Too many functionality overlapped with the standard library, with less obvious design principles.
			Too many direct use of strongly coupled specific types in function signatures (e.g. explicit 'std::string').
		The quality of impelementation is not competitive.
		It relies on a subset of boost.
			Boost is rejected basically because it is too large. This subset is still considered large engough to be rejected.
			Though some equivalent API of them are of parts of YBase (e.g. boost.operators), it is too tricky to maintain.

$2015-10:

report.impl:
There are something to be noted for feature-testing macro '__cpp_lib_tuple_element_t'.
	According to WG21 N4030 and WG21 N4440, the feature-testing macro is defined for <utility>.
	However, the definition shall be in <tuple> as per ISO C++14.
	Microsoft VC++ 2015 has supported 'tuple_element_t'
		See https://msdn.microsoft.com/en-us/library/Hh409293.aspx.
		Note that Microsofot Microsoft VC++ 2015 implemented the primary template also in <utility> rather than <tuple> as ISO C++14 requires.
			This is acceptable because 2-phase lookup is not implemented yet in Microsoft VC++. Once <tuple> is included, the specialization of 'tuple_element' for 'tuple' would work as expected. So does 'tuple_element_t'.
			Since <utility> is always included by YBase.YStandardEx headers, the conforming issue does not take effect.
Assertions can not necessarily be used in 'constexpr' functions.
	ISO C++11 'constexpr' is limited for only one statement (besides static assertions, etc) is allowed in function-body.
		This is relaxed by ISO C++14. However, ISO C++11 compatibility is still needed for YBase currently.
	For ISO C++11 '__func__' and other similar extension like '__PRETTY_FUNCTION__' of G++, the implementation inserts the declaration directly into the function body. So it does not meet to the requirement above.
		The standard macro 'assert' may or may not use these facility.
			This actually cause 'assert' even cannot be reliably used in 'constexpr' function template for devkitARM and Android, but not for MinGW-w64.
		This is a defect of C++. See LWG 2234.
	As a workaround, custom implementation should be used instead.
		For example, '_LIBCPP_ASSERT' in libc++ is used in <__debug>. It uses '_VSTD::fprintf' and '_VSTD::abort'.
		The macro 'yconstraint' in YBase use custom 'yassert' instead of 'assert'.
			As a result, it would display different diagnostics when triggered.
			It might also behaves differently for platforms like Android.
				Note '__android_log_assert' is not directly used.
		The macro 'yassume' is not touched.
Proper string types should be selected to design APIs.
	For owning string, classes like std::basic_string instances may be good enough.
		The default allocator is 'std::allocator' instance.
			Replacing it by type-erased allocator in future is recommended for general scenes, if possible.
				See namespace in [memory.resource.aliases] in WG21 N4480.
		The specialization of APIs are modified significantly since ISO C++11.
			Reference-counted implementation is not allowed any longer.
				Be careful to non-conforming implementations, e.g. libstdc++ shipped before G++ 5, or newer but with old ABI. See $2013-12 report.impl for details and replacement.
	For readonly view of non-owning string, some particular pass-by-value objects should be used instead.
		Non-owing refereces are quite common to use.
			Particularly for strings, the computational complexity is O(1) for length computation, instead of O(1) 'strlen' call for traditional C NTCTS(null-terminated character type strings).
		See 'string_view' of [string.view] in WG21 N4480.
			Prior art for strings has been used elsewhere, see WG21 N3921.
			For arrays there is 'array_view' similarly, see WG/P0122R0. To simplify the APIs, see WG21 P0123R0.
		YBase.YStandardEx.StringView provides 'ystdex::basic_string_view'.
		Furthermore, YBase.YStandardEx.TStringView provides 'ystdex::basic_tstring_view' for strings with termination character only occurs at the end of the string, particully for NTCTS.
			Only specializations of null character as terminators are implemented now.
			Use it carefully, since it is essentially confilict with 'string_view' stuff because of overloading rules.
			Only use it for APIs serve to legacy NTCTS underlying facilities when no ambiguity would be introduced.
Options for threads should be cautious for portable build.
	Option '-mthreads' should be used in MinGW GCC to be compatible with Microsoft VC++ multithreaded environment (with predefined macro '_MT').
	Currently MinGW GCC with POSIX thread model defaults to '-pthread' if not provided '-no-pthread'.
		Although '-pthread' is also available (no effect) for GCC, to be compatible for Win32 thread model in future, options for GCC in build script is not changed.
	For Clang++, there is no specs and '-dumpspecs' is unavailable.
	Currently all compilers without specs are treated as the same. The pthread support is assumed to be existed in the hosted implementations in all cases.
		This also eliminate hard-coded check for specific OS.

$2015-11:

report.impl:
Some metaprograming interface design is concerned.
	Higher-ranked polymorphism is distinct than prenex polymorphism. The difference is the rank, i.e. the number of universal quantifiers appered to the left of arrows in the type signature.
	Some programing languages has native support on this feature based on a monomorphic type system.
		In C++, a type refers to monomorphic type in type theory. Polymorphic types are class templates. Template type parameter is prenex, while template template parameter is higher-ranked. Function templates in class templates can also considered higher-ranked.
		In Haskell 98 (without extensions), types are prenex by default.
	There are some complexity and interface limitations dealing with higher-ranked polymorphic types in genereal.
		Type inference for rank-2 polymorphism is decidable, but reconstruction for rank-3 and above is not.
	Kinds can be a replacement to higher order metaprogramming.
		Though it is also often limited in languages. Until GHC 8, types and kinds are treated differently. See https://typesandkinds.wordpress.com/2015/08/19/planned-change-to-ghc-merging-types-and-kinds/.
		In C++, there are no native support. However class template partial specializations and custom members can be used to achieve similar effect.
			Most notably, member 'type' is used as intermediate implementation for higher-ranked alias templates. This is also fit where alias templates are not available, e.g. TR1 and boost.mpl.
			Function kind '* -> *' can be simulated as boost.mpl style, which expose an 'apply' metafunction to call the specialized class templates as metafunction.
				See http://www.boost.org/doc/libs/1_59_0/libs/mpl/doc/refmanual/apply.html.
			In meta library of range-v3, there are some differences.
				The nested member alias template 'apply' in metafunctions is directed to the result, rather than a type with nested member type 'type'.
				Some helpers like 'quote' are used to help creation of metafunction expressions.
					There are some subtle issues with C++, e.g. CWG 1430.
				See https://github.com/ericniebler/range-v3/blob/master/include/meta/meta.hpp.
		Higher-ordered kind is not supported by standard Haskell but GHC. This is not considered here to avoid extra complexity.
	To avoid complexity, in YBase, design is limited.
		Higher-ordered polymorphism are avoid in template parameters except for several exceptions.
			One is the implementation proposed detection API, see WG21 N4502.
			Another case is some underlying helpers like 'vseq::defer'.
The 'what()' in classes derived from 'std::exception' shall always returns a nonnull pointer value.
	Since ISO C++ [exception]/2 specifies explicitly that it should be a valid pointer suitable as an argument of 'std::strcmp'.
	Thus it is redundant to check nullary of value of 'what()'.
	And the 'what' overriders can be declaraed 'YB_ATTR(returns_nonnull)'.

$2015-12:

GCC now emits additional code for block scope static variable initialization to ensure conforming to the standard (e.g. ISO C++11).
	The thread-safe initialization is controlled by 'flag_threadsafe_statics' in static function 'expand_static_init' in source file 'gcc/gcc/cp/decl.c'.
	It is toggled by '-fthreadsafe-statics' of the driver, which is enabled by default.
	For implemntation with single thread model, this is redundant.
		To reduce the binary size especially for some embedded platforms, the code can be compiled with '-fno-threadsafe-statics'.
			This is also good for compilation performance.
			This is also fit for libstdc++.
				See also https://github.com/devkitPro/buildscripts/issues/6.
				Note that '--disable-libstdcxx-verbose' have been already used for devkitARM, see https://github.com/devkitPro/buildscripts/blob/master/dkarm-eabi/scripts/build-gcc.sh#L47.
			This does not reduce YSTest binary significantly since there are few static variables.
The new GCC toolchain bloats code.
	The new compiler and linker actually optimized for size better. However, libstdc++ bloats significantly.
	It bloats 'YSTest' binary size to 1030KiB(b662) from 1000KiB(b661).
	The mangled names for standard library entities like 'std::string' in libstdc++ with C++11 ABI bloated a lot.
		There have been another issue since G++ 4.9 though: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936.

////

