• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>

    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>

            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            

    
            

            


            

        


            


            C++ Space
            

            C++, 3DGame
            

            

            
	
					
		

            
	2007年4月20日		  
	#

            


		
            
			
            關于DLL中對象的動態創建與刪除的問題
            
			
			
            最近有看到一些文章討論怎樣輕松的使用DLL，其中有一個錯誤，那就是在DLL中創建的對象未在DLL中刪除，如下示：
            

            //someheadfile.h
            #include<memory>

            class __declspec(dllexport) Interface
            {
                         public:
              virtual             void foo() = 0;
            }            ;

            class __declspec(dllexport) Impl : public Interface
            {
                         public:
               virtual             void foo()
                           {}
            }            ;

            __declspec(dllexport)
            std::auto_ptr            <Impl> DLLCreate()
            {
                          return std::auto_ptr<Impl>(new Impl);
            }
            

            上面的做法貌似可以做到自動刪除動態生成的對象，但，只有DLL和用戶都動態鏈接C/C++運行庫時它才會運行正確，否則，創建和刪除會在不同的堆棧空間進行，從而導致錯誤 。
            所以還是老實的在提供一個            DLLDelete()用于刪除在DLL中生成的對象。

            

			
			
            		
				posted @ 2007-04-20 13:35 Kooyu 閱讀(1556) | 評論 (6) | 編輯 收藏
			
            
		
            
	

	
		

            
	2007年4月3日		  
	#

            


		
            
			
            一個浮點數表示產生的問題
            
			
			半夜里剛睡著又被電話叫醒，一個項目的現場數據出現了錯誤。
            我們的程序要分析的報告里的某一個字段使用了定點小數的表示方法，即兩個字節表示整數部分，再兩個字節表示小數部分。剛開始的時候沒注意到這里有個問題，那就是這種表示法要求小數部分一定是定長的，否則，就無法解析。例如，0.03和0.30的表示不同在哪里，0.30可不可以表示成0.300。怪我當初考慮欠佳，失敗。

			
			
            		
				posted @ 2007-04-03 00:27 Kooyu 閱讀(973) | 評論 (0) | 編輯 收藏
			
            
		
            
	

	
		

            
	2007年3月9日		  
	#

            


		
            
			
            ACE_CDR::mb_align(ACE_Message_Block * mb)使用問題
            
			
			
		
            ACE_CDR::mb_align(ACE_Message_Block * mb)用于對齊mb內部數據塊ACE_Data_Block所擁有的內存的起始地址，它的實現大致如下：
            
		
            
				
				void
            ACE_CDR::mb_align?(ACE_Message_Block?            
				*
				mb)
            {
            ??char?            
				*
				?
				const
				?start?
				=
				?ACE_ptr_align_binary(mb
				->
				base?(),???ACE_CDR::MAX_ALIGNMENT);

            ??mb            
				->
				rd_ptr?(start);
            ??mb            
				->
				wr_ptr?(start);
            }            
		
            
		
            由于要執行內存地址對齊，那么mb->base()所指示的地址可能需要向后移動(MAX_ALIGMENT - mb->base() % MAX_ALIGMENT)個字節。但在這個之后，mb->base()指向的可用內存將比它自己薄記的少，如果需要程序正常運行，那么依賴于在往它寫入數據時，寫入的字節數不能大于實際大小(這個實際大小為 ：mb的薄記大小-移動的距離)，而這需要由程序員來控制，容易出錯也就難免了。

            也許可以在函數mb_align內部重設mb的大小，使其薄記大小與實際有效內存大小相符，但這引起內存拷貝，這個代價也太大了。

            內存對齊的處理似乎應該在內存分配階段，比如提供類似下面的分配已對齊地址功能的分配器：
            
		
            
				
				struct?Align_Alloc
            {
            ????void?            
				*
				?align_alloc(size_t?size,?unsigned?align)
            ????{
            ????????void?            
				*
				?ptr?
				=
				?
				new
				?char[size?
				+
				?align];
            ????????return?align_mb_ptr(ptr,?align);
            ????}
            };            
		
            
		
            但ACE實際上沒這么做，它提供mb_align這個與內存分配毫不相干的功能，且希望由程序員自己來解決可能引發的問題！~
            ?
            

			
			
            		
				posted @ 2007-03-09 15:33 Kooyu 閱讀(1603) | 評論 (0) | 編輯 收藏
			
            
		
            
	

	
		

            
	2007年3月7日		  
	#

            


		
            
			
            "危險"的函數指針類型的強制轉換
            
			
			
		
            查看一個與別人合作的項目的代碼，發現了一個“隱秘”的問題，模擬這個問題如下：
            
		
            
				
				typedef?void?(
				*
				foo_type)(
				int
				,?
				int
				);

            void?foo1(            
				int
				,?
				int
				)
            {
            }

            void?foo2()
            {
            }

            
				int
				?main()
            {
            ??foo_type?f?1            
				=
				?
				&
				foo1;??????????????????????// <1>
            ??foo_type?f?2            
				=
				?(foo_type)
				&
				foo2;?? // <2>
            ???? return 0;
            }            
		
            語句<1>肯定是對的，語句<2>強轉一個函數類型到foo_type類型，我當時擔心這會不會導致下面的語句導致運行時錯誤：
            (*f2)(1,2);
            幸運時這里它不會導致錯誤，這是由于：
            <1>我們使用C/C++的默認函數調用方式__cdecl，也就是傳入的函數參數是由調用者清理的；
            <2>函數foo2沒有使用任何參數。
            這種做法肯定不值得提倡，但實際的項目中要避免還是不太容易，畢竟每個人的習慣不一樣，還有為了與框架協同工作，有時候可能也不得不這樣做。但是，一旦函數調用方式發生改變，或者被強轉的那個函數是帶參數的，而它又使用了這些參數，隱秘的錯誤也就埋下了。
            
			
			
            		
				posted @ 2007-03-07 13:38 Kooyu 閱讀(3061) | 評論 (1) | 編輯 收藏
			
            
		
            
	

	
		

            
	2007年3月6日		  
	#

            


		
            
			
            實在讓人無法忍受
            
			
			C++ = VC++ = MFC/ATL/COM
            我已經記不清多少次看到與此類似甚至比這更離譜的關于C++的表述，真是害人不淺，特別是對C++新手而言。
            還有一些C++的半調子動輒批評、諷刺他們一知半解的C++特性，拿C++與另一種毫不相干的語言大肆比較，得出稀奇古怪的結論。

            一些氣話，心情不好。
			
			
            		
				posted @ 2007-03-06 13:17 Kooyu 閱讀(2285) | 評論 (7) | 編輯 收藏
			
            
		
            
	

	

            僅列出標題  
            

				

            






    
    
            
	   
	



