一個問題的討論
今天在QQ里跟大家討論了一個問題，雖然沒有結論，但是還是貼出來留個記號。
崔剛(崔剛) 2007-10-25 16:18:55
如何通過基類指針調用派生類特有方法，前提是不允許強制轉換指針類型？
例如有基類 class base{};
派生類
class derive:public base{
public:
int A();
}
我得到了一個base* 類型的指針 derive_ptr，但它指向derive類型對象，我如何調用方法 derive::A(), 不可以
((derive*)derive_ptr)->A();
李奇兵(李奇兵) 2007-10-25 16:20:17
把方法A（）申明為虛的
陶華(陶華) 2007-10-25 16:20:52
除非基類有這個虛接口
李奇兵(李奇兵) 2007-10-25 16:20:55
把方法A（）申明為虛的，在Base定義一個。
向官文(向官文) 2007-10-25 16:21:16
用函數指針應該可以實現吧
陳道生(陳道生) 2007-10-25 16:22:46
沒方法
崔剛(崔剛) 2007-10-25 16:22:27
呵呵，如果base類有幾十個派生類，每個派生類都有不同的特有方法，那么在基類中就會存在幾十個虛方法，而每個派生類只實現一個，其它全部不實現，
這樣是不是不太好？？
李偉(監護）(李偉(監護）) 2007-10-25 16:23:25
如果是public的，基類應該聲明吧
張建生(張建生) 2007-10-25 16:23:57
這樣的話該函術確實不應該在基類里面定義
基類里面只定義共有的
靳波(靳波) 2007-10-25 16:23:47
這個問題的答案肯定很有技巧，但我認為這種技巧太花哨，不知道也沒關系
陶華(陶華) 2007-10-25 16:24:49
崔剛，你那樣定義是違反替換原則的
向官文(向官文) 2007-10-25 16:25:02
咱們的消息映射機制就是用基類的函數指針調派生類的成員函數
李偉(監護）(李偉(監護）) 2007-10-25 16:25:02
還是想知道。。
莫書健(莫書健) 2007-10-25 16:25:22
上面那段代碼會不會運行是對的？
只是這樣強制轉換不是很符合編碼規范
崔剛(崔剛) 2007-10-25 16:25:28
呵呵，不要懷疑我的問題的實用性
彭建軍(彭建軍) 2007-10-25 16:26:34
對于這個問題，C++的標準解決方法應該是dynamic_cast
靳波(靳波) 2007-10-25 16:26:15
cast也是類型轉換
莫書健(莫書健) 2007-10-25 16:27:41
加不加dynamic_cast之類的，運行效果應該一樣
彭建軍(彭建軍) 2007-10-25 16:29:18
是類型轉換，但那是C++標準的轉換方式。
向官文(向官文) 2007-10-25 16:30:45
dynamic_cast 據說會損失執行期效率
靳波(靳波) 2007-10-25 16:31:33
dynamic是在運行時進行轉換，所以不是據說，是肯定會損失執行期效率。
靳波(靳波) 2007-10-25 16:36:22
#include "stdafx.h"
#include <iostream>
using namespace std;
class Base
{
};
class Derive : public Base
{
public:
int A(){cout<< "Derive::A()\n"; return 0;}
};
union Amazing
{
Base* pBase;
Derive* pDerive;
};
int _tmain(int argc, _TCHAR* argv[])
{
Base* derive_prt = new Derive;
Amazing trick;
trick.pBase = derive_prt;
trick.pDerive->A();
delete derive_prt;
return 0;
}
向官文(向官文) 2007-10-25 16:37:45
typedef void (base:: *BasefnPtr) ();
BasefnPtr fn_ptr = &derive::A;
然后用基類的指針去調
(pBase->*fn_ptr)();
我看高端里消息響應函數就這樣調
沒理解錯吧 ;)
崔剛(崔剛) 2007-10-25 16:39:09
同志們，跑題了
1、不能強制轉換，標準的強制轉換也不行。
2、不是把派生類指針轉成基類指針，那樣是沒問題的。我說的是把基類指針轉成派生類指針。
楊曉濤(楊曉濤) 2007-10-25 16:40:14
靳波的方法挺有創意的，呵呵
靳波(靳波) 2007-10-25 16:40:45
：）
莫書健(莫書健) 2007-10-25 16:41:37
jinbo的方法有什么優點？
崔剛(崔剛) 2007-10-25 16:41:46
靳波太搞笑了，這樣寫不可維護
靳波(靳波) 2007-10-25 16:41:41
這個方法太危險
崔剛(崔剛) 2007-10-25 16:42:13
變相的強制轉換，不合格，0分
莫書健(莫書健) 2007-10-25 16:43:34
cuigang的需求估計沒有解決方法
陶華(陶華) 2007-10-25 16:44:57
需求評審不通過
崔剛(崔剛) 2007-10-25 16:44:40
問題本身是沒有解的，但是迂回的方法有，比如IoControl或者高端中ControlModule的方法就是一種，但是不是有其它更好的辦法呢？
崔剛(崔剛) 2007-10-25 16:45:34
visitor 模式也提供了一種方法，但是太麻煩，本質上和 IoControl 沒什么區別。
張進(張進) 2007-10-25 16:48:45
還有一種方法,把編譯器作者拉出來打,狂打,直到他搞定為止!
陳道生(陳道生) 2007-10-25 16:48:57
有點像已經知道方法名和參數,如何調用實例對應的方法,在c++中無解,在其他語言大放異彩(java,c#),都是要具有元編程能力的語言才行.
崔剛(崔剛) 2007-10-25 16:48:26
我需要一種安全方便又易于維護的辦法，不要急著回答
崔剛(崔剛) 2007-10-25 16:49:23
難道我們真的離不開強制轉換？？
莫書健(莫書健) 2007-10-25 16:52:18
如果想調用派生類的方法，就要使用虛函數，
設計基類是要充分抽象，盡量想到種種情況
向官文(向官文) 2007-10-25 16:53:01
崔剛好像對強制轉換深惡痛絕啊～
崔剛(崔剛) 2007-10-25 16:52:46
我認為依靠繼承的方法不可取
莫書健(莫書健) 2007-10-25 16:53:19
實在不行，就將就強制一把，我想也可以容忍的
楊曉濤(楊曉濤) 2007-10-25 16:54:05
類本身也需要細化，寄希望一個類包含所有的接口是不現實的；
粗暴的將所有功能放在一個類中，也是不美觀的，不招人喜歡的
崔剛(崔剛) 2007-10-25 16:53:45
不是我厭惡強制而是強制不安全，維護代碼時可能發生不可意料的問題。
靳波(靳波) 2007-10-25 16:53:57
既然你已經有答案，不如公布出來讓大家參詳參詳。
崔剛(崔剛) 2007-10-25 16:54:54
我沒有答案，有的話就給你們上課了
莫書健(莫書健) 2007-10-25 16:56:11
這個課題就叫“崔剛猜想”吧
陶華(陶華) 2007-10-25 16:58:27
給C＋＋標準委員會提個需求
崔剛(崔剛) 2007-10-25 16:59:27
另，dynamic_case<> 需要編譯器支持 RTTI
向官文(向官文) 2007-10-25 17:04:51
C++這門靜態語言解決這個執行期的動態問題恐怕無解
也許出路在第三方的接口上吧
崔剛(崔剛) 2007-10-25 17:05:55
換句話說，大家是不是認為，在目前階段，象ControlModule和IoControl這樣的接口是相對合適的嘍。
崔剛(崔剛) 2007-10-25 17:13:41
2007年10月8日，汪勝平在他的工作日志里寫道：
關于ControlModule型接口
這種類型的接口有以下好處：
1、降低編譯依賴性。
2、如果模塊A通過接口ControlModule依賴模塊B，當模塊B不存在時，理論上模塊A仍然可以正常工作。
當然它也有一個不好的地方，那就是本來簡單的調用關系，因為這個接口的引入變得復雜一些了。
但是，這兩個好處需要小心使用才能保證。
1、沒有函數名的依賴，但是并不代表就沒有編譯依賴了。比較典型的是ID的依賴。ID在模塊B中被定義。在A中直接包含
B的頭文件。不過這種編譯依賴可以由第三方定義ID來解決。
2、如果需要傳遞的信息比較多，我們最容易想到的方法是定義一個結構體來傳遞相關信息。這個結構體如果由B來定義，
那么A又落入了在編譯上依賴B的陷阱。
3、如果A在調用時沒有考慮好B不存在怎樣處理，那么ControlModule的第二個好處就體現不出來。
對于ControlModule型接口。我覺得要慎用，它不是萬能的。某些時候，虛函數也許更方便。
=================================
這是一個典型的C方式函數。我覺得如果是通用的接口，可以用多態，如果是特殊函數，這樣寫純屬找茬。//崔剛 2007-10-12
=================================
ControlModule這類的接口，簡單問題復雜化，難道只是為了
“降低編譯依賴性”？這會不會是我們軟件部附加上去的想法,
這類接口經常用于驅動接口(請參看linux\windows,
還有我們的mmos驅動模型),
我想最初這樣做的理由會不會是這樣：
1）為了減少接口個數。
2）統一屬性設置/獲取接口。
至少在驅動是這樣的。
比如：
set_property1();
set_property2();
:
:
set_propertyN();
減少為一個
#define ID_PROPERTY_1 0
#define ID_PROPERTY_2 1
:
:
#define ID_PROPERTY_N n
Control( property_id, ...);
mosj
夏恒星(夏恒星) 2007-10-25 17:37:29
呵呵，原來這樣的問題并不只有我遇到，俺在代碼中加了注釋：
//注意: 將基類指針強制轉換為派生類指針并不可取
//但是此處要使用協議各層提供的非基類提供的接口
//能不能從設計上避免?
mTopProtocol = (CUartCommProtocol* )(m_pProtocolStack->GetSpecifiedLayer(UART_COMM_PROTOCOL));
崔剛(崔剛) 2007-10-25 17:44:02
這種應用更常見的地方是，把不同的派生類放到共同基類類型的指針容器里，然后把這個基類指針取出來，再干一些派生類的事情。
崔剛(崔剛) 2007-10-25 17:46:11
隨便在高端里copy一段代碼給大家看：
MSpinBox* pSB;
pSB = (MSpinBox*)GetWindowItem(IDC_CO_SPIN_TB_HI);
INT32 value = pSB->GetIntCur();
汪勝平(汪勝平) 2007-10-25 17:53:20
我覺得這種類型的接口比ControlModule強，
雖然這些接口會增加編譯期依賴。
崔剛(崔剛) 2007-10-25 17:53:40
這就見仁見智了。
崔剛(崔剛) 2007-10-25 17:58:59
下班前，抄一段《JAVA編程思想》的話給各位共勉，包括發炎的沒發炎但吃了藥的。
http://vss2/sites/jhsoftware/Lists/List13/Attachments/768/ThinkJava.bmp
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
太“行而上”了！不過監護軟件部真是不可小覷啊！ 張進
/*******************************************/
/*
我不認為這是一個“形而上”的問題，或者一個智力游戲，它有著廣泛的用途，否則不會有這么多的討論和解決方案。昨天晚上回家查了一下，“向下轉型”的確是我們要在設計中避免的，但在實際設計卻經常面臨，目前所有語言基本都支持到dymanicv_case<>的地步，而這卻需要RTTI的支持，雖然其他高級語言比如C#，Java，Python都在語言級別提供象“反射”等方式來解決這個問題的超集，但是此種“元類”的語言特性違背了C++的精神，想必無論如何也不會出現在C++里，因為效率的犧牲和運行時存儲的需求應該也不適用于目前的嵌入式設備。
反過來再想想，我們何必要求非常安全的途徑解決這樣的問題。C++/C本來就是一種弱類型語言，不安全的特性比比皆是，所以動態強制轉換未必不是一個正途。
另外，對于汪勝平最后說出的問題，我覺得ControlModule之類的寫法可以用這種強制轉換的方式解決，當然孰優孰劣就留給各位去判別了。
崔剛 2007-10-26
*/