我理解STL的概念必须存在,而实际上只有文档(人类)的概念并不能被翻译成C代码,所以称之为“类”或“接口”是愚蠢的,但是当给予机会扩展语言以适应概念时,为什么他们不简单地修改类和/或引入接口的功能？
不是一个非常类似于接口的概念(100％抽象类没有数据)？通过看,它似乎在接口上缺乏对公理的支持,但也许公理可以被引入到C的接口中(考虑到C中接口的假设采用接管概念),不可能吗？我认为甚至自动概念可以很容易地添加到这样的C界面(自动接口LessThanComparable,任何人？).
不是一个concept_map非常类似于适配器模式？如果所有方法都是内联的,则适配器本质上不存在于编译时间之外;编译器简单地用内联版本替换对接口的调用,在运行时直接调用目标对象.
我听说过一些名为静态面向对象编程的东西,它基本上意味着有效地重用通用编程中面向对象的概念,从而允许使用大多数OOP的能力,而不会导致执行开销.为什么没有进一步考虑这个想法？
我希望这一点很清楚.如果你认为我没有,我可以重写这个;只是让我知道.
解决方法
在OOP中,当您设计课程时,您会看到您认为有用的界面.完成了
另一方面,在通用编程中,只要类符合给定的一组要求(主要是方法,还有内部常量或类型),那么它符合账单并可能被使用.概念提案是关于形式化这一点,所以在检查方法签名时可能会发生检测,而不是实例化方法体.它还使检查模板方法更容易,因为如果概念不匹配,某些方法可以被拒绝,无需任何实例化.
概念的优点是,您不会受益于Predestination,您可以从Library1中选择一个类,从Library2中选择一个方法,如果适用,则为黄金(如果没有,则可以使用概念地图).在OO中,您需要每次写一个成熟的适配器.
你是对的,两者似乎相似.差异主要是关于绑定的时间(以及Concept仍然具有静态调度而不是类似于接口的动态调度的事实).概念更加开放,因此更易于使用.
