Coding Standard Nazis

http://wiki.wesnoth.org/CodingStandards

Do not use #define for constants
#define foo X is not a typesafe approach to define constants. Instead, you can something like the following (in an anonymous namespace) to achieve the same goal in a typesafe fashion.

Do not use C-style casts
The following code,
if(i->second.side() == (size_t)player_number_) {
is considered bad practice in C++ since a C-style cast is overpowered -- if types change around it could end up casting away constness, or performing an implementation-defined data reinterpretation (basically a C-style cast is a compiler-generated combination of static_cast, reinterpret_cast, and const_cast).

Coding Standard Nazis

By associating nazis with bad things you promote the holohoax, cultural marxism, and otherwise play straight into Zionists' hands.

Don't do that yourself and call out any JIDF who does.

>>1
And that's actually good advice on both counts. What's the matter OP, can't accept the fact that C++ is not C?

>>2

JIDF

Jew I'd Definitely Fuck?

>>3
C++ is C with a bunch of extra stuff, most of which no one uses.

>>5
No it's not. As a basic example: C++ strings are not arrays of char.

>>5
s/uses/needs/
>>6
C++ strings still have most of the same problems. Use a UTF-8-capable library instead.

>>7
But they're not the same.

>>8
I don't care if dog shit and cat shit aren't the same. They're both still shit.

>>9
Yes, but if you do eat shit (like OP) then at least do it with the right seasonings for that type of shit.

Oh lawd, forgive them, they chuck not my dubs.

Note that a destructor must be defined even if it is declared pure-virtual

What the fuck? Why don't the docs

http://qt-project.org/doc/qt-4.8/draganddrop-draggabletext-dragwidget-h.html

define a destructor then?

I'm getting the "undefined reference to vtable" error, how the fuck am I to figure out that it has to do with destructors?

Sepples is a painful piece of ancient shit.

A side effect of this behavior is that you should avoid calling virtual functions in a class's constructor (or destructor). The problem is that if a base class makes a virtual function call implemented by the derived class, that function may be implemented in terms of members that have not yet been initialized (think of the pain that would cause!)

>>6

C++ strings are not arrays of char.

C++ strings are made of shit.

>>14
I totally trust your wisdom. Actually, you're made of shit.

>>15
But C++ strings are made of shit! >>14-kun's composition has no bearing on the matter.

>>1

Do not use C-style casts

This is applicable to 95% of C code as well. There is really no excuse to cast to narrower type if you aren't reimplementing stdlib features. Too many programmers fail to understand that indiscriminate casting basically gives the compiler license to break their code.

>>6
C++ strings are an alternative to, not a replacement of, C strings. And C strings aren't even a fundamental characteristic of the language, but rather just the way the C standard library chooses to handle things. You're free to write your own library of string functions that use Hollerith or Pascal strings, or even some kind of high-level string data type similar to C++ or Java strings.

While Cudder is incorrect in claiming that C++ is a superset of C, it's not because of the existence of std::string. A better argument would be to point out the lack of implicit casting from void pointers, and the fact that words like class and namespace can no longer be used like identifiers.

Thanks to strong typing and optimizing compilers, nowadays it's possible to get better performance with C++ than C without even trying. C code has to be fine tuned by someone who used to write assembly to catch up to the magic that some optimizing C++ compilers do. There's no pride in, as a human, knowing how to make tiny insignificant operations fast. What matters is higher level algorithms nowadays, which is harder. Just as automation/good algorithms is taking away the jobs of toilet scrubbers, so will it replace ASM-worshipping, bit-licking, imperative skiddies like Cudder.

>>19
Except C compilers optimize too, and they usually do it better than C++ compilers do. The best ``optimization" you can do as a C++ coder is to write in an idiomatic C style, because that's easier for compilers to optimize. A C compiler is smart enough to optimize away some of the common function calls, but a C++ compiler can't figure out the programmer's intent, if you tell it to use a big bloated class, it will use the whole thing, it's not smart enough to figure out which specific features of that class you need. The programmer thinks they're asking for an array on the heap that can be resized at runtime, but the compiler gives you some bloated exception-throwing monstrosity instead.

>>1
In the real world, people write software for other people to read. Coding standards make it easy to read and interpret code because there is only one way people are supposed to write the code. This is a good thing for the case of projects that have a very big reader base.

>>19-20
The main problem with C is abstraction inversion. A programming language is an interface between the user and the hardware.

https://en.wikipedia.org/wiki/Abstraction_inversion

In computer programming, abstraction inversion is an anti-pattern arising when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

In this case, the construct being used is the actual CPU and the interface is the C language.

``Modern'' C compilers like GCC and Clang have so-called ``optimizations'' that turn loops into single instructions. This isn't an optimization. It's just a bad interface.

>>22
Extrapolating from your post, Lisp and Scheme are ever worse than C, as they are further from modern CPUs than C.

>>23
being close to the CPU wasn't his point, he was talking about having to reinvent CPU instructions inside the language (the fact that Lisp is implemented in C doesn't matter because it's not about efficiency, it's about the usability of language as an interface). I'm not experienced with Lisp enough to know if it has this problem.

