|
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. Lurkin noob here. I'm just taking my first C++ class. This hackerrank place has the same kinda stuff we're doing as projects. 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. The Dentist consider updating that OP? It'd be awesome if someone did. Some links are broken and I didn't find it hellua useful.
|
# ? Oct 6, 2016 15:09 |
|
|
# ? Jun 8, 2024 07:52 |
|
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.
|
# ? Oct 6, 2016 16:49 |
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
|
|
# ? Oct 6, 2016 17:51 |
Ralith posted:That site is frequently outright wrong. Use cppreference instead. Really? I've always thought people just liked the layout of cppreference better. What are some things that cplusplus.com is outright wrong about?
|
|
# ? Oct 6, 2016 18:33 |
|
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? 15 years ago IIRC we already had the STL and (some) compilers that could handle it. 20 years ago you had cfront and whatever lovely class library your vendor supplied (I'm looking at you, HP codelibs ).
|
# ? Oct 6, 2016 19:03 |
|
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? Depends a lot on how much back do you want to go. It is also important to realize that compilers and code tends to push each other... as compilers get better at aggressively inlining code created by nested templates, people get better at creating nested templates for crazy compile time magic.
|
# ? Oct 6, 2016 19:03 |
Xarn posted:Depends a lot on how much back do you want to go. 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.
|
|
# ? Oct 6, 2016 19:18 |
|
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. Most games / game companies don't use STL. Even today.
|
# ? Oct 6, 2016 19:36 |
xgalaxy posted:Most games / game companies don't use STL. Even today. 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?
|
|
# ? Oct 6, 2016 19:44 |
|
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?
|
# ? Oct 6, 2016 19:59 |
|
Star War Sex Parrot posted:The STL implementations are probably too slow for gaming purposes. See: EASTL The EASTL is a good example of one large game companies ideas and thoughts and actual implementation. Other game companies will have their own "base libraries" of containers, and algorithms, etc. A lot of them will be less template heavy than STL and EASTL. xgalaxy fucked around with this message at 20:26 on Oct 6, 2016 |
# ? Oct 6, 2016 20:22 |
|
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?
|
# ? Oct 6, 2016 21:35 |
As far as I know, 15 years ago compiler support for C++98 was still somewhat flaky and you had to be really careful and possibly limit yourself in features used, if you wanted your code to build on a variety of compilers. But all of that improved greatly within the following 5 years. If you want to see the insanity that could cause, find some really old versions of wxWidgets, version 2.2 or 2.4 should showcase some of the ugly things you had to do if you wanted to work on every compiler. nielsm fucked around with this message at 23:14 on Oct 6, 2016 |
|
# ? Oct 6, 2016 23:12 |
|
Star War Sex Parrot posted:The STL implementations are probably too slow for gaming purposes. See: EASTL 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.
|
# ? Oct 7, 2016 00:04 |
|
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. Historically, some STL implementations have done all sorts of silly things that perform well in synthetic benchmarks and abysmally in the real world. Copy-on-write strings, for example.
|
# ? Oct 7, 2016 03:16 |
|
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:
|
# ? Oct 7, 2016 07:01 |
|
rjmccall posted:Copy-on-write strings are a really interesting case. ^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.
|
# ? Oct 7, 2016 13:16 |
|
leper khan posted:^a good post. Counterpoint: anything written using Qt
|
# ? Oct 7, 2016 20:41 |
|
leper khan posted:^a good post. string_view is definitely worth having but it's really easy to gently caress up an implementation if you don't even know what a quarter of the std::string functions do and have never tried to implement them yourself (and boost::string_ref didn't exist yet ) (It's also easy to adapt string_view if you're stuck with someone's bespoke string type)
|
# ? Oct 8, 2016 06:00 |
|
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? /*Given an array containing both negative and positive integers. Find the contiguous sub-array with maximum sum. Input: The first line of input contains an integer T denoting the number of test cases. The description of T test cases follows. The first line of each test case contains a single integer N denoting the size of array. The second line contains N space-separated integers A1, A2, ..., AN denoting the elements of the array. Output: Print the maximum sum of the contiguous sub-array in a separate line for each test case. Constraints: 1 ≤ T ≤ 40 1 ≤ N ≤ 100 -100 ≤ A[i] <= 100 test input Example: Input 3 3 1 2 3 4 -1 -2 -3 -4 5 -2 -1 -2 -3 -4 Output 6 -1 -1 */ code:
LLSix fucked around with this message at 20:48 on Oct 8, 2016 |
# ? Oct 8, 2016 16:53 |
|
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?
|
# ? Oct 8, 2016 20:25 |
|
I didn't check if your algorithm worked or not, but your code reads more like C to me than C++. I slapped this together, it seems to work. code:
Is this more efficient? I have no idea. If you were going to do much more complicated things I would probably wrap the entire array into an object. Then you could do things like stream the input directly into the object, have the object keeping track of what the elements in the biggest subsum are, etc, and easily access all of that without getting too overly complicated.
|
# ? Oct 8, 2016 20:29 |
|
That should really be a const reference. (it should really be a span, but for some reason those aren't going to even be in C++17... can always pull in the GSL, though)
|
# ? Oct 8, 2016 20:40 |
|
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.
|
# ? Oct 8, 2016 20:42 |
|
Klades 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".
|
# ? Oct 8, 2016 20:44 |
|
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? 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). Klades posted:more c++ version Thank you. It's helpful to see what someone more familiar with C++ libraries might do.
|
# ? Oct 8, 2016 21:01 |
|
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. Except that it's backwards?
|
# ? Oct 8, 2016 21:01 |
|
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? Never use malloc/free in C++. Unless you have a very good reason, you shouldn't even be using new/delete. If you really need to allocate something on the heap, std::make_unique and friends are much less error prone. You adjusted brace style is still pretty wacky. Most people use something like Klades'. 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. Ralith fucked around with this message at 21:18 on Oct 8, 2016 |
# ? Oct 8, 2016 21:14 |
|
Subjunctive posted:Except that it's backwards? That's why I said "in place of your conditional"
|
# ? Oct 8, 2016 21:25 |
|
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. Round 2: code:
Subjunctive posted:Unless I missed a definition of current somewhere, that doesn't compile. Typos. Klades fucked around with this message at 21:52 on Oct 8, 2016 |
# ? Oct 8, 2016 21:49 |
|
Unless I missed a definition of current somewhere, that doesn't compile.
|
# ? Oct 8, 2016 21:50 |
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:
Joda fucked around with this message at 23:41 on Oct 8, 2016 |
|
# ? Oct 8, 2016 23:20 |
|
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.
|
# ? Oct 8, 2016 23:58 |
|
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.
|
# ? Oct 9, 2016 00:29 |
|
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. Oh, is it a vector? Over what field? If C++ has vectors, why can't it have modules?
|
# ? Oct 9, 2016 00:59 |
|
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 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. Fergus Mac Roich fucked around with this message at 01:38 on Oct 9, 2016 |
# ? Oct 9, 2016 01:35 |
|
Why not use std::array, you know the size and it's const
|
# ? Oct 9, 2016 01:55 |
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. It's very possible that the algorithm is invalid, but those two cases return -1 and 400 respectively. My thinking is that the only point at which we're no longer interested in the current tally is the one in which it has become negative and the next number in line is of a higher value than the tally. In that case the highest possible tally from the current position is the one from the next value forward. In all other cases we can assume that the current tally is valid as the highest possible value at our current point from the previous reset point (and by extension this holds for the whole array as well.) Remember that max holds the value from when the tally was at its highest point. Joda fucked around with this message at 02:25 on Oct 9, 2016 |
|
# ? Oct 9, 2016 01:55 |
|
Okay yeah, sitting down in front of a computer I can see why that should work(and why it doesn't fail in those cases).
|
# ? Oct 9, 2016 02:27 |
|
|
# ? Jun 8, 2024 07:52 |
|
Malcolm XML posted:Why not use std::array, you know the size and it's const You'd have to always use a 100 element array, since that's the max size known at compile time. Arguable whether that's better than using a vector.
|
# ? Oct 9, 2016 02:28 |