成人妇女免费播放久久久|
久久精品亚洲福利|
久久人人爽人人爽人人爽|
亚洲日本久久久午夜精品|
亚洲精品NV久久久久久久久久|
天堂无码久久综合东京热|
色偷偷久久一区二区三区|
久久免费线看线看|
久久人人添人人爽添人人片牛牛|
久久国产亚洲精品无码|
99久久精品国产一区二区蜜芽|
久久无码一区二区三区少妇|
7777精品久久久大香线蕉|
亚洲国产精品久久|
亚洲精品乱码久久久久久久久久久久
|
国产精品亚洲综合专区片高清久久久|
久久露脸国产精品|
久久美女网站免费|
99久久婷婷国产综合亚洲|
99久久综合国产精品免费|
99久久精品国产一区二区|
国产精品久久久久久一区二区三区|
久久九九久精品国产免费直播|
久久香蕉国产线看观看精品yw|
久久久久无码中|
18岁日韩内射颜射午夜久久成人|
亚洲伊人久久大香线蕉综合图片|
久久一区二区免费播放|
欧美激情精品久久久久|
久久久久亚洲AV无码麻豆|
久久久久亚洲AV成人网人人网站
|
亚洲欧洲久久久精品|
久久久久夜夜夜精品国产|
精品久久无码中文字幕|
精品人妻伦九区久久AAA片69|
久久精品夜色噜噜亚洲A∨
|
久久国产免费观看精品3|
久久人做人爽一区二区三区|
麻豆久久久9性大片|
久久久国产精华液|
久久99国产精品尤物|