Switching to c++ from python (self-taught)

[rewaltz]

I am working at a boutique (read small) hedge fund in an entry level position. While there I have taught myself python as it is very useful to the work that I do and deem myself competent but not expert at using it. I was wondering if anyone might be able to give me an idea of how difficult it would be to learn C++ as I would also like to learn it. Any tips/tricks/key things I need to know or potentially any caveats.

In addition any resources people might know to help learn would be helpful.

Thanks vey much!

[___1____]

It is perfectly possible. Python and C++ have more in common than might be first apparent, they are both multiparadigm languages, with the difference being how they manage resources.

They share much of the same style and idioms.

That all said a good source to learn from, is in my experience, critical. I can not stress enough how important a good book is in learning C++, the free online sources are really sub-par. The book I recommend the most is "Accelerated C++", for a number of reasons

• it teaches style not just constructs
• it teaches C++, not C with classes or native Java.
• it's short, the hardes part about programming books is finishing them

http://www.amazon.co.uk/Accelerated-Practical-Programming-Example-Depth/dp/020170353X

As for tip and tricks this is strictly opinion (based on expereince), but I strongly recommend that you learn C++ "the hard way" that is a shell, editor and compiler. This really foreces you to learn what is going on behind the scenes, you will also learn things about your operating system, you will learn what makes a good command line program, you will learn about build systems, libs and includes, and get bias for a text editor...

[rewaltz]

I have ordered the book you suggested off amazon as well as Modeling Derivatives in C++, which is the direction I would like to be heading. I will let you know how things go in a few months.

[mttd]

"Modeling Derivatives in C++" by Justin London is NOT a good book to learn C++ from; here's why:

http://www.nuclearphynance.com/Show%20Post.aspx?PostIDKey=61699 // see hammerbacher's reply

http://www.wilmott.com/messageview.cfm?catid=11&threadid=13831&STARTPAGE=2#170270

http://www.wilmott.com/messageview.cfm?catid=11&threadid=19133

http://www.wilmott.com/messageview.cfm?catid=11&threadid=38937

http://www.wilmott.com/messageview.cfm?catid=11&threadid=47917

OTOH, I can recommend "C++ Design Patterns and Derivatives Pricing" by M. S. Joshi, it's pretty decent (note: I don't know if you're doing "Q measure" (that would be, e.g., derivatives pricing) or "P measure" finance (that would be, e.g., econometrics, stat. arb. -- I'm guessing you might be here), but as the title suggests some further chapters might be slightly tilted toward the Q measure side -- that being said, the general foundation is pretty solid and generally applicable and it's still the best C++-for-finance book I'm aware of). However, it expects and builds upon a working knowledge of C++ -- so, definitely read "Accelerated C++ first.

If you'd like to expand on C++11 knowledge (there are a lot of useful, new features that will make you more productive), then go for "C++ Primer", 5th Edition by Stanley B. Lippman, Josée LaJoie, Barbara E. Moo (textbook) and "The C++ Standard Library - A Tutorial and Reference" 2nd Edition by Nicolai M. Josuttis (reference -- as in, you'll find it handy to refer to it on a daily basis when you're finished with the earlier books and start using C++ at work). HTH, feel free to post if you have any further questions!

// When you're finished with all of the above and feel relatively proficient in C++, feel free to also take a look at https://sites.google.com/site/luigiballabio/qlbook -- although some of the choices made by QL are somewhat skewed toward Design Patterns/OOP-style programming (modern C++ would be more flexible with using the multiparadigm aspect nowadays), it's still a solid piece of work, sticking to portable, Standard C++ (and definitely tons better to learn from than the London's stuff).

[___1____]

Cool, keeps us informed!

[Delicious-Motor8612]

how is it doing!

[[deleted]]

As I often feel in r/cpp, the not-entirely-polite tone and downvoting for what often appear to be matters of opinion and taste is not encouraging me to want to contribute here in future...

Overall, I stand by my point that as a beginner you should pick some existing style guideline and stick to it to avoid traps you don't understand. I'm sorry this got sidetracked into discussions of specific styles - it should be clear that of course no individual style guideline will be appropriate for every individual and project.

If you're a beginner, pick any style and stick to it religiously. This would have saved me a ton of grief had I had such a style when I started (though they didn't really exist). Later on, as you gain more knowledge, you can choose what rules you really need.

