This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
“using namespace” in c++ headers
I'm a c# developer in the WPF world, but I've decided to do all of my Winrt development in C++.
One thing im getting confused over is the use (or not) of using statements in header files (as opposed to typing out the fully qualified type names).
Its so much easier to have using statements in header files. A lot of the Microsoft Winrt samples include using statements in headers which keeps the code clear and easy to read.
However, I've been going through the c++ samples in the preview of John Petzolds new book, and he demands that headers be free of all using statements.
I dont understand the pro's and con's, and when I google it I get lots of opposing opinions.
Can anyone give me a definitive explanation of this issue as it related to the Winrt world (im not interested in c++ in other environments)
Thanks
In C++, it is very much customary to avoid using namespaces in header files, for several reasons.
Unlike C#, C++ doesn't have a nice tidy module system. Anything you do in a header affects every file which includes it. So if one header has a using namespace, if effectively pollutes not just the header file itself, but all files which include it. That can lead to surprising name clashes.
So in C++, the most common convention is this: never put using namespace in a header. In source files, you can do it if you want to, but many people avoid it even there.
Another reason is that this can actually aid readability:
If I refer to a vector<int>, it's not really clear what that is. It could be any vector class defined anywhere in any of my included headers.
But if I write std::vector<int>, then I know that this is the standard library header. It tells me where a type comes from. I think that makes the code both clearer and more easy to read.
Of course, there are tricks you can use to make this more manageable, if you refer to certain types a lot, or if certain namespaces have long, verbose names.
Long namespace names can be aliased:
namespace foo = VeryLongNamespaceName;
// now I can do foo::bar instead of VeryLongNamespaceName::bar
or individual names can be imported from a namespace:
using std::cout;
// now I can refer to `cout` without the std prefix
Of course, it is not a coincidence that C++ developers tend to use flat namespace hierarchies and short namespace names.
Nearly all of the C++ standard library is in the std namespace, which is a bit easier to type than the .NET equivalent. (std::vector<T> vs System.Collections.Generic.List<T>). Short names and a flat hierarchy means that you can actually live without using namespace statements.
Can anyone give me a definitive explanation of this issue as it related to the Winrt world (im not interested in c++ in other environments)
There is no such thing as "the WinRT world" in this context. If you write C++ code in your WinRT application, then you should follow C++ conventinos and best practices. If you write C# code in your WinRT application, then you should follow C# best practices, and so on.
Nowhere do WinRT guidelines state "please disregard everything you would normally do in the language you're using". WinRT is an API, not a language.
As for why Microsoft's samples do otherwise: they're samples. Their goal is to illustrate specific concepts and give you a starting point, and not to teach you to write good code in general. It is assumed that you can take the concepts they illustrate, and fit it into your own code without copying the various shortcuts taken in the samples. Many samples also omit error handling code for the same reason. It's irrelevant for the purposes of the sample, but certainly not irrelevant in a real application.
I am considering migrating from eclipse to vim for c++ development- I've recently "rediscovered" Vim, and finally went beyond the basics. I'm loving it, but there are still a few features that I use constantly in Eclipse that I'd also like to see in Vim.
One of them is call hierarchy. It's extremely helpful to know where a particular function/method is called throughout a project, and having an overview at a glance. Is there a similar plugin for that in Vim? Perhaps a combination of plugins/commands that are equivalent?
https://stackoverflow.com/questions/149558/recommended-vim-plugins-for-c-coding
A combination of the cscope and taglist plugins (linked from above) should give you what you want. Possibly cctree. All of these have problems with templates, however.
Also check out eclim
Eclipse has a built-in C++ parser that runs in the background and fully parses and semantically analyzes C++ code. This is what allows it to provide code completion, call hierarchy, refactoring and similar features.
I'm not aware of anything like that being available for vim. If someone knows something like that, I would be interested too.
I am currently working on a project. One library I would like to consider using in the future uses ToLua++ as a method of binding Lua. Currently, the library I am looking at is CEGUI, and it uses ToLua++. I am currently considering using LuaBind for the implementation in the project I'm working on. I was wondering if anyone would have any insight as to if that would cause clashes and break things, or if it would work just fine.
As long as you don't define the same Lua entities with both tools, LuaBind and ToLua++ coexist nicely. You can use either tool to add more functions and classes to a module, but you can't add more methods to a class defined by the other tool.
We are slowly moving towards better-standardized commenting in a large C++ project, introducing Doxygen. I personally find it a pain typing in comments, especially since Java IDEs are so good at automating this.
So I wondered what tools there might be? A search turned up DoxyComment which looks quite nice, is this the best/standard tool or are there others worth a look too?
Atomineer is a tool that I and a few others have been using for documenting unmanaged C++ code with Doxygen markup. It's not free, but it is cheap, and may be worth a try:
http://www.atomineerutils.com/products.php
If typing the meta-comments which are instructions to doxygen is a significant part of your comment-writing effort, you're doing it wrong.
Comment should not include things which can be automatically determined by a tool, any programmer will determine just as much (or more) information from e.g. parameter names than any tool.
Another way to look at this is that doxygen already does an excellent job of presenting what can be automatically determined. You don't need to write: "B::B constructs a B object", since doxygen is going to sort it into the constructors section of the documentation automatically.
Focus on what's non-obvious, and take time to think about what you're writing.
Normally many functions and variables will have no need for an individual comment, since either the name is descriptive enough, or they are better explained in a class-level comment describing how multiple members interact.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I use the Boost Test framework for my C++ code but there are two problems with it that are probably common to all C++ test frameworks:
There is no way to create automatic test stubs (by extracting public functions from selected classes for example).
You cannot run a single test - you have to run the entire 'suite' of tests (unless you create lots of different test projects I guess).
Does anyone know of a better testing framework or am I forever to be jealous of the test tools available to Java/.NET developers?
I've just pushed my own framework, CATCH, out there. It's still under development but I believe it already surpasses most other frameworks.
Different people have different criteria but I've tried to cover most ground without too many trade-offs.
Take a look at my linked blog entry for a taster. My top five features are:
Header only
Auto registration of function and method based tests
Decomposes standard C++ expressions into LHS and RHS (so you don't need a whole family of assert macros).
Support for nested sections within a function based fixture
Name tests using natural language - function/ method names are generated
It doesn't do generation of stubs - but that's a fairly specialised area. I think Isolator++ is the first tool to truly pull that off. Note that Mocking/ stubbing frameworks are usually independent of unit testing frameworks. CATCH works particularly well with mock objects as test state is not passed around by context.
It also has Objective-C bindings.
[update]
Just happened back across this answer of mine from a few years ago. Thanks for all the great comments!
Obviously Catch has developed on a lot in that time. It now has support for BDD style testing (given/ when/ then), tags, now in a single header, and loads of internal improvements and refinements (e.g. richer command line, clear and expressive output etc). A more up-to-date blog post is here.
Take a look at the Google C++ Testing Framework.
It's used by Google for all of their in-house C++ projects, so it must be pretty good.
http://googletesting.blogspot.com/2008/07/announcing-new-google-c-testing.html
http://code.google.com/p/googletest
Boost.Test does allow to run test case by name. Or test suite. Or several of them.
Boost.Test does NOT insists on implementing main, though it does make it easy to do so.
Boost.Test is NOT necessary to use as a library. It has single header variant.
I just responded to a very similar question. I ended up using Noel Llopis' UnitTest++. I liked it more than boost::test because it didn't insist on implementing the main program of the test harness with a macro - it can plug into whatever executable you create. It does suffer from the same encumbrance of boost::test in that it requires a library to be linked in. I've used CxxTest, and it does come closer than anything else in C++-land to automatically generating tests (though it requires Perl to be part of your build system to do this). C++ just does not provide the reflection hooks that the .NET languages and Java do. The MsTest tools in Visual Studio Team System - Developer's Edition will auto-generate test stubs of unmanaged C++, but the methods have to be exported from a DLL to do this, so it does not work with static libraries. Other test frameworks in the .NET world may have this ability too, but I'm not familiar with any of those. So right now we use UnitTest++ for unmanaged C++ and I'm currently deciding between MsTest and NUnit for the managed libraries.
I'm a big fan of UnitTest++, it's very lightweight, but does the job. You can run single tests there easily.
Great question! A few years ago I looked around forever for something worth using and came up short. I was looking for something that was very lightweight and did not require me to link in some libraries... you know something I could get up and running in minutes.
However, I persisted and ended up running across cxxtest.
From the website:
Doesn't require RTTI
Doesn't require member template functions
Doesn't require exception handling
Doesn't require any external libraries (including memory management, file/console I/O, graphics libraries)
Is distributed entirely as a set of header files (and a python script).
Wow... super simple! Include a header file, derive from the Test class and you're off and running. We've been using this for the past four years and I've still yet to find anything that I'm more pleased with.
Try WinUnit. It sounds excellent, and is recommended by John Robbins.
I like the Boost unit test framework, principally because it is very lightweight.
I never heard of a unit-test framework that would generate stubs. I am generally quite unconvinced by code generation, if only because it gets obsolete very quickly. Maybe it becomes useful when you have a large number of classes?
A proponent of Test Driven Development would probably say that it is fundamental that you run the whole test suite every time, as to make sure that you have not introduced a regression. If running all the tests take too much time, maybe your tests are too big, or make too many calls to CPU intensive functions that should be mocked out? If it remains a problem, a thin wrapper around the boost unit-tests should allow you to pick your tests, and would probably be quicker than learn another framework and port all your tests.
http://groups.google.com/group/googletestframework, but it's pretty new
I'm using tut-framework
Aeryn is another framework worth looking at
Visual Studio has a built-in unit testing framework, this is a great link to setting up a test project for win32 console application:
http://codeketchup.blogspot.ie/2012/12/unit-test-for-unmanaged-c-in-visual.html
If you are working on a static DLL project it is much easier to set up as other have pointed out external tesing frameworks like GTest and Boost have extra features.
CppUnit was the original homage to JUnit.
Eclipse/JUnit is a solid package for java, and there are C++ extensions/equivalents for both. It can do what you're talking about. Of course, you'd have to change IDEs...
I too am a fan of UnitTest++.
The snag is that the source distribution contains almost 40 seperate files. This is absurd. Managing the source control and build tasks for a simple project is dominated by looking after all these unit testing files.
I have modified UnitTest++ so that it can be integrated with a project by adding one .h and .cpp file. This I have dubbed "cutest". Details are at http://ravenspoint.com/blog/index.php?entry=entry080704-063557
It does not automatically generate test stubs, as asked for in the original question. I cannot help thinking that such a feature would be more trouble than it is worth, generating vast amounts of useless code "testing" accessor functions.
I would imagine automatically stubbing out test functions would be more of a function (of scripts for the framework or) the development environment in question. Supposedly CodeGear's C++Builder applications will quickly generate test code for user functions.
Andrew Marlow's Fructose library's worth checking out... http://fructose.sourceforge.net/
I recall his documents containing a fairly detailed analysis and comparison of other offering at the time he wrote Fructose, but can't find a URL direct to that document.
I'm trying out Igloo, also a header only C++ test suite, even it's two included dependencies are header only.
So, it's pretty straightforward and simple. Besides the included example on github, there's examples and more details at the main site, igloo-testing.org. I'll update this later as I get more experience with it and other frameworks.