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