最後，Base-from-Member Idiom 是這個問題的另外一種變形，稍加修改設計，亦可適用。

因為當 Constructor 遇上 Virtual Function說：
建構一個 Derived 的 object instance 時, 先被建構的是其父類別，因此此時 typeid 會是拿到 Base class 。待子類別建構完成後、在 main() 中的 d.print_type_name(); 呼叫才會拿到 Derived 。

我亦認同且自己嚴格執行這個 convention，不過，考慮到 pre-compiled header 可以有十分顯著的 compilation speed up 時，把 standard headers 放前面有其好處。

jeff 的意思是說 MS 提供的 runtime library 常會做非標準的事情. 例如 inet_ntoa 的回傳字串的實作.

• POSIX (BSD)

… The string is returned in a statically allocated buffer, which subsequent calls will overwrite.

• WIN32

… The string returned is guaranteed to be valid only until the next Windows Sockets function call is made within the same thread.

於是, 在 windows 上的 programmer 並不會知道程式寫錯了, 那些問題也只會在程式要從 windows 跨到其他 platform 時爆炸.

於是 upgrade visual studio 版本後，或是一開始就發現，程式很神奇的不會爛掉，但是當 porting 到其它「正常」的平台後，就爛掉了。

No, it is a brilliant strategy, because it allows you to make claims like this in order to try to defend their actions. It has zero effect on the “lock in” (the funcitons are trivial enough that no “standard” is needed to reverse-engineer them) but it provides a nice-sounding excuse for their compiler to spew warnings about portable code.

CHECK(lexi_cast3<string>(123) == "123");

(CHECK() is a macro of my tiny test framework.)

I still think the claim of a Microsoft conspiracy to ‘lock in’ developers cannot be taken seriously, except by those who could easily be convinced to wear tinfoil on their heads. It would be quite a stupid strategy to spend time and money trying to get these ‘*_s’ routines standardised if ‘lock in’ were Microsoft’s goal.

Second, the issue is not whether a routine is inherently ‘unsafe’ — virtually anything /can/ be used ’safely’ — but whether an interface is so poorly designed that it promotes ‘unsafe’ coding. That is, it cannot be used ’safely’ without a lot of extra code to check things that the library routine itself could (and should) very easily check.

Even the original strcpy can be used perfectly safely if developers keep track of string lengths and buffer sizes. The reason strcpy is ‘unsafe’ is because (a) the interface does not make it clear that developers /have to/ think about these things themselves, and (b) the compiler/runtime does not offer any checking or error reporting, so developers have to rely on spotting bugs in code reviews, with debug allocators (for heap buffers) or from crash dumps.

The main point of these ‘*_s’ routines (well, my guess as to the point) is to force developers to think about string lengths, buffer sizes and truncation whenever they call one of the library routines, and to help them spot cases where they have made mistakes. If you don’t know the string lengths, buffer sizes and whether or not you want to truncate, then your code is already wrong. If you do, then switching to these ‘*_s’ routines is trivial. These are not marketing effects. Thinking about these things is exactly what every developer using the C library should do. Unfortunately, many of them don’t, and even the ones that do sometimes make mistakes, for which the standard C library interfaces/runtime offer no help.

On the whole, strcpy is an awful design and strncpy makes things worse, by introducing confusing special cases without even guaranteeing null termination. strlcpy is a good (but non-standard) solution, and so is strcpy_s. Where strcpy_s wins is in requiring that developers who want truncation explicitly say so, in its more powerful error-handling mechanisms and in the overall consistency of the ‘*_s’ interfaces.

First of all, let me just say that I am glad that you stopped calling people “tinfoil heads” in your response to Spitzak’s comment.

The scenario you laid out does demonstrate your points very well, (BTW, I fixed the ‘\0′ thing in your comment) but still, it doesn’t mean one can’t code securely using strncpy.

This post is NOT about how I hated a set of (supposedly) more secured string functions that is not in the Standard, but rather, to dispute one compiler vendor’s secure programming strategy, which IMO, produces more marketing effects than secure coding minds.

Apology to all if I’ve been misleading. By implying strncpy is as safe as strcpy_s, I meant one can’t overrun destination buffers, as a result of invocations of either strncpy or strcpy_s, when used correctly. And one could indeed code securely, with strncpy. (though additional effort may be required) As the zero filling behavior of strncpy, which wastes CPU cycles, is another topic.