Reputation
1,045
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
1 9 17
Impact
~31k people reached

  • 0 posts edited
  • 0 helpful flags
  • 179 votes cast
Feb
21
awarded  Notable Question
Jan
13
comment Anonymous namespaces make code untestable
@DocBrown, yes, I understand what you're saying. If I'd use a subset of C++ which would forbid me calling private functions outside of the class, then I'd have same problem as with anon. namespaces. However there is a clear answer to the "private functions problem" - C++ has the friend keyword for it, don't use such stupid subset of C++, it's not C# or Java!
Jan
13
comment Anonymous namespaces make code untestable
@DocBrown look, there is a big difference between "practically impossible" and "bad idea". There is the Chromium codebase. It uses friend class FooTest; in almost every class. No matter what experts say - it's a norm there, and the coding style guide agrees with that. So while it's important to listen to experts, one should stay pragmatic and think of more options than only "recommended by some theoreticians on the internet".
Jan
13
comment Anonymous namespaces make code untestable
@DocBrown private functions are perfectly testable, C++ has the friend keyword for it. Functions in anonymous namespace are not visible to tests at all (except for the trick with #include "foo.cpp" in foo_test.cpp, which is usually impossible because of the ODR)
Jan
13
awarded  Cleanup
Jan
13
revised Anonymous namespaces make code untestable
rolled back to a previous revision
Jan
13
comment Anonymous namespaces make code untestable
@DocBrown I'm not asking how to test functions in anon. namespaces. I'm asking "why put code into anon. namespaces?" (see the text at the end of the question). Blame Ixrec for changing the title to something different.
Jan
12
awarded  Yearling
Jan
12
revised Anonymous namespaces make code untestable
deleted 50 characters in body
Jan
12
asked Anonymous namespaces make code untestable
Jan
12
accepted Named output parameters vs return values
Jan
12
revised Named output parameters vs return values
added 71 characters in body
Dec
28
awarded  Good Question
Dec
27
awarded  Popular Question
Dec
26
awarded  Nice Question
Dec
26
comment Doesn't “always initialize variables” lead to important bugs being hidden?
Yeah, the example is no good. I'd remove it but that'd mess up the history.
Dec
26
comment Doesn't “always initialize variables” lead to important bugs being hidden?
@Mat that buffer[bytes_read] = 0 was just an example of a read operation. It could be anything, it doesn't really matter if there is a terminating 0 or not.
Dec
26
comment Doesn't “always initialize variables” lead to important bugs being hidden?
1) it's all about probabilities, like 1% vs 99%. 2 and 3) VC++ generates such initialization code, for local variables as well. 3) static (global) variables are always initialized with 0.
Dec
26
revised Doesn't “always initialize variables” lead to important bugs being hidden?
changed code example (2)
Dec
26
comment Doesn't “always initialize variables” lead to important bugs being hidden?
@Mat the design is bad, but it's not relevant here. That use thing could be a third party function (e.g. system).