Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[breadman]

I'd also be wary of a language that says it never segfaults.

C++ segfaults for a good reason: the code is designed to fail rather than perform illegal operations. If you have out of bounds array reads in Rust does it just keep chugging along and pretend everything is ok? C++ could do that, but the designers decided not to.

A segfault means you got lucky, and the operating system noticed the illegal operation.  It's also possible, and common, for out-of-bounds array reads in C++ to land in space that the program could normally access anyway, so it happily chugs along doing the wrong thing.  Entire classes of security bugs are caused by the flaws in C's language design principles, and C++ kept all of them.

A language that can't segfault protects you from such security holes by failing at a higher level.  Yes, that means a bit of extra computational power and time on random array access, and less powerful pointer arithmetic, but the trade-offs are worth it in the general case.  If you really need to squeeze an extra cycle out of a hotspot, you can give that bit the extra attention it needs to consider every possible input and code path; otherwise, it's helpful to get a nice traceback from the language itself.  Among other things, throwing an exception can give your program another chance to respond appropriately.

C++ fails when you make a range of glaring errors. That enforces discipline in checkng that you are indeed coding logically correct structures. Merely promising not to fail no matter what you do doesn't make your code magically correct.

C++ makes it easy to fail in ways both subtle and catastrophic when you make a wide range of errors that even a seasoned programmer can have a hard time noticing.  This requires more discipline than the average programmer has, to code absolutely correct data access pathways without moving on as soon as it seems to work.  Relying on the operating system to kill your program if it does something monumentally stupid doesn't make your code magically safe.

[da_nang]

To be fair, C++ out-of-bounds memory access is undefined behavior. It's entirely up to the OS how that is handled.

For instance, from what I recall, freeing a memory block doesn't necessarily mean you'll get a segfault should you access that block again as long as the block hasn't been allocated elsewhere.

I'm not quite sure what you mean by the block being "allocated elsewhere" - by another program or the same program? If it's the former, virtual memory prevents programs from accessing each others' memory in the same way as their own. There's no way a program could accidentally access another program's memory (without going through OS-specific APIs, etc.).

If it's the latter (e.g. a program allocates a block with addresses 100-200, frees it, and allocates another block which happens to have the same address), that's worse - as far as the OS is concerned, that program can access those addresses freely, regardless of whether the program intends to access data stored in that block previously or in the "new" block in the same location.

(That may be unclear; I had to write this quickly, but let me know if I need to clarify anything.)

The way I understand it is that with standard C/C++ you can malloc/new pointers, write to them, then free/delete them and it's possible to still access the written data without necessarily getting a segfault.

It depends on how the OS manages the virtual memory. Of course, any OS worth their salt will isolate allocated physical memory of different processes and page stuff in/out so two processes can't access each others memory, though I wouldn't be surprised if some sneaky guy managed to circumvent the memory management system somehow. (Embedded systems sometimes require using physical addresses for e.g. IO.)

Seeing as sometimes you may get data, sometimes garbage even if you had written to it before also tells me that it works over paging and the OS isn't copying back and forth deallocated memory (beyond a limit, anyway, due to OS typically allocating more memory than necessarily needed). Either that or the address translation table is doing some shenanigans to deallocated memory.

[Pseudo]

On a semi-related note, has anyone else seen the GCC 7 (preliminary) release notes?

They (finally) catch a lot of obvious errors at compile time. And prettily too:

void* f (int mday)
{
  char *buf = malloc (3);
  sprintf (buf, "%02i", mday % 100);
  return buf;
}

warning: 'sprintf may write a terminating nul past the end of the destination [-Wformat-overflow=]
note: 'sprintf' output between 3 and 4 bytes into a destination of size 3

test.c:51:29: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'int' [-Wformat=]
   printf ("foo: %d  bar: %s baz: %d", 100, i + j, 102);
                          ~^                ~~~~~
                          %d

[Reelya]

Visual studio already triggers on a lot of those problems, and more assertively than warnings.

e.g. Visual Studio won't compile at all if you have a printf with the wrong number of parameters for the format string, or if any of them don't match on type. Not just a warning. And using things like sprintf that can overflow bounds is an outright error, with the suggestion of one that allows you to specify limits, unless you add in a special macro that overrides deprecation.

It's nice for the compiler to check that sprintf is not overflowing a set-sized array but what if either the input or output are of indeterminate size? That warning message is shown to be a very limited use-case, and you could just recommend to use a newer replacement function that doesn't suffer from that probllem in the first place, and works for variable-sized input/output as well, which just pointing out the bounds problem in sprintf for this one case (as a mere warning) doesn't actually do.

