What are advantages of using Sepples?

1.templates are easily replaced by macros and _Generic (which selects arguments by compile-time type(without any float/int promotions!)
2.function overload is replaced by above as well.
3.Classes are essentially structs with function pointers.
GCC supports constructors(attribute constructor) and destructors(attribute cleanup) in plain C
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
http://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html
4.constexpr can be rewritten as expression macros ({macro;return var;}) which will be optimized via constant propogation(but unlike constexpr can be runtime dependent).
5.GCC has new apply function for plain C
https://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing-Calls
6.Thread-safe atomics built-ins in Plain C
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins

7. Job Security

>>1
If you thought reading OOP in C++ was bad, reading OOP in the style you're advocating would be a fate worse than never ending Lisp parens.

>>2
Instant Job Security. Debugging Macros.

JACKSON FIVE GET

Aside from job security, namespaces. It's the only thing I wish C had. Admittedly, if namespaces were added to C it'd probably ruin the language.

>>6

namespaces

Literally syntax sugar and since "muh namespace pollution" people still write std::forward and mylib::myfunc
which is as east as std_forward and mylib_myfunc
Plus they add a fun game of finding "what namespace we are using at this line?" every time "muh namespace pollution" occurs.

Not one comment about operator overloading and lambdas/functors?
Does /prog/ actually use them in Sepples?

People hate macros because their shitty IDEs do not support syntax highlighting inside them.

>>8

operator overloading
lambdas

These are two conveniences that I wish C had. First-class functions are extraordinarily useful, and it's nice to be able to type v1 += v2 instead of v1 = vec2_add(v1, v2). Clang has support for blocks, which are a decent enough alternative to lambdas.

On the other hand, I don't understand the point of wrapping things up into classes. If you want an object-oriented approach in C, you can do:

typedef struct {
// ...
} MyStruct;

...

my_struct_operation(MyStruct *s, ...);

Make MyStruct an opaque type and define getters, setters, and a constructor for it if you need really that level of encapsulation.

In C++, you have structs AND CLASSES that can both have functions defined within them, while private properties are defined in the headerfile. Wtf? It's literally the same amount of typing (or more) than what you'd get in C, two keywords that do the same thing, and it violates the fundamental tenets of encapsulation. This is the defining feature of C++ compared to C, yet it wasn't necessary to write a new programming language to do this.

>>10
You can actually write lambdas(through expression macro abuse) in plain C
http://www.codeproject.com/Tips/614570/Lambda-in-C-GCC

>>11
GNU C is not ``plain C"

>>12
+1
A lot of GNU C extensions are probably cool and all, but GNU C is now a language by itself, which fragments the ecosystem.

>>10

while private properties are defined in the headerfile. Wtf?

Likewise, what the literal fuck.
It brings barely any advantages for being an absolute nuisance.

Who in the right mind thinks "golly gee wiz better shoehorn that geat ol' pImpl idom into every class because it's so fucking convenient eh, Strusdroop sure is a clever guy".

>>14
It's because the class declaration is useless unless its size is known.

>>10
Clang has __attribute__((overloadable)) for function overloading in C as well.

There are literally no disadvantages to using Sepples. Only use the features you want. The code will be so much more maintainable, faster to execute, and easier to read if you can go without having to reinvent the wheel. "But how do I keep myself or others from using those bad features?" Well, you braindead codenigger, here's one idea: Write a quick program (of course in another language, since C-family languages aren't for real programming) to put in the Makefile that detects if X supposedly bad feature is used. Problem solved. Now go back to writing enterprise quality apps (TM).

>>16
That is inferior to _Generic since it introduces name mangling.
_Generic is also much faster to parse and resolve.

There are literally no disadvantages to using Sepples.

1.Much slower compile times
2.Multi-MB executables
3.Harder to debug
4.Name mangling and binary ABI changes make it hard to interface
5.Much more complex runtime
6.Tons of gotchas and hidden abstractions:you can't just "use the features you want" as by default you using all features you explicitly don't use. Templates are lurking everywhere.
7.ASM Code quality/speed suffers as optimizing OOP code is much harder than straight functions and imperative style.

>>19
1. try -O0 and clang or msvc instead of gcc
2. limit the use of templates and virtual functions and libraries that use them. don't limit usage thereof when you don't care about super small binary size (99% of cases).
3. computer nigger
4. extern C
5. it's only as complex as you make it fam
6. none of the core language features require templates. you're talking about the STL. again, you can choose to not use the STL. you can opt to use nothing but stdlib.h and whatever C libs you would have used instead. strawman.
7. doubtful. [citation needed]

>>20
So what advantage does it have over C, if the usable subset of C++ is basically the same as C?

no standard dubs library is a deal breaker for me

>>21
the ability to use any of hundreds of modern PL features without having to use half-assed, illegible, or handrolled substitutes. plus there are many things that have no conceivable implementation in C, like C++14 constexpr functions (which are 1/3x a Lithp macro and 3x a C preprocessor macro with all the GNU extensions turned on).

http://harmful.cat-v.org/software/c++/linus

>>21
If you want to use the other features like generic programming (with templates) you can do it. A feature I like is automatic deduction of variable types, it saves precious seconds for me in certain situations.

It's obvious that pretty much anything C++ can do, you can find some equivalent way in C - that is the nature of Turing-complete languages. Just because you're theoretically able to make it happen, it doesn't mean that the results are "aesthetically pleasing". This is the reason why modern high level languages provide all kinds of nice programming features right into its syntax (or standard library).

>>25

It's obvious that pretty much anything C++ can do, you can find some equivalent way in C - that is the nature of Turing-complete languages

Type deduction/auto can't be done in C at all. Syntax is independent of Turing completeness.

>>26
If a language is Turing complete, you can implement any other language in it. Which technically means every language is a subset of C (and Java, and Brainfuck, and Visual Basic, and so on).

>>27
Then the other language wouldn't be C.

Check em

>>26

Type deduction/auto can't be done in C

void.h\types.h\#L95
#define auto __auto_type //gcc extension

>>30
gcc extensions are not plain C

>>31 Plain C exists only as abstraction in the minds of C standard committee

>>32
but you shouldn't assume everyone is going to compile with gcc. especially not on /prog/ where almost every compiler thread is about how stupid gcc is

>>33
GCC is still better than MSVC.

>>33 The alternatives are
1.Clang(Apple-owned, Open-source, Depends on MSVC tools)
2.Intel C++(Intel-owned, proprietary, non-free)
3.MSVC(Microsoft-owned, proprietary, non-standard C89)

>>35
There's also Pelles C/LCC and TCC. Both are C only. I don't have much experience with the former, but it's said to support up to C11. The latter supports C99, compiles very fast, and produces very small binaries (2KB for Hello World, compared to 16KB in GCC and 32KB in MSVC) but at the expense of optimization, and has some bugs (e.g. generates faulty code for returning structs from functions) and is no longer under active development.

>>35
Clang does not depend in MSVC.

>>36
While we are on the topic, I doubt think MSVC gets much active development either. It exist to serve one propose, that being to build Windows. Occasionally, Microsoft occasionally decides to make a few updates to VC++ which can be used to compile C though.

>>37

Clang does not depend in MSVC.

http://stackoverflow.com/questions/14313439/why-does-clang-llvm-on-windows-require-visual-studios-link-exe
http://clang.llvm.org/docs/MSVCCompatibility.html