原创 action start與Task.Factory.StartNew()方法的異同點實例

之前演示了用action start創建和啓動task類多線程的實例,現在我們一起來看一個性能更好,也更方便的在task類中創建和啓動多線程的方法——TaskFactory.StartNew方法。 用action start創建和啓動ta

原创 Yield return語句與return語句的4個不同點(上)

本文部分內容來源於書籍和網摘。 return語句返回的是其所在方法的控制權,即終止該方法的此次執行; 而迭代器方法運行到 yield return 語句時,會返回一個 expression,並保留當前在代碼中的位置。 下次調用迭代器函數時

原创 Python編譯器求餘錯誤BUG

求餘就是求餘數的一種數學運算。也就是說,只要所得的商是整數,那麼求餘的結果也就爲0了。但是,在某些特殊的情況下,編譯器也是會出錯的,一起來看看:而且有趣的是,每次計算錯誤的輸出結果都是相同的——都是1.7763568394002505e-

原创 C#顯式實現接口與隱式實現接口的5個不同點

顯然我們隨時都可以創建該接口的對象,但是編譯器無法得知我們所創建的對象究竟是指向該接口的哪個實現的(如果有的話),甚至即便我們沒有實現該接口也一樣可以創建該接口的對象。簡單來說就是如果我們只是創建了接口的對象,那麼編譯器就只知道這個對象是

原创 C#接口的顯式實現解析和實例

之前在《C#接口的隱式實現解析和實例》,已經對C#的接口實現作了簡單的介紹,下面讓我們一起來看看更常見,也更規範化的接口實現方式——顯示實現。   ///而在實際工作中接口成員方法可能同名,但是其實現往往是有不同要求的,這容易導致遺漏和錯

原创 泛型方法的設計與應用2(參數的限制與設計)

設計泛型類或方法時,如果要對泛型成員執行除簡單賦值之外的任何操作或調用 System.Object 不支持的任何方法,則必須對該類型參數應用約束。包括但不僅限於: 由於具體類型的參數可能無法用於實現方法所以對泛型方法的參數進行限制: 由於

原创 協變接口與逆變接口的4個不同點

隱式轉換的範圍不同 協變接口:可以將“類型範圍”比他更小的泛型接口引用對象賦給協變接口的引用對象。 逆變接口:可以將“類型範圍”比他更大的泛型接口引用對象賦給逆變接口的引用對象。

原创 Java求三個數的最小公倍數算法優化

回顧之前的博文,一路走來,從《Java求3個數的最大公約數(3個數都是正整數)》一文中的“從3個數中的任意一個數開始求餘、遞減”;再到《Java求3個數的最大公約數算法優化(3個數都是正整數)》一文中的“3個數的最大公約數必然小於或等於其

原创 Java求三個數的最小公倍數算法改進(化境)

回顧之前的博文,一路走來,從“從3個數中的任意一個數開始求餘、遞減”;再到“3個數的最大公約數必然小於或等於其中最小的數”;再到“先用for循環對最小數求餘再對其他數求餘”;然後在第3次改進時又“直接對最小數求餘然後再對其他數求餘”;經歷

原创 Java求3個數的最大公約數算法優化(3個數都是正整數)

之前在《Java求3個數的最大公約數(3個數都是正整數)》一文中所使用的算法效率太低,現在來優化一下: 3個數的最大公約數必然小於或等於其中最小的數 相關導讀: Java求3個數的最大公約數(3個數都是正整數) https://blog.

原创 Java求3個數的最大公約數算法第3次改進

回顧之前的博文,一路走來,從“從3個數中的任意一個數開始求餘、遞減”;再到“3個數的最大公約數必然小於或等於其中最小的數”;再到“先用for循環對最小數求餘再對其他數求餘”;經歷了這2次算法上的改進之後,我越來越發覺算法其實比想象中的更復

原创 Java求3個數的最小公倍數(3個數都是正整數)

最近研究算法的時候突然發現目前國內網上發佈的關於這道題的文章有很多都是錯誤的(都是些新手寫的,至少在這篇文章之前是這樣的),自己寫完以後發現這其中的算法複雜程度的確不是新手就能夠駕馭的。 話不多說,直接上代碼:

原创 MySQL \G的三種作用詳解(下)

作用3:和SHOW關鍵字一起展示更多細節:

原创 MySQL簡易觸發器實例解析(通過變量來實現的觸發器)

@變量(用戶變量)sum=新插入的amount字段的記錄的和(NEW關鍵字修飾的字段amount);

原创 MySQL使用有多個執行語句的觸發器

不難看出,異常只出現在觸發器中的語句執行的時候;其他情況下仍然是正常的。 而所謂的“異常”其實是觸發器被觸發了2次,因此ctt3的插入操作也進行了兩次。而表ctt3是在表ctt2之後的,所以實際情況是ctt2執行一次插入語句之後,ctt3