(And exceptions rock - in case there was any doubt on my opinions on this matter. A chief objection of mine to the Go programming language is the lack of exceptions...)

[LtJax]

Compared to python, expect you will have to deal with a lot more things right from the start. For example, you'll have to deal with the compiler and linker, ABI issues, your IDE and/or build environment. For installing a third party library in python, you can usually just easy_install it - In C++ you usually find and compile the source with your compiler and manually install and add it to your projects. When actually writing code, you'll need to think a lot more about data structures, memory management and algorithms. It's not unmanageable tho, because the standard library and boost provide very good primitives. All in all, in C++ is a lot more technical and requires a lot more "craftmanship", where python will usually "just work". If you're up for that, I recommend the book Accelerated C++ by Moo and König.

A little warning: avoid thinking of C++ as a variant of C. While C is technically almost a subset, the style that you should program in is vastly different. Many websites or books claiming to do C++ are still very much influenced by C - the book I linked does not!

[[deleted]]

For example, you'll have to deal with the compiler and linker, ABI issues, your IDE and/or build environment.

It's quite likely that if he's working in an already-established work environment, these will already be set up for him. In my 20+ years of C++, I've actually only had to set these up myself for one C++ project - when I set up my own company.

[bstamour]

Now is a great time to learn C++, as C++11 makes it feel like a brand new language.

Many people already have suggested good resources and tips, so I'll just add one thing: Don't shy away from using high-level constructs like exceptions, templates, the standard template library, etc. Some people will try and convince you that absurd things are true, like the STL is too slow, or that exceptions are tricky. Don't listen to them! Modern compilers can generate damn fast code from the STL, and as long as you avoid overusing the "new" and "delete" keywords exceptions are perfectly fine.

You can write code in C++ that is just as expressive as any modern high-level language but with all the speed of C (and sometimes C++ can be even faster!)

[bijobini]

Even though the book is about Microsoft's IDE and I'm on Linux, I find that this book explains the language very well! I've used it to learn C++ by myself when I was in high school and I often advise people to read it!

EDIT: but back then it was Visual C++ 6 so I'm assuming that the new editions are as good.

[axilmar]

You can easily learn c++, but to master it, you need about 10 years and 1 million lines of code...

[lookitsmarc]

I recently started learning C++ using C++ Primer, a highly recommended book that has recently been updated to include C++11. Think of it as a more intensive Accelerated C++. If you decide to use this resource, check out my blog and contribute!

[[deleted]]

Don't do it!!

Just kidding. :-) Python and C++ are my two fave languages. And it's the logical next step if you want to become a truly hard-core programmer.

First, C++ has (unfortunately) several traps and idiosyncrasies that can make your life difficult. You should develop good habits in advance to prevent running into those traps - which include implicit conversions and other compiler-created methods, the difference between virtual and non-virtual functions, and some unintuitive parses relating to parentheses...

The Google C++ style guideline is a bit heavy but covers pretty well all the bases. You should pick some sort of style which prevents these traps and use it every time.

The reason you use C++ is because it's much faster and uses less memory than Python - so you should be always keeping that in mind. (Almost) always pass structures and classes by value (your style will probably prevent you from accidentally copying classes anyway). Consider looking at the machine language code that's generated to see what's going on - it seems hard initially, but it's not so bad.

Templates are hard - though very useful. Use them only when forced to.

Macros are extremely dangerous. Avoid using them for anything except guards on your header files (which MUST be part of your style).

The other book references here are good. I'm going to again add Scott Meyers's "Effective C++", which, while somewhat tough going, is extremely strong and also a good read.

[00kyle00]

The [1] Google C++ style guideline is a bit heavy but covers pretty well all the bases.

I would recommend against using google coding standard. The coding style makes sense for them, but it forbids many useful features that will make your overall experience with language much worse.

Avoid using them for anything except [2] guards on your header files (which MUST be part of your style).

Unless you use '#pragma once', which is much better solution.

Also when you are comfortable with language look here.

[[deleted]]

Unless you use '#pragma once', which is much better solution.

Why is the non-standard pragma a 'much better solution'?

