I've recently been relearning C++ and creating an application in hand with what I'm learning and even branching out to figure out concepts that aren't necessarily normal. As dangerous as I see this being, I am still diving head first.
That being said the application I'm currently working on requires storing some info in a local database which I will then be merging with a server database at some point in the future to allow for more in-depth queries and a better UI. While diving into learning SQLite3 integration with C++ I've found that a lot of the integration is specifically "C/C++" with, what appears to be, a stronger foot in C than C++. With this realization I've come across one very specific tutorial that leaned on C++ over C minus the specific issue I'm encountering.
https://www.dreamincode.net/forums/topic/122300-sqlite-in-c/
I actually rather like the concise nature of the Database.cpp that the author of the tutorial created and I want to utilize it. The problem is C++ likes to throw the conversion warnings that apparently work due to the use of C, but are deprecated in C++.
ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
Technically this can be bypassed by casting the string to (char*). While I understand this it seems I may be missing some information as well. Could this be bypassed by changing the parameters of the Database function to "string*" then converting it to "char*" in the function or should I not care about the implicit conversion and just ignore it. I really don't want to cross C and C++ in my application so I would prefer to paid heed to the warning. Figured I'd ask for advice to at least get some clarification though.
If it seems obvious from my inquiry that I am lacking in some very specific section of my C++ knowledge please feel free to let me know. I am nothing if not diligent when it comes to making sure I can fill all the gaps in my knowledge on any given topic.
You should tell the author of that tutorial to make his code const correct if you want to make use of his class.
Well, actually, I suggest you edit it yourself to make it conform. This won't take you long once you understand the principles involved (which are not hard to get your head around), and doing this will help you write your own code in the right way.
So, just by way of example, change this:
class Database
{
public:
Database(char* filename);
...
To this (note the added const):
class Database
{
public:
Database(const char* filename);
...
There are, of course, a bunch of other related changes you need to make but you just have to see it through, and the compiler itself will guide you when you get it wrong. SQLlite itself is already const correct (because those guys are professionals), so there is light at the end of the tunnel.
First of all, note that I'm using C++03 (and C++11 is not an option). I'm using boost concept to check that a certain class is default-constructible:
BOOST_CONCEPT_ASSERT((boost::DefaultConstructible<my_class>));
However, for some other class I'd like to assert that the type does not have a default constructor. Is there a way of doing this?
Update: to all those super-duper experts marking the question as duplicate or already answered without reading it: I state in the very first paragraph that I already use boost concept to check that classes are default-constructible (which is the question this is supposed to be a duplicate of). I also explicitly state that I can't use C++11, so type_traits are not available to me. So, could somebody please point me to the specific part where my question was "already answered"? Because I haven't found it yet.
The disappointing bit is that no, this is not possible with boost concept check.
The not so disappointing bit is: aren't you trying to use this tool backwards?
Generally, you write code that needs a type that has a certain number of features, such as constructors, functions that operate on that type, and so on.
I can't imagine a situation where you would write code that needs a type which lacks specific features.
You seem not to be wanting to do concept-oriented programming, but to enforce coding style.
And this is not the right tool for it.
I have a little bit of experience in C++. I know how to overload the plus sign and what not, but would like to overload the space operator.
For example:
MyObject obj();
result = obj - foo; // This would be treated as a normal '-' operation.
result = obj-foo; // This would invoke code which throws an assert at runtime
This would allow me to enforce certain style guidelines I'm trying to set forth for my team.
There is no space operator in C++. Whitespace is not significant in most cases, there is no difference from a parsing point of view between
a-b
and
a - b
Which I'm happy for.
Note: there are some corner cases (nested templates spring to mind) where it actually matters, but that's more of an artifact of the grammar than indications of the whitespace being active as an "operator", in my opinion.
Bjarne Stroustrup did at one time suggest allowing overloading of whitespaces [PDF]. But seeing as this article was published on April 1st he may not have been 100% serious...
The article is worth a read though.
There is no such item as the whitespace operator. In general in C++ whitespace is irrelevant and doesn't cause functionality differences in the program, hence there's nothing to overload.
What you're looking for is a static analysis tool for C++. Something akin to StyleCop for C++. Unfortunately I don't have a lot of experience in this area and can't recommend a specific program. Likely someone else on this thread will be able to though.
Sorry, not possible.
Instead look at code formatters - there are a few for every popular IDE (for example checkstyle for eclipse), or you can setup pre-commit hook in your version control system server, that checks if code before and after formattting is the same, and if not, it returns error instead of allowing to commit the code.
It's not possible. Space is not an operator. If you want to enforce style, use static code analysis tools and talk to your team members. Try cpplint or something similar.
If you want to enforce style guidelines, obtain a tool or application that can identify violations of style. A tool that can do this is Klocwork. There are probably smaller and simpler tools out there.
Worst case, write your own.
I'd recommend a look at Guy Steele's new HPC language: Fortress. It allows the overloading of the juxtaposition operator. There's also a blog post covering this aspect here. It's not going to help you with formatting, but it's rather funky. (Haskell and ML also use juxtaposition to apply functions).
I've found a few methods online on how to implement property-like functionality in c++. There seems to be some sound work-arounds for getting it to work well.
My question is, with the prevalence of properties in managed langues, should I spend the effort and the possibilty of code-breakage (or whatever) to implement properties in my code?
Say I'm going to dev up a library of calls for someone else to use, would properties be desired enough to validate the extra code?
What can you gain from doing this that you can't get from just using accessor functions?
It seems to me that while coding you ought to play to a language's strengths instead of getting it to emulate another language. So I'd vote no on this one. However, if you are writing in MANAGED C++ and are going to be using this code to interface with C# on a regular basis, and if for some reason you wanted to make the backend more usable by a native C# programmer, it might be worthwhile.
Unless you add reflection to the mix (being able to identify at runtime what properties exist on an object), properties are nothing more than syntactic sugar for getters and setters. Might as well just use getters and setters, in that case.
Properties with reflection can indeed be useful for C++ programs, though. Qt handles this quite nicely.
Properties are not idiomatic Standard C++ - as evidenced by the fact that there's no single "property-like" library in widespread use. The complexity of properly implementing them in conformant C++ is significant, while the benefits compared to direct invocation of accessor methods are small, and mostly stylistic. In my opinion, it's not worth the bother.
Properties actually prevent code breakage if done properly. It allows you to change the implementation of the property underneath without the caller having to change his code or even worry about it.
For instance, say you have a Socket class that takes a socket number. Implement as a property to just take an int and store it.
However your boss says that you should not accept socket numbers lower than 1024. Your property can change to scan for that and not accept the value.
No change to caller code.
Edit: A slight mis-understanding of the question...I took properties to mean normal accessor functions.
I have once tried to implement something similar to Matlab structures in C++, i. e. structures to which one can add named fields. After that I became a firm believer in the "Do Not Fight the Language" principle.
Efforts to make one programming language behave like another are often a special case of the inner platform effect.
I agree with others - just use getters and setters.
If you really need properties in C++, perhaps you already have them as a language extension. I think Visual C++ does - almost certainly for managed C++, but maybe for unmanaged too. Personally, the only reason I'd use them is in managed C++ to fit with .NET conventions.
Outside of that, creating an inner platform for this will almost certainly cause more problems than it solves.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What guidelines do you follow to improve the general quality of your code? Many people have rules about how to write C++ code that (supposedly) make it harder to make mistakes. I've seen people insist that every if statement is followed by a brace block ({...}).
I'm interested in what guidelines other people follow, and the reasons behind them. I'm also interested in guidelines that you think are rubbish, but are commonly held. Can anyone suggest a few?
To get the ball rolling, I'll mention a few to start with:
Always use braces after every if / else statement (mentioned above). The rationale behind this is that it's not always easy to tell if a single statement is actually one statement, or a preprocessor macro that expands to more than one statement, so this code would break:
// top of file:
#define statement doSomething(); doSomethingElse
// in implementation:
if (somecondition)
doSomething();
but if you use braces then it will work as expected.
Use preprocessor macros for conditional compilation ONLY. preprocessor macros can cause all sorts of hell, since they don't allow C++ scoping rules. I've run aground many times due to preprocessor macros with common names in header files. If you're not careful you can cause all sorts of havoc!
Now over to you.
A few of my personal favorites:
Strive to write code that is const correct. You will enlist the compiler to help weed out easy to fix but sometimes painful bugs. Your code will also tell a story of what you had in mind at the time you wrote it -- valuable for newcomers or maintainers once you're gone.
Get out of the memory management business. Learn to use smart pointers: std::auto_ptr, std::tr1::shared_ptr (or boost::shared_ptr) and boost::scoped_ptr. Learn the differences between them and when to use one vs. another.
You're probably going to be using the Standard Template Library. Read the Josuttis book. Don't just stop after the first few chapters on containers thinking that you know the STL. Push through to the good stuff: algorithms and function objects.
Delete unnecessary code.
That is all.
Use and enforce a common coding style and guidelines. Rationale: Every developer on the team or in the firm is able to read the code without distractions that may occur due to different brace styles or similar.
Regularly do a full rebuild of your entire source base (i.e. do daily builds or builds after each checkin) and report any errors! Rationale: The source is almost always in a usable state, and problems are detected shortly after they are "implemented", where problem solving is cheap.
Turn on all the warnings you can stand in your compiler (gcc: -Wall is a good start but doesn't include everything so check the docs), and make them errors so you have to fix them (gcc: -Werror).
Google's style guide, mentioned in one of these answers, is pretty solid. There's some pointless stuff in it, but it's more good than bad.
Sutter and Alexandrescu wrote a decent book on this subject, called C++ Coding Standards.
Here's some general tips from lil' ole me:
Your indentation and bracketing style are both wrong. So are everyone else's. So follow the project's standards for this. Swallow your pride and setup your editor so that everything is as consistent as possible with the rest of the codebase. It's really really annoying having to read code that's indented inconsistently. That said, bracketing and indenting have nothing whatsoever to do with "improving your code." It's more about improving your ability to work with others.
Comment well. This is extremely subjective, but in general it's always good to write comments about why code works the way it does, rather than explaining what it does. Of course for complex code it's also good for programmers who may not be familiar with the algorithm or code to have an idea of what it's doing as well. Links to descriptions of the algorithms employed are very welcome.
Express logic in as straightforward a manner as possible. Ironically suggestions like "put constants on the left side of comparisons" have gone wrong here, I think. They're very popular, but for English speakers, they often break the logical flow of the program to those reading. If you can't trust yourself (or your compiler) to write equality compares correctly, then by all means use tricks like this. But you're sacrificing clarity when you do it. Also falling under this category are things like ... "Does my logic have 3 levels of indentation? Could it be simpler?" and rolling similar code into functions. Maybe even splitting up functions. It takes experience to write code that elegantly expresses the underlying logic, but it's worth working at it.
Those were pretty general. For specific tips I can't do a much better job than Sutter and Alexandrescu.
In if statements put the constant on the left i.e.
if( 12 == var )
not
if( var == 12 )
Beacause if you miss typing a '=' then it becomes assignment. In the top version the compiler says this isn't possible, in the latter it runs and the if is always true.
I use braces for if's whenever they are not on the same line.
if( a == b ) something();
if( b == d )
{
bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}
Open and close braces always get their own lines. But that is of course personal convention.
Only comment when it's only necessary to explain what the code is doing, where reading the code couldn't tell you the same.
Don't comment out code that you aren't using any more. If you want to recover old code, use your source control system. Commenting out code just makes things look messy, and makes your comments that actually are important fade into the background mess of commented code.
Use consistent formatting.
When working on legacy code employ the existing style of formatting, esp. brace style.
Get a copy of Scott Meyer's book Effective C++
Get a copy of Steve MConnell's book Code Complete.
There is also a nice C++ Style Guide used internally by Google, which includes most of the rules mentioned here.
Start to write a lot of comments -- but use that as an opportunity to refactor the code so that it's self explanatory.
ie:
for(int i=0; i<=arr.length; i++) {
arr[i].conf() //confirm that every username doesn't contain invalid characters
}
Should've been something more like
for(int i=0; i<=activeusers.length; i++) {
activeusers[i].UsernameStripInvalidChars()
}
Use tabs for indentations, but align data with spaces
This means people can decide how much to indent by changing the tab size, but also that things stay aligned (eg you might want all the '=' in a vertical line when assign values to a struct)
Allways use constants or inline functions instead of macros where posible
Never use 'using' in header files, because everything that includes that heafer will also be affected, even if the person includeing your header doesn't want all of std (for example) in their global namespace.
If something is longer than about 80 columes, break it up into multiple lines eg
if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
BigVaribleIsValid(SomeVeryLongVaribleName))
{
DoSomething();
}
Only overload operators to make them do what the user expects, eg overloading the + and - operators for a 2dVector is fine
Always comment your code, even if its just to say what the next block is doing (eg "delete all textures that are not needed for this level"). Someone may need to work with it later, posibly after you have left and they don't want to find 1000's of lines of code with no comments to indicate whats doing what.
setup coding convention and make everyone involved follow the convention (you wouldn't want reading code that require you to figure out where is the next statement/expression because it is not indented properly)
constantly refactoring your code (get a copy of Refactoring, by Martin Fowler, pros and cons are detailed in the book)
write loosely coupled code (avoid writing comment by writing self-explanatory code, loosely coupled code tends to be easier to manage/adapt to change)
if possible, unit test your code (or if you are macho enough, TDD.)
release early, release often
avoid premature optimization (profiling helps in optimizing)
In a similar vein you might find some useful suggestions here: How do you make wrong code look wrong? What patterns do you use to avoid semantic errors?
Where you can, use pre-increment instead of post-increment.
I use PC-Lint on my C++ projects and especially like how it references existing publications such as the MISRA guidelines or Scott Meyers' "Effective C++" and "More Effective C++". Even if you are planning on writing very detailed justifications for each rule your static analysis tool checks, it is a good idea to point to established publications that your user trusts.
Here is the most important piece of advice I was given by a C++ guru, and it helped me in a few critical occasions to find bugs in my code:
Use const methods when a method is not supposed to modify the object.
Use const references and pointers in parameters when the object is not supposed to modify the object.
With these 2 rules, the compiler will tell you for free where in your code the logic is flawed!
Also, for some good techniques you might follow Google's blog "Testing on the Toilet".
Look at it six months later
make sure you indent properly
Hmm - I probably should have been a bit more specific.
I'm not so much looking for advice for myself - I'm writing a static code analysis tool (the current commercial offerings just aren't good enough for what I want), and I'm looking for ideas for plugins to highlight possible errors in the code.
Several people have mentioned things like const correctness and using smart pointers - that's the kind of think I can check for. Checking for indentation and commenting is a bit harder to do (from a programming point of view anyway).
Smart pointers have a nice way of indicating ownership very clearly. If you're a class or a function:
if you get a raw pointer, you don't own anything. You're allowed to use the pointee, courtesy of your caller, who guarantees that the pointee will stay alive longer than you.
if you get a weak_ptr, you don't own the pointee, and on top of that the pointee can disappear at any time.
if you get a shared_ptr, you own the object along with others, so you don't need to worry. Less stress, but also less control.
if you get an auto_ptr, you are the sole owner of the object. It's yours, you're the king. You have the power to destroy that object, or give it to someone else (thereby losing ownership).
I find the case for auto_ptr particularly strong: in a design, if I see an auto_ptr, I immediately know that that object is going to "wander" from one part of the system to the other.
This is at least the logic I use on my pet project. I'm not sure how many variations there can be on the topic, but until now this ruleset has served me well.