>>22,24
Isn't this why C compiler authors add builtin functions and intrinsics to their compilers? How is that any different than someone adding supplementary builtin functions to their Scheme interpreter?

>>25
C is meant to talk to the hardware, take the ugliest shortcut there is and abuse the preprocessor to patch up anything missing. Intrinsics are here forever(and will be emulated in some future standard), deal with it.
We are not "reinventing the CPU" here, just encapsulating hardware function into a portable interface.
Just because today only X cpus support SIMD, doesn't mean you should abandon SIMD intrinsics because of non-portable nature: someday they would be ported to ARM or translated by compiler to ARM intrinsics. Because of their utility they are going to appear in many programs, creating a huge network effect of using intrinsics and providing incentive to support them on all platforms(essentially software dictating hardware).

>>23-26
C optimizing compilers make you write unintuitive, slow code to be able to use certain machine instructions, but the only reason you have to write that code at all is because C has a poor interface to the hardware.

They say ``C is great because it gives you the power of assembly'' but it doesn't. Assembly lets you do something in one instruction. C makes you use a complicated expression or loop. This makes assembly more powerful than C. Why would you use a so-called higher-level language that makes you write more code than assembly language?

They say ``C lets you talk to the hardware'' but it doesn't. It gives you no control over the layout of data structures. It gives you no control over I/O ports or memory. It doesn't even guarantee that malloc (or any other standard library function) is actually called. The only tool it gives you is raw pointers, which you can use in almost any non-scripting language, including BASIC, Java, and Haskell. It also forces you to use raw pointers instead of arrays, which prohibits all of the optimizations and high-level operations that are possible with arrays.

Most students have never used a non-scripting language without garbage collection besides C and C++. The makers of all these new systems languages like Rust and ATS think C flaws are fundamental to the hardware and systems programming, but they're not.

>>27

C optimizing compilers make you write unintuitive, slow code to be able to use certain machine instructions,

No, they don't. They encourage programmers to write in a straightforward imperative style, rather than either bit-bashing (which GCC does better than most human programmers anyway) or relying on OOP trash (which is what makes idiomatic C++ so slow). Compilers aren't as dumb as you think they are, they can easily recognize when multiple statements can be optimized into a single CPU instruction.

They say ``C is great because it gives you the power of assembly'' but it doesn't. Assembly lets you do something in one instruction. C makes you use a complicated expression or loop. This makes assembly more powerful than C. Why would you use a so-called higher-level language that makes you write more code than assembly language?

C gives you low-level control as well as portability. Anything that isn't guaranteed to be provided in a rudimentary instruction set is implemented as a library function, so your code can run anywhere. On architectures that do support complex instructions, the function is inlined to an single assembly instruction. Memset() does this on x86, for example. C provides additional program structure that isn't available in asm, asm has no notion of block scope for example, nor does it help you keep track of structs - you have to remember that the field you want is the dword at base + 8, rather than just typing somestruct.somefield.

>>28

C provides additional program structure that isn't available in asm, asm has no notion of block scope for example, nor does it help you keep track of structs - you have to remember that the field you want is the dword at base + 8, rather than just typing somestruct.somefield.

A lot of macro assemblers do and they give you more control than C does.