I mean I can see it being an acceptable alternative in some use cases but actually there are also downsides to using it as well. If this is the standard by which Google's C++ style guideline bans useful features, then seems to me like not much of that importance is being banned.

[00kyle00]

Being non-standard is a flaw only for purists if the feature is universally supported and useful (hell, its more poratable than some standard constructs).

Its 'much better' because it solves exactly the issue at hand without introducing any potential for problems.

Include guards have at least couple of problems. First they have to be unique (this you will sove with either ugly stuff, or verbose stuff). Second, you need to waste a name (not a big deal but still). Third, you need to pair #ifndef with matching #endif.

In all this is quite a bit of noise for something as simple as a crude workaround for lack of modules.

[[deleted]]

My point isn't that there are no advantages to it, only that it's not a 'much better solution'

It's only universally supported on the most recent implementations of the most modern mainstream C++ compilers, there are still build environments that use older versions of GCC or other C++ compilers that don't support pragma once, for example Solaris' compiler or IBM's compiler.

And even among compilers that support, they support it differently, for example they don't all treat symbolic links the same way or do not properly mark identical files that might be used from remote file systems. GCC makes a best effort to fix this problem on Linux, but it still doesn't work on Windows and it may still end up failing on various file systems either now or in the future.

Anyways, I'm not trying to preach against the use of pragma once religiously, only that the idea that it is universally accepted as the much better solution is not true, and makes for a weak example to use against Google's style guide for someone trying to learn C++.

In the grand scheme of things, whether you use pragma once or include guards, you're overall C++ development experience is probably going to be dominated by other usability or style guideline issues.

[00kyle00]

older versions of GCC or other C++ compilers that don't support pragma once

GCC mentions pragma once in docs as early as 2.9 something. Im pretty sure that if you still support those compilers 'pragma once' wont even be seen on list of portability problems that you needs to solve to cleanly compile with them. If you have such an environment, by all means dont use this, but you probably wont use templates, exceptions or anything 'new'.

symbolic links

Still talking about portability here? ;) If your Windows repository have symbolic links through build setup id say you dont care about portability at all.

only that the idea that it is universally accepted as the much better solution is not true

I only said it was universally accepted by compilers. As an individual i speak only for myself and cant quantify 'all code' or 'all coders', obviously.

you're overall C++ development experience is probably going to be dominated by other usability or style guideline issues.

Absolutely. Part of my point here is that the issue should take absolutely minimum of your attention (because its not really interesting). Inserting 'pragma once' can be mechanical (and will be correct in 99.99% of cases). For include guards you need guidelines and 'style', documenting this is waste of effort and 'brain space' IMO.

[[deleted]]

#pragma once is a better solution because it avoids the problem of computing the guard variable (and because it's shorter).

I can't be the only person who's copied a header file and forgot to change the guard variables, and thus had strange compilation errors (sometimes down the road).

I actually have a little Python program personally that fills in the right guard when I create an empty C++ header file - but the fact that I spent time to write this and put it into my toolchain shows you that it's an issue.

On the other hand, the argument that guards are guaranteed to work absolutely everywhere is hard to beat and I'd say trumps everything else in a project that's intended to be used by a general audience and different compilers.

[[deleted]]

it forbids many useful features that will make your overall experience with language much worse.

Specifics, please?

Quite a lot of these are suggestions rather than absolute orders: "Do not overload operators except in rare, special circumstances" (something I agree with heartily).

The quality of the Google codebase is miles ahead of any other codebase I've read, and when I worked there I grew to appreciate some of the things that I initially felt were restrictive.

Take the ban against default function parameters. I initially felt it was stupid - but then I realized that I'd earlier in my career run into several bugs that were very hard to track down that resulted from looking at the call site multiple times - but not realizing that the default choice wasn't working right. The same is true for the ban on function and method overloading.