[Pseudo]

It's nice for the compiler to check that sprintf is not overflowing a set-sized array but what if either the input or output are of indeterminate size?

This sort of response makes it sound like you are saying that the improvement is a bad thing. Is that your intention?

There are multiple levels:

 -Wformat-overflow=1 only warns about cases that are most likely going to overflow (e.g. 'char buf [12]; sprintf (buf, "a = %i, b = %i\n", a, b);' - even if a and b are both 0 this still overflows.).

-Wformat-overflow=2 also warns if there exists some value that when passed into a function would cause an overflow. This leverages the existing bounds checker that GCC uses for its optimizations.

-Wformat-nonliteral (not new) warns if the format string is indeterminate.

Visual studio already triggers on a lot of those problems, and more assertively than warnings.

GCC can do that too with -Werror. (And yes, it can do so selectively - -Werror=foo will turn warning foo into an error, and can be repeated as necessary.) The only difference here is by default GCC warns, whereas by default visual studio errors.

And yes, this feature is mainly catching up with clang. Compilers tend to do that back and forth - one compiler does something new, then everyone else realizes it's a good idea and implements their own version. Rinse. Repeat. For a long time GCC's warnings / errors was a weak point. With GCC 6 & 7 that's changing.

[Reelya]

People often get lots of warnings and ignore them. A warning is weaksauce.

The warning is also only relevant for a small subset of the problem (sprintf of a set-sized string into a set-sized container). Which implies it's not even going to warn you in the actual real-world situation where this becomes a real problem - sprintf where either the input string's length isn't known at compile time, or the buffer size is not known at compile time.

It's not that adding the warning is a bad thing, the fact that this warning is needed directly indicates they don't have the more robust error-checking that would prevent you doing the questionable operation.

[alway]

As I've read and agreed with before, the main benefits of C++ are the standard library (C++11/14/17), the ability to manage your own memory, and template metaprogramming. If you aren't using any of those things, you're better off with another language.

No one language is superior to any other; they're just different tools for different purposes.

C++ metaprogramming is actually kind of notoriously painful to use with every step of the pipeline. Which leads to the most commonly underestimated point wrt programming languages: tooling. 99% of your job is interacting with programming tools: the debugger, intellisense/autocorrect/suggestion features, the code editor, profilers, third party libraries, etc. These are the things which, in reality, determine how you use a programming language.

Take the boost library, for example; it's a great example of template metaprogramming hell that shows why template metaprogramming is *not* a feature you want to interact with in C++. You end up with compile errors and warning that look like this: https://twitter.com/mitsuhiko/status/834550427488247809
Attempting to use the debugger on such structures usually leads to jumping around seemingly random places in code, with no clear picture of what's going on; very similar to trying to parse the above excerpt.
Template metaprogramming can also can slow down compile time immensely. Typical large game engines take ages to compile to begin with; anything that makes it worse is just stealing time out of the entire studio's day.
There are languages much more oriented towards metaprogramming than C++; I haven't used them, but presumably their IDEs would be designed to handle this better; at the very least, the abomination above shows there's light years of design space improvements you could make over common C++ tooling.

In contrast, consider the use of structs and classes in C++. Most people make heavy use of them, often more than is necessary to do what they need to; but it's obvious why they do. Type in "myObject." and visual studio pops up a handy list to autocomplete, showing you every function, piece of data, enum which is relevant to what you are doing, and no more. Come back a year later, or have a junior developer take over an unfamiliar subsystem? Now you don't even need documentation; the IDE practically instructs the programmer on what is relevant, what isn't, and what they should read code for before continuing.

Then there's the "standard" library, which for all its standardization is often spotty at best in terms of implementation on a given platform with a given compiler. For multiplatform, multicompiler projects, that makes it very dangerous to use. Many game dev studios have their own stripped-down implementations of the standard library features they use for this reason. So again, a case of a reasonable language feature which gets ignored because of tooling issues. But beyond that, other languages (C# springs to mind) do have more helpfully designed standard libraries than C++.

Overall though, the external tooling component of things is what usually results in using C++, as is the case for most languages. Want to do deep learning? Python or Lua because that's where the good libraries are at. Want to do console development? C++, since that's the only thing you can compile and run on all of them with reasonable quality guarantees.

[McTraveller]

