[cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing does u

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

[cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing does use concrete GDBBackend class name?

From: "Andy Jin" <AJin@xxxxxxx>
Date: Wed, 29 Jun 2011 09:38:23 -0400
Delivered-to: cdt-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/cdt-dev>
List-help: <mailto:cdt-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/cdt-dev>, <mailto:cdt-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/cdt-dev>, <mailto:cdt-dev-request@eclipse.org?subject=unsubscribe>
Thread-index: Acw2YdEUdOvXZ++lSqOdhHAsRV97xA==
Thread-topic: [DSF] why does AbstractMIControl.startCommandProcessing does use concrete GDBBackend class name?

I am migrating to CDT8. In DSF debug I have customized IGDBBackend for specific implementations.

New in CDT8, the AbstractMIControl.startCommandProcessing() method creates a stderr stream thread to fix bug 327617. However when creating the error thread it uses the concrete GDBBackend class so that my customized IGDBBackend class is not being used.

Is there a reason why this method uses the concrete class not the interface? Is there a way I can work around this without overriding this method with my customized control?

Thanks,
Andy

Follow-Ups:
- Re: [cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing does use concrete GDBBackend class name?
  - From: Marc Khouzam

Prev by Date: [cdt-dev] Code generation and reflection in IBaseClassInfo.
Next by Date: [cdt-dev] FW: Hudson build is unstable: cdt-nightly #738
Previous by thread: [cdt-dev] Code generation and reflection in IBaseClassInfo.
Next by thread: Re: [cdt-dev] [DSF] why does AbstractMIControl.startCommandProcessing does use concrete GDBBackend class name?
Index(es):
- Date
- Thread

Breadcrumbs