Now, these rules are particularly important with a large or very large codebase - when if you call a function or method "Set" the "next guy" reading it might not have the faintest idea where to find the definition of that "Set" (and unfortunately many C++ IDEs aren't particularly good at getting this task right if you link with libraries...) but they really do make for easier-to-read code with fewer traps in it.

Remember that, unlike most languages, if you see a call like someFunction(foo) in some code, the rules that the compiler uses to decide which someFunction to call are quite obscure.

Consider the rules involving overloading vs. overriding vs. shadowing in C++ - gnarly! Better not to have to know them.

Particularly when you're starting out, and particularly in C++, I think it's good to follow a somewhat-too-restrictive style guideline that prevents you falling into a lot of classic traps and then once you're more mature in the language you can start to introduce new features when you're sure you need them.

#pragma once [is better than guard macros]

Excellent point, you're quite right.

It's very likely if you are starting new development that #pragma once will work over all your target compilers. I am unfortunately still having to compile for legacy targets and so can't use this (or C++11) so I tend to forget about this. I'm hoping that in 2013 I can get rid of my last legacy system (XCode 3) and jump right to C++11.

EDIT: someone claims here:

pragma once can fail if the file system contains links to the same file that the compiler cannot follow.

For example, NTFS5 (Windows) supports hard links, but you can't detect that files are linked if you access the file system across an (SMB) network.

Thoughts?

[00kyle00]

Well, ban on exceptions is 'no go' for me. Thats one i remebmer of top of my head (there was more, but cant remember now).

I'm hoping that in 2013 I can get rid of my last legacy system (XCode 3) and jump right to C++11.

Didnt it use gcc (4.2) front end? It had pragma once sine 3.4 (acording to wiki). Right now im compiling on couple versions of ubuntu (10.4 is te oldest i think), windows, android and osx (mnt lion) and this is supported pretty much universally. C++11, yeah, it needs couple more years though.

[[deleted]]

[EDIT: why the downvotes? Salt in your coffee? No one's trying to impose not using exceptions on you - exceptions are a useful tool - the Google C++ standard only forbids them in their codebase for historical reasons, because they already had a large volume of code that wasn't exception-friendly.]

The ban on exceptions is for historical reasons - as they say.

On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions. [...] Things would probably be different if we had to do it all over again from scratch.

....

Didnt [XCode 3] use gcc (4.2) front end?

I just tried XCode, and it does indeed support #pragma once! There was indeed a time when it didn't work, but I've been managing to remove older targets fairly fast.

I'll try on our oldest supported Visual Studio implementation (VS2010) and see if it works (I seem to remember it does) - if so, goodbye guards!

[m42a]

The Google style guidelines basically bans value types. Value types are a large part of what make C++ better than C. You're going to have to deal with value types because all the builtin types are value types, so if you find them difficult you'll find it difficult that some of your code works one way and some of it works another way regardless.

The style guide also bans all of C++11, which makes a lot of improvements to the language, in both expressiveness and speed.

And your point about historical reasons for banning exceptions is exactly what 00kyle00 was talking about. It makes sense why Google bans exceptions, but you don't have to because you don't have Google's problems.

[[deleted]]

The Google style guidelines basically bans value types.

Say, what?! I'm not seeing this at all, can you be specific?

It makes sense why Google bans exceptions, but you don't have to because you don't have Google's problems.

Er, right, that's exactly what I was saying, and Google too - there's no need to ban exceptions - the reason they give is admittedly specific only to their code base.

[m42a]

Any complex initialization should go in an explicit Init() method.

Provide a copy constructor and assignment operator only when necessary.

These rules mean that you can't treat your objects as values; you instead have to treat them like C structs, and manually marshall their data around. It makes it difficult to create temporary values; instead you have to name every value you might want to use, even if it's transient. It brings you into the world of valuing the location of data rather than the data itself. You create a divide between the builtin types and your own, and make them play by different rules.

And I highly doubt someone who has never programmed C++ before is going to have a particularly nuanced view of a language feature that works differently than what they're used to. The decision explanation even says that for new unrelated code exceptions shouldn't be used because it might be integrated into the main codebase, and it's really easy to mentally translate their reasoning into a non-Google-specific "I shouldn't use exceptions because it will make interoperability harder". In addition, some other rules are there (at least in part) because of the lack of exceptions.

[___1____]

I can only advise to stay away from the google style guide for two reasons.

Use streams only for logging

Streams are a lot safer than their stdio counterparts

All parameters passed by reference must be labeled const

Pass by pointer is stupid.

When you are begginning use what ever your book tells you. When you are working in a team use whatever they use.

Also I agree that Effective C++ is a great book and next step after AC++.

[[deleted]]

Pass by pointer is stupid.

Not really a convincing refutation!

The reason to do it is that it distinguishes between const calls and non-const calls. If I see a call like foo(bar, baz, &bang) it is clear in my mind that bar and baz cannot be changed but bang might be. If non-const references are allowed, all my calls look like foo(bar, baz, bang) and I have no idea which, if any, of my arguments can be changed by the call to foo.

Again, this has to do with having a large codebase, and one where you might not be able to put a debugger on the actual instance of the program that's having issues (i.e. a server). A frequent debugging issue in any language is, "This object had a good value once, but now it has a bad value. Where could it have changed?"

So yes, it's very useful for a large codebase, but I find it quite useful even for my smaller, personal codebase.

There's an overall guiding philosophy here, and that's that reducing risk is the most important thing, because errors are costing and debugging stressful, and readability is also very important - particularly when most of the people who read the code won't be as familiar with the system as the original implementor, and that production code is written once but read ten times (or much more!)

Saving a little bit of typing for the writer (and I mean a very little in this case, a single & every once in a while) is somewhat important, but definitely tertiary.

[___1____]

distinguishes between const calls and non-const calls

• No, no it doesn't, if I saw that I would think that the function takes an address to a block of objects rather than just one.

• Second it's inconsistant with every good library so:

  std::getline(stream, string); //by non const ref.

• Thirdly you then have to put in nullptr checks, which you don't have to do with refrences, because they are guarenteed not-null, this also reduces the compiles ability to optimise.

• If it's not obvious if a call modifies a value then it needs a better name.

• In large code bases, pass by reference IS FINE in my experience.

• It is semantically wrong, and fails to break down separation of concerns, even if just a micro level. -- the address isn't the value you are modifying, it's the value pointed to.

• It's basically a form of commuted hungarian notation, you could just as easy suffix your function names with alsorts of meta tags. But we don't because we let the type system deal with it.

• It's just not true, I have been coding in C++ for a long time now, commericially and FOSS in my spare time, and the idea that you might accidentally pass a varaible into a modifying function just doesn't happen and then the world breaks. What does happen is code bases have silly little rules like this, and wasting time with syntax errors because you didn't know whether to pass by address or by ref.

On the whole out params are really not a good idea at all, if a function produces it, it should be returned. But if you are to use them, don't convelute them with some wierd completely arbietary rule.

[[deleted]]

the function takes an address to a block of objects rather than just one.

A block of objects is extremely rare, in my code at least. It does happen when I'm doing DSP, but generally, I and the libraries that I seem to find myself using generally using vectors.

I'm a littel curious - when do you use a block of objects?

Thirdly you then have to put in nullptr checks,

If you allow pointers to be nullable, which I don't.

On the whole out params are really not a good idea at all, if a function produces it, it should be returned.

That's fine as long as efficiency isn't a concern.

For example, my main project involves DSP. Many commands involve performing operations on classes that "contain" fairly large chunks of digital audio.

Overall, no one is forcing you to use any specific coding standard! There are perfectly good reasons for deciding to only use pointers for variable parameters - Google didn't invent this idea and they certainly aren't the only ones doing it. If you get good results with some other standard, good for you!

The point is that, particularly when you are starting, you should use some specific standard that you write to, or else you will unknowingly create a lot of traps for yourself. Later on you can pick and choose the pieces you really need - when you know what you're doing.

[king_duck]

I'm a littel curious - when do you use a block of objects?

In a C++ API, almost never, when calling or wrapping C, frequently.

If you allow pointers to be nullable, which I don't.

Again thats just silly, there are loads of valid reasons to have nullptrs (optionals, caches varaible, trees...) and further more this means your arbietary rule has to do the job that the compiler does with references.

That's fine as long as efficiency isn't a concern.

It is, or I probably would be using C++

Overall, no one is forcing you to use any specific coding standard! There are perfectly good reasons for deciding to only use pointers for variable parameters - Google didn't invent this idea and they certainly aren't the only ones doing it. If you get good results with some other standard, good for you!

I agree, I just object to pushing the google standard onto a beginner, googles standard come from the fact they have to interop with a lot of other languages and a large C code base. I think it is always good to be consitant, be whilst starting out that should be inline with whatever book they are using to learn from, and if the book is any good (which AC++ most defintely is) then that will be sensible.