C++模板继承在g++编译中应注意的问题(if you use `-fpermissive', G++ will accept your code, but allowing the use ...)

  x.cc: In member function `int Derived<T>::g()':
  x.cc:6: error: there are no arguments to `f' that depend on a template
     parameter, so a declaration of `f' must be available
  x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
     allowing the use of an undeclared name is deprecated)
To make the code valid either use this->f(), or Base<T>::f(). Using the -fpermissive flag will also 
let the compiler accept the code, by marking all function calls for which no declaration is visible at the time 
of definition of the template for later lookup at instantiation time, as if it were a dependent call. We do not 
recommend using -fpermissive to work around invalid code, and it will also only catch cases where functions 
in base classes are called, not where variables in base classes are used (as in the example above). 
Note that some compilers (including G++ versions prior to 3.4) get these examples wrong and accept above 

code without an error. Those compilers do not implement two-stage name lookup correctly.

 

基本意思是,在模板继承出现的时候,需要在子类中用this来标志从父类中继承过来的成员函数和变量的调用。不然用using声明也行。

在使用模板继承的时候,如子类中有调用父类的成员函数和变量的情况,则需要用用this来调用,或者使用using声明,否则会导致在linux

的G++ 上无法编译通过,错误提示会有如上错误信息。

 

 

Sure, I'd be happy to answer your questions! 10.1. IoC stands for Inversion of Control, which is a design pattern used in software engineering. It is used to decouple the components of a system by allowing dependencies to be injected from outside the component rather than being created inside the component. This makes the system more flexible and easier to maintain. Here's an example of implementing IoC using pseudo-code: ``` class ComponentA { private ComponentB dependency; public ComponentA(ComponentB dependency) { this.dependency = dependency; } public void doSomething() { dependency.doSomethingElse(); } } class ComponentB { public void doSomethingElse() { // do something else } } // Usage: ComponentB dependency = new ComponentB(); ComponentA componentA = new ComponentA(dependency); componentA.doSomething(); ``` In this example, `ComponentA` has a dependency on `ComponentB`, but rather than creating an instance of `ComponentB` inside `ComponentA`, the dependency is passed in as a constructor parameter. This allows the dependency to be easily replaced with a different implementation if needed, without having to modify `ComponentA`. 10.4. DIP stands for Dependency Inversion Principle, which is another design principle used in software engineering. It states that high-level modules should not depend on low-level modules, but both should depend on abstractions. This allows for more flexibility and easier maintenance, as changes to low-level modules won't affect the high-level modules. If a designer depends too heavily on concretions (specific implementations), it can make the system difficult to change and maintain. For example, if a high-level module directly depends on a low-level module, it can be difficult to change the implementation of the low-level module without affecting the high-level module. This can lead to a lot of code changes and potential bugs. By depending on abstractions instead, the system becomes more flexible and easier to maintain.
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值