LLSix posted:

I've been writing C for the last few years and would really like to brush up on c++ for job hunting. What are some good ways/sites to practice c++ coding? I found HackerRank earlier today but so far the problems have been pretty easy and I'm worried I'll blitz through them in a week or two.

Solvent posted:

Cplusplus.com is a nice reference that I'm always looking at to see what libraries I need to include, and what the hell things like argv[] mean.

Ralith posted:

That site is frequently outright wrong. Use cppreference instead.

Shy posted:

I don't know if that's better suited for the general programming thread but I've been meaning to ask about C++ standard/compiler progress over the last 15-20 years. If I understand it correctly C++11 and newer is mostly supported across all modern compilers and performs well, but let's say 15 years ago would a team choosing it over C for a large project encounter many additional difficulties compared to now?
I'm not looking for a detailed answer (though if you have an article handy that would be cool), mostly just want to get an idea of how bad C++ compilers used to be compared to C. My C++ experience is reading the first 200 pages of the stroustrup book

Shy posted:

I don't know if that's better suited for the general programming thread but I've been meaning to ask about C++ standard/compiler progress over the last 15-20 years. If I understand it correctly C++11 and newer is mostly supported across all modern compilers and performs well, but let's say 15 years ago would a team choosing it over C for a large project encounter many additional difficulties compared to now?
I'm not looking for a detailed answer (though if you have an article handy that would be cool), mostly just want to get an idea of how bad C++ compilers used to be compared to C. My C++ experience is reading the first 200 pages of the stroustrup book

Xarn posted:

Depends a lot on how much back do you want to go.

Shy posted:

I was looking at some developer job positions in gaming industry to get an idea of how their languages and requirements for prospective employees have changed. I figured in, let's say, 1996, C would've been an obvious choice for a new or ongoing project, closer to 2000 I saw a line about "understanding tradeoffs between c and c++", even further the requirements shifted towards C++, and that got me wondering what those tradeoffs were back then. But I guess Zopotantor narrows it down well, it would probably be STL support and vendor libraries that made the most difference.

xgalaxy posted:

Most games / game companies don't use STL. Even today.

Shy posted:

I'm probably confused then, I thought most companies would use it before the standard library became what it is, they still use the standard library to some extent, right?

Star War Sex Parrot posted:

The STL implementations are probably too slow for gaming purposes. See: EASTL

VikingofRock posted:

Really? I've always thought people just liked the layout of cppreference better. What are some things that cplusplus.com is outright wrong about?

Star War Sex Parrot posted:

The STL implementations are probably too slow for gaming purposes. See: EASTL

rjmccall posted:

Let's be clear here. The STL is not, like, implemented by idealistic idiots who don't give a poo poo about performance. There are some specific data structures and optimizations that game developers like which aren't provided/supported well by the STL, like slab allocation, intrusive linked lists, and hashtables. Other than that, a lot of the differences are trade-offs which aren't necessarily as obvious as some people want to believe; and then there is a huge amount of superstition.

rjmccall posted:

Copy-on-write strings are a really interesting case.

C++ programs back in the day used to do a really ridiculous amount of copying. That's been somewhat addressed with C++11 and move semantics, so now the level of spurious copying in a typical C++ program is just "too high" instead of "wildly excessive", but of course that's new to this decade. Strings in particular tend to have a fairly simple lifecycle of being built up / broken down in a single step and then copied all over the place; and the STL provides an obvious API for building up a string (stringstream) that in theory ought to be preferred over repeated += and have significantly better performance. So the basic idea of optimizing for copies over direct mutation is actually a pretty sound one. Of course, people who set out to write a "string benchmark" in practice end up writing something that just bangs on mutations instead of reflecting the real workload on the type, but whatever.

The problems are:

