在使用 C++ 进行编程时,向您的合作程序员展示某些方法尚未在类中实现的方法;
在以下情况下可以使用什么方法:
- 您与其他几个(例如 1-3)个程序员一起处理一个小型 C++ 项目,您使用单个存储库
- 你创建一个类,声明它的方法
- 你还没有时间实现所有方法
- 您还不希望其他程序员使用您的代码(因为它尚未实现);或者不想使用代码中尚未实现的部分
- 你没有时间/机会向你的同事讲述所有这些尚未实施的事情
- 当您的同事使用您尚未实现的代码时,您希望他们立即意识到他们不应该使用它 - 如果他们遇到错误,您不希望他们想知道出了什么问题,搜索潜在的错误等。
What approaches can you use when:
- you work with several (e.g. 1-3) other programmers over a small C++ project, you use a single repository
- you create a class, declare its methods
- you don't have a time do implement all methods yet
- you don't want other programmers to use your code yet (because it's not implemented yet); or don't want to use not-yet-implemented parts of the code
- you don't have a time/possibility to tell about all such not-yet-implemented stuff to you co-workers
- when your co-workers use your not-yet-implemented code you want them to immediately realize that they shouldn't use it yet - if they get an error you don't want them to wonder what's wrong, search for potential bugs etc.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
最简单的答案就是告诉他们。当你与一群人一起工作时,沟通是关键。
更强大(可能也是最好)的选择是创建自己的分支来开发新功能,并仅在完成后将其合并回来。
但是,如果您确实希望在主源代码树中实现您的方法,但不希望人们使用它们,请使用异常或断言将它们删除。
The simplest answer is to tell them. Communication is key whenever you're working with a group of people.
A more robust (and probably the best) option is to create your own branch to develop the new feature and only merge it back in when it's complete.
However, if you really want your methods implemented in the main source tree but don't want people using them, stub them out with an exception or assertion.
我实际上很喜欢 .Net 中
NotImplementedException
的概念。您可以轻松定义自己的,派生自std::exception
,将what
重写为“未实现”。它的优点是:
I actually like the concept from .Net of a
NotImplementedException
. You can easily define your own, deriving fromstd::exception
, overridingwhat
as "not implemented".It has the advantages of:
您应该要么不提交代码,要么更好的是,将其提交到开发分支,以便在您的机器发生灾难性故障时至少可以离开您的机器。
这就是我在工作中使用 git 存储库所做的事情。我在一天结束时将我的工作推送到远程存储库(而不是主分支)。我的同事知道这些树枝非常不稳定,不要用十英尺的杆子去碰,除非他真的喜欢折断的树枝。
我想,对于这种情况,Git 非常方便,就像其他具有廉价分支的 dvc 一样。在 SVN 或更糟糕的 CVS 中执行此操作将意味着痛苦和磨难。
You should either, just not commit the code, or better yet, commit it to a development branch so that it is at least off your machine in case of catastrophic failure of your box.
This is what I do at work with my git repo. I push my work at the end of the day to a remote repo (not the master branch). My coworker is aware that these branches are super duper unstable and not to be touched with a ten foot pole unless he really likes to have broken branches.
Git is super handy for this situation as is, I imagine, other dvcs with cheap branching. Doing this in SVN or worse yet CVS would mean pain and suffering.
我不会将其签入存储库。
I would not check it into the repository.
声明一下。不要实现它。
当程序员使用调用代码的未实现部分时,链接器会抱怨,这对程序员来说是明显的打击。
Declare it. Dont implemented it.
When the programmer use to call the unimplemented part of code linker complains, which is the clear hit to the programmer.
断言是最好的方法。不终止程序的断言更好,这样同事就可以继续测试他的代码,而不会被您的函数存根阻止,并且他可以完全了解尚未实现的内容。
如果您的 IDE 不支持智能断言或持久断点,这里是简单的实现 (c++):
优点:
缺点:
PS 最初的 DEBUG_ASSERT 实现的积分归我的同事 EG 所有
Assert is the best way. Assert that doesn't terminate the program is even better, so that a coworker can continue to test his code without being blocked by your function stubs, and he stays perfectly informed about what's not implemented yet.
In case that your IDE doesn't support smart asserts or persistent breakpoints here is simple implementation (c++):
Advantages:
Disadvantages:
P.S. Credits for initial DEBUG_ASSERT implementation go to my co-worker E. G.
您可以对继承的类使用纯虚函数 (= 0;),或者更常见的是,声明它们但不定义它们。您不能调用没有定义的函数。
You can use pure virtual functions (= 0;) for inherited classes, or more commonly, declare them but not define them. You can't call a function with no definition.