|
Writing a pool allocator to avoid malloc() overhead is a fairly common practice, dunno why this is somehow contentious. It's even in the C++ FAQ. Not sure what you mean by dynamic memory allocation being disallowed, though. I think you just mean that malloc() is disallowed? So that the program never runs into the OS returning out of memory errors?
|
#
¿
Nov 5, 2017 02:56
|
|
|
|
| # ¿ Apr 27, 2024 21:00 |
|
|
On Linux at least you can:code:
|
|
#
¿
Nov 13, 2017 01:25
|
|
|
Slurps Mad Rips posted:Look into clang-rename. Probably won’t solve all these issues but it can most likely help a bunch. (clang-tidy’s modernize settings might help as well) clang-rename is pretty beta and likes to break stuff involving shadow variables. There's proprietary tooling out there to modernize old C++ codebases that work better but generally refactoring on a grand scale is not a good idea if you're the only maintainer of legacy code.
|
|
#
¿
Nov 16, 2017 22:15
|
|
|
Alcatrash posted:I'm unfamiliar with C++ and figured I misunderstood strcmp. Is this for a C++ course? That code is very C. C++ has std::string which provides a guarantee that strings are null-terminated and provides the compare() function.
|
|
#
¿
Nov 18, 2017 02:44
|
|
|
Bruegels Fuckbooks posted:the best part is despite there being like 11 different string types available to you as a windows C++ programmer, there is no actual good string type even decades into c++ being a thing - they all suck, that's why people keep making more of them. The reason of course is that you slave away making an extensible string class that knows its encoding, knows its locale, will auto-widen on concatenation with strings in a different encoding, can auto-narrow and free memory if it's in an encoding that's too wide for its data, can do locale-aware comparisons, can try to guess encoding of a bytestream, has a constructor that works on literals with no overhe-- Then a man comes by your desk and says "gee there's a whole lot of overhead here, Dave, it's awfully complicated for a simple string, Dave" and then you start drinking heavily and have nightmares about code points.
|
|
#
¿
Nov 18, 2017 22:02
|
|
|
VikingofRock posted:Why does std::string get so much hate? It's always seemed pretty reasonable to me, but maybe I just haven't used a language with amazing strings / haven't run into the std::string pitfalls. Way too implementation-dependent, sometimes supports Unicode and sometimes doesn't, can't actually be derived from and extended unless you want to horrifyingly break things. When you run into issues with std::string then they pile up quick. Otherwise it's okay.
|
|
#
¿
Nov 19, 2017 01:11
|
|
|
Ladies and gentlemen, you've watched the bearded lady and you've seen the world's fattest man, but here I present to you a unique event: the reason why C++ strings suck.Ralith posted:What exactly do you expect your string container to do to "support Unicode?" Why is your software sensitive to its implementation details? Why do you want to, of all things, derive from it?!
|
|
#
¿
Nov 19, 2017 03:53
|
|
|
code:
|
|
#
¿
Dec 15, 2017 03:20
|
|
|
Plorkyeran posted:C++ jobs generally aren't the "gluing together libraries" sort of programming and so preexisting knowledge of the libraries they happen to be using is often unimportant. Yeah, this. Also a lot of libraries used in the codebase may be proprietary so it wouldn't be expected that you had any familiarity with them. I run into Boost (esp. threads, asio, filesystems) and Loki a lot. Then maybe Qt and OpenMP and Xerces but that's just my experience.
|
|
#
¿
Dec 18, 2017 20:44
|
|
|
C++17 (or whatever you know) rather than C++. Especially don't put C/C++ as a skill on your resume. Esp. if you're new to the industry, put your github on your resume with a project using some of the libraries I said before so you demonstrate that you can work with other people's code (they are way way better implemented than half the poo poo you will find in production but eh.) I'm not in charge of hiring but generally people get in because they could demonstrate C++ knowledge; C++ is a gigantic hell language so you're not expected to know all of it nor all of the third-party libraries. You're expected to know how to use it though and a personal project is a good demonstrator of that. e: also C++ might not be a good choice if you're trying to break into programming as a career regardless. The job market where I am for C++ is pretty dire. The Phlegmatist fucked around with this message at 15:35 on Dec 19, 2017 |
|
#
¿
Dec 18, 2017 23:53
|
|
|
Plorkyeran posted:Putting certifications on your resume is generally considered a negative signal. You mean you wouldn't want to hire a certified C++ GRANDMASTER? (to be fair that course is about writing a C++ compiler, you could literally just throw the code up on github after the certification but I don't know if I'd be impressed or somewhat scared)
|
|
#
¿
Jan 6, 2018 15:14
|
|
|
Jeffrey of YOSPOS posted:I think it will hurt performance if you use it as a drop in replacement if you ever copy them by value and rely on c arrays degrading to pointers in those cases. If you are writing new code, you can explicitly pass references or pointers around when you want them. Modern (C++14 compliant) compilers are technically smart enough to avoid this. The question would be what's gained by making C-style array declarations into std::array containers and the answer is...nothing.
|
|
#
¿
Jan 8, 2018 04:26
|
|
|
C++17 removes some stuff, most notably std::auto_ptr and the much-maligned dynamic exception specifications that everyone said "okay never use these" right after they were introduced. In general you should expect newer revisions to the standard to keep adding features and making C++ more conceptually complex, yeah. RAII, smart pointers and STL containers make C++ code easier to keep leak-free than C code, though. C++ should eventually have std::span<T> (C++20 maybe?) which is a non-owning view into a contiguous area of memory, making it easier and safer to work with C style arrays.
|
|
#
¿
Jan 8, 2018 18:42
|
|
|
Jeffrey of YOSPOS posted:Casting between pointer types in your function is a good sign that the strict aliasing assumptions are not true within that function, my complaint pretty much would go away if the spec was written such that it gave up its aliasing assumptions once that happened. That would complicate compiler design since you'd be adding a "look for a cast between pointer types in this scope" to your parser. Easiest way would be to add a nostrict or norestrict (to mimic C) keyword specifier for functions that could tell the compiler to not use strict aliasing in that scope. Submit a proposal to the C++ committee and see what happens!
|
|
#
¿
Jan 25, 2018 22:49
|
|
|
fankey posted:The pipe connects fine but readyRead() never gets called and it doesn't look like the messages I'm sending are making it either. It's been a while since I wrote Qt code for Windows but are you sending more data than can fit in the pipe's buffer? QLocalSocket won't handle the error and won't see anything to read in the pipe.
|
|
#
¿
Jan 30, 2018 00:54
|
|
|
Twerk from Home posted:
lol, you must be working at my job Anyway you'll need to go through every library call to disambiguate between Boost calls and stdlib calls. The interface for most of them is the same if the Boost libraries were ported to standard so it's not too difficult, just tedious.
|
|
#
¿
Feb 10, 2018 21:58
|
|
|
epalm posted:I guess Defender just sees some "bad" bytes in our executable? I've submitted the file to Microsoft. Anything I can do in the meantime? Yes, and not really. Certain things (monitoring the cursor or keyboard input, any sort of DLL injection) will make the heuristics in Windows Defender go crazy. It's probably your use of sed doing it, if I had to guess. You'll just have to wait for MS. e: If this is for end users then you'll probably have to end up digitally signing your executable with MS eventually assuming something in the code is making Windows Defender mark it as a false positive. New releases are going to flag it all over again. The Phlegmatist fucked around with this message at 19:29 on Feb 13, 2018 |
|
#
¿
Feb 13, 2018 19:25
|
|
|
Dren posted:Does gtest have modern c++ mocking yet or are they still weirdly resistant to modern c++ Nope. Google Test uses bugfuck insane macro wizardry to make unit testing easy. I assume that's why they can't easily move to C++11.
|
|
#
¿
Feb 27, 2018 05:31
|
|
|
In Google's defense, they did say that banning exceptions was a horrible idea and if they had the chance to do everything over, they'd make an exception-safe codebase. e: the weirdness with std::threads wandering off and calling std::terminate if not managed correctly is probably why they banned those initially. The Phlegmatist fucked around with this message at 20:54 on Feb 27, 2018 |
|
#
¿
Feb 27, 2018 20:50
|
|
|
baby puzzle posted:1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\xmemory0(737): error C2280: 'CoolText::RenderTextInfo::RenderTextInfo(const CoolText::RenderTextInfo &)': attempting to reference a deleted function Delete the copy-assign operator as well. Create a move-assign operator. Declare both the move constructor and move-assign as noexcept (std::vector uses std::move_if_noexcept under the hood) and this should hopefully point the compiler in the right direction.
|
|
#
¿
Feb 28, 2018 02:58
|
|
|
Hell, same. That's one of the features I love most about Kotlin. Yes it's just syntactic sugar but you know what happens when nested null checks are really gross and tedious to write? People stop writing them.
|
|
#
¿
Mar 2, 2018 18:24
|
|
|
Zopotantor posted:C++ changed a lot beginning with C++11. Unless you followed the development leading up to that, it can be a little overwhelming when you switch. I'm gonna laugh if the useless 2D graphics library (which is Stroustrup's white whale, I'm pretty sure) gets into the standard library before Concepts do.
|
|
#
¿
Mar 17, 2018 17:59
|
|
|
|
| # ¿ Apr 27, 2024 21:00 |
|
|
Dren posted:Wasn't what I expected. So why did they choose this behavior and not a compile time error? Is it just impossible/impractical to check all code paths? If so this seems like a good task to assign to a linter. Exhausting all code paths is technically the halting problem, so...no. You should still be using noexcept on anything that doesn't throw, though, since it provides hints to the compiler about what optimizations it can do and makes STL containers move your objects around instead of copying them (using std::move_if_noexcept.)
|
|
#
¿
Mar 26, 2018 21:43
|
|