Come back a year later, or have a junior developer take over an unfamiliar subsystem? Now you don't even need documentation; the IDE practically instructs the programmer on what is relevant, what isn't, and what they should read code for before continuing.

This makes me believe you have never actually been the one to come back to code "a year later".

I would also say: If you have to rely on an IDE to understand code, the code could be improved*.
I would couple that with: code (especially without documentation) can only tell you what the code does, not what the code is supposed to do.

*This is not to knock the utility of things like Intellisense - it does indeed make writing code easier.  But if you can't find where something is declared easily without search and autocomplete, or you have to rely on it to know what members are in your struct/class, that code is getting unwieldy and is probably subject to worse issues than compiler errors or warnings.  There is after all the old (?) adage:  "Yay my code compiles! Now let's find out what the real bugs are..."

[itisnotlogical]

Is it feasible to be a "real programmer" (ie have a paid position at a company of some kind, writing some kind of code) if you hate C/++?

There is no way around it. I've tried using C with different IDEs, tools and aids (including none of those at all) for tasks of varying difficulty. It is still far and away the most tedious and annoying language I've ever attempted to learn. There is so much time spent on header files and templates and forward declarations and why compilers don't like certain situations and it's all just so fucking tedious. Writing C gives me the same feeling as doing my taxes. It feels like a meta representation of the paperwork and meetings and email chains that programmers at "real jobs" complain about, built right into the very work itself.

[da_nang]

Not every product uses C/C++, so yes, I imagine you could get hired.

[TheBiggerFish]

"You don't need documentation"
*froths aggressively*

THERE IS NEVER ENOUGH DOCUMENTATION.  EVER.

I am a (relative) novice and I can tell you that.

[Arx]

But good code is self-documenting!

But seriously, if your code is straightforward, well set-out, and commented on occasion, docs don't have to be extensive.

Is it feasible to be a "real programmer" (ie have a paid position at a company of some kind, writing some kind of code) if you hate C/++?

There is no way around it. I've tried using C with different IDEs, tools and aids (including none of those at all) for tasks of varying difficulty. It is still far and away the most tedious and annoying language I've ever attempted to learn. There is so much time spent on header files and templates and forward declarations and why compilers don't like certain situations and it's all just so fucking tedious. Writing C gives me the same feeling as doing my taxes. It feels like a meta representation of the paperwork and meetings and email chains that programmers at "real jobs" complain about, built right into the very work itself.

Yep. I worked in Python, LaTeX, and XML for a couple months over the summer holiday.

[itisnotlogical]

I'd argue that even if it's not necessary, reading a page or two of online documentation with a search bar is much easier than hunting through a potentially massive source to find the information you need.

[alway]

So working backwards: Good code is documentation. There's high level overviews of 'this is the intent of this vast construct that is our program and what we want it to do and where we want it to fit in' which can be separate, but for the daily work intent should be clear simply based on patterns and idioms. For example, if you see code like:

Code: [Select]

int n;
api::Foo( nullptr, n );
char* data = new char[n];
api::Foo( data, n );You can tell what that code is doing as well as knowing that api makes use of the pattern in which you call twice, get a size the first time, then fill a buffer with that size the second time. If it was your company's api, you should also know to use that pattern if it becomes relevant for your work. Name the api and function appropriately (FileSystem::Read? NetworkLayer::ReadPacket? GPUContext::CopyBuffer?) and you know exactly what it does and who owns what at the end of it. Basically all code you will ever write in a job setting is banal stuff doing mundane things a slight permutation away from how a million other programmers did them over the years. Leave documentation for the bits that are non-trivial or non-obvious; like the weird looking workaround you did to work around a unicode bug when you did NetworkLayer::ReadPacket( data, n/2 ) on a string of Japenese characters that one time. If a system is complicated enough to need documentation, it's also complicated enough to produce so much documentation that left unchecked, no one will bother to read the documentation.

I mean, if you use proper asserts, you can make template metaprogramming compilation errors work just fine. That's what Eigen does.

Again, it's not that you *can't* use them, it's that you've got an added layer of friction to doing so.

Is it feasible to be a "real programmer" (ie have a paid position at a company of some kind, writing some kind of code) if you hate C/++?

There is no way around it. I've tried using C with different IDEs, tools and aids (including none of those at all) for tasks of varying difficulty. It is still far and away the most tedious and annoying language I've ever attempted to learn. There is so much time spent on header files and templates and forward declarations and why compilers don't like certain situations and it's all just so fucking tedious. Writing C gives me the same feeling as doing my taxes. It feels like a meta representation of the paperwork and meetings and email chains that programmers at "real jobs" complain about, built right into the very work itself.