• The language completely betrays copy-on-write types; all sorts of logically non-mutating operations end up looking like mutations in the type system. For example, code like std::string str = ...; char c = str[0]; invokes a non-const subscript operator and thus would naturally do a unique-and-copy check unless you do a lot of complex proxying (which you can't necessarily do with, say, iterators).
  
• Copy-on-write reference-counting has to be atomic in a multi-threaded process. Atomic increment/decrement used to be really expensive, even for completely uncontested accesses (typical for copy-on-write data structures). This is much less true now; it's closer to one order of magnitude more expensive than two. But people mostly formed these opinions back then.
  
• Streams in the STL are a very bloated and inefficient abstraction; what in principle could be as efficient as "prepare a buffer, append all these things to it, and do a little tidying when you're done" ends up doing a lot of dynamic crap, so just using += is actually seen as a major optimization.
  
• Copy-on-write strings aren't really friendly to a small-string optimization because it would add another dimension of complexity to an operation that's already pretty complex. Small-string optimizations can be a major win just from doing less allocation. They also cut down on the costs of spurious copies, since spurious copies of small strings are cheaper and spurious copies of large strings are more likely to be algorithmically significant enough to skew a profile.
  
• Copy-on-write types benefit a lot from a specialized optimizer that's aware of them, but library-specific optimizations are not common in C++ compilers.
  

leper khan posted:

^a good post.

Not using std::string (or wstring, ..) has been a pretty strong leading indicator that I'm going to be dealing with a house of horrors. At least for projects started in the past 5-ish years.

leper khan posted:

^a good post.

Not using std::string (or wstring, ..) has been a pretty strong leading indicator that I'm going to be dealing with a house of horrors. At least for projects started in the past 5-ish years. It's very easy for people to write things that are less performant and more broken when they think dealing with strings is easy and people who wrote the STL are obviously dumb because they read something like that but far more nuanced on the internet once.

As with all things, it's not a problem until you've benchmarked. If you aren't in a place where you can benchmark and you don't have a suitable replacement with several years of industrial use behind it, you have better things to be working on than std::string being too slow for your non-extant application.

LLSix posted:

I'm trying to reteach myself c++ and I found this sample interview question which really threw me for a loop (took me like me almost two hours to wrap my head around the problem and find a decent approach). I think I ended up with basically Kadane's algorithm without tracking the indices of the subsum. Is there a better approach to this? Is there a more efficient way to write this in c++. Critically, did I screw something up?

Klades posted:

Klades posted:

I slapped this together, it seems to work.

Ralith posted:

Your brace style is... unconventional, and this is really C code, not C++. You also seem to be stack-allocating a dynamic array, which is a language extension and generally not a great idea. What compiler are you using that didn't warn you about that?

Klades posted:

more c++ version

sarehu posted:

You should pass the vector by const reference, there's no reason to use iterators, and there's no reason not to use max_sum = std::min(max_sum, current_sum); in place of your conditional.

LLSix posted:

Ha, ha, yeah That makes sense. I've been writing C code for the last few years and I just started trying to relearn the C++ style since that seems like what most open positions need. Do you have any suggestions for learning more C++ style approaches or example code I should look at?

Sorry about the braces. That's just what HackerRank does and since I have a few coding interview tests in it coming up I'm trying to get used to it. No reason you should have to though. It should be tidied up now.

I'm using HackerRank's default C++ compiler right now. Not the C++14 one, the other one. Maybe C++11?

Thank you for pointing out the array. I was a bit surprised it let me get away with that. I should have used malloc/free (or really a vector).

Subjunctive posted:

Except that it's backwards?

fritz posted:

If I saw this in code review the first thing I'd ask after Ralith's comment about const ref is "why not use a ranged-for".

sarehu posted:

You should pass the vector by const reference, there's no reason to use iterators, and there's no reason not to use max_sum = std::min(max_sum, current_sum); in place of your conditional.

Subjunctive posted:

Unless I missed a definition of current somewhere, that doesn't compile.

Ralith posted:

The best way to learn good style is to make contributions to a project that already has it and where someone qualified will review your changes. Find a major open source project you care about and jump in! You can also review a few different prominent style guides; Google's is popular but a bit outdated.

csammis posted:

I don't think anyone's mentioned it yet but I'm cringing at a vector named array. I know that's not the OP's code but still, yikes.

Joda posted:

This is more a question of algorithm design than C++, but I don't think that algorithm solves the problem, Klades? You seem to assume that as soon as you hit a negative integer the subarray resulting from a further search cannot be larger than the one you are currently investigating, but what about the case {10,10,-1,10,10}. The largest subarray here has the size 39 (includes all elements,) but your algorithm returns 19 because it stops searching and starts a new search at the -1.

I think this works?

C++ code:

int max_subsum_of_array(const std::vector<int>& array) {
  if (array.size() == 0) {
    throw std::runtime_error("Your array is empty doofus");
  }

  int max_sum = std::numeric_limits<int>::min();
  int current_sum = 0;

  for (int num : array) {
      if(current_sum < 0 && current_sum < num)
          current_sum = num;
      else
          current_sum += num;

        max_sum = std::max(current_sum, max_sum);
  }
  return max_sum;
}

E: Fixed redundant expression

Fergus Mac Roich posted:

I believe this will fail on -1, -3. I'm on my phone so I can't check my work properly but it looks like your code returns -4, whereas the answer is -1.

Or 400, -401, 1.

I may be wrong but it would surprise me to learn this problem has a linear solution.

Malcolm XML posted:

Why not use std::array, you know the size and it's const