Can I prevent future developers from making an object constructable?

you have a class A, where you set ctor to be private, so a client can't call "A a;" to create obj on stack. But s开发者_StackOverflow中文版omeday another developer add a new ctor: "A(int)" and try to call "A a(1);" inside main(). So this will create a obj on stack. How do you prevent that?

If, as you imply, your class gets edited, then there is nothing you can do that can't be "edited away" -- your having only a private ctor was perfectly good protection, but it got edited away by that other developer. Just document very clearly that the class must never be edited to have public ctors, and, as a comment said, don't hire people who'd trample over such requirements!-)

Nothing you can do to C++ source code can constrain the future behavior of other people with permission to modify the C++ source code. That other developer could delete the string 'private:' just as easily as they could add a public constructor with another signature. All you can do is carefully comment the reasons why this class shouldn't ever be allocated directly, and expect other developers to read and pay attention.

Well, I can think of a few ways:

1. If you use some version control software (and you should!) you can set up commit hooks that prevent any changes on that file to be committed (or create a regex to only prevent adding new constructors).

2. You could also wrap the whole class into a DLL and require that project links to it and uses the public interface you export from DLL. They cannot change to source if they do not see it.

3. Hire a guy with a big baseball bat that stands next to developer. He should be wearing a T-shirt with "Class X constructor mustn't be changed" written on it.

The failure is the assertion that "nobody in the future could possibly use this in some way I haven't thought of."

Code your object defensively and make it fail spectacularly if it is not operating properly. Do not arbitrarily say "don't create this on the stack" and then make the ctor private; maybe I have a good reason to want to aggregate that object in another one.

Programmers should focus on making sure that the code they are writing works in the way they intended it to work, and they should also set things up so that it is obvious when something goes wrong what the problem is. Programmers should not encode arbitrary expected or desired or intended usage patterns into their software. Making a constructor private is just screaming at the user that they couldn't possibly be smart enough to build the thing themselves. Doing this will make many people use your factory interface or whatever you provide, but you don't know all possible future requirements so leave well enough alone.

If you're worried about others making changes and then you being on the hook for debugging it, write some unit tests. If you get a bug report that is not covered by your tests, then either write the test and fix the bug or figure out who made the change and bounce it to that person.