Depends on what type of application you want to write, but in general, yes. C/C++ are awful in those regards largely because of age. Header files are kind of an abomination tbh, and mostly come down to 'we do this so the compiler doesn't have to.' Without a complete survey of today's trendy languages, I would say it's probably safe to say most of them don't get bogged down in those things. Whether you find that's a good thing or not depends on how recently you've wrestled with a misbehaving package manager.

C++ is and will always be the go to language for 'does everything passably' and so will always be in demand, but for most specialties that are focusing on one particular aspect, other languages and tools are used because lower level code is a distraction. Things like neural network machine learning, for example, have tools that at the heart are compiled C/C++, but which are so standardized that nobody cares to rewrite that basic stuff. The field is concerned more about neural network operators and chaining together various inputs and outputs such that actual work and innovation occurs primarily in higher level languages like Python/Lua through use of frameworks like Tensorflow, Theano, Torch, etc. Nobody there cares about allocating and freeing memory and who owns what pointers; with faster iteration times, they could be getting a 100x speedup by tweaking their algorithm instead of 50% speedups from optimizing their memory use slightly better than a pre-built solution. There are also domain-specific languages, with R being a notable one among statisticians. And that's not even getting into the trendy language-of-the-month used for Silicon Valley apps or the massive regions of web coding.

Come back a year later, or have a junior developer take over an unfamiliar subsystem? Now you don't even need documentation; the IDE practically instructs the programmer on what is relevant, what isn't, and what they should read code for before continuing.

This makes me believe you have never actually been the one to come back to code "a year later".

I would also say: If you have to rely on an IDE to understand code, the code could be improved*.
I would couple that with: code (especially without documentation) can only tell you what the code does, not what the code is supposed to do.

*This is not to knock the utility of things like Intellisense - it does indeed make writing code easier.  But if you can't find where something is declared easily without search and autocomplete, or you have to rely on it to know what members are in your struct/class, that code is getting unwieldy and is probably subject to worse issues than compiler errors or warnings.  There is after all the old (?) adage:  "Yay my code compiles! Now let's find out what the real bugs are..."

Programmers take the path of least resistance. Intent not imparted through code is mostly intent wasted. Basically nobody reads documentation unless they're already facing a bug or something is really ambiguous. Between function, argument, and variable names, I would contend that things just plain shouldn't be that ambiguous. On the rare case they are, that's what comments are for. Beyond that, there's the occasional idioms that need explaining, but those are just as often done better in person, as they tend to weave together high level vision and low level reality in a way that isn't easily conveyed through documentation. Some things just need tutorializing; but those tend to be in the 'what is possible' space more than anything tied to code.

Sure, you can do find in files; that's the entire reason I have notepad++ on my work machine (a tangent I will get back to, as it's notable in its own right). But in combination with even trivial polymorphism and C++'s love of header and cpp file separation, now you're searching through several files for an implementation, following a chain of dependencies attempting to find the source. If that was what developing with object oriented approaches meant, it would be seen/derided as an obscure hobby like pure functional programming often is. This is where the tools come in.

Intellisense (of which the autocomplete you mentioned is a part) gives you a list of functions, shows you the comments around them, can link you to their implementations for further detail, and can help discover things in large interfaces. It serves a similar role to NEI mods in minecraft -- I may not know how to transfer this RF power, but I know if I type in 'cable,' 'conduit,' or 'duct,' I will probably find something to do what I want so long as I have a general sense of what is possible, what I want to do, and commonly used terms to do them. It, and solutions like it are probably as big a part of OO's success out in the world as anything else.

(As for the tangent: Intellisense *doesn't* always just work. Sometimes, often with special project setups or very large projects, these tools fail. Intellisense is notoriously crashy and locks up Visual Studio on things the size of a game engine. Sometimes, they just aren't pointed at the right place and fail entirely or in part for certain libraries. Failures of these tools adds a lot of friction to things like OO code -- which results in less OO code being written in those spaces.)

[Skyrunner]

I disagree that nobody reads documentation

The first thing I do whenever I want to figure out how to use someone else's function or library, I search for documentation. Big projects that are well-maintained (like, say, Unity or Flask or Python's standard library) are wonderful in this regard. Looking at the code is a last-resort and is often not what you should reach for first, just because it takes soooo long to parse.

Of course documentation has to be maintained, just like code.