C or C++? Why?

C++ because it's a better C

C because it's a better C++

>>59782641
C because

C++ > C == false

>>59782641
C++ because std::thread

>>59782641
C because I'm a masochist and like making everything I need on my own

>>59782967
But that shows C++ as being greater than C

>>59782641
C when you have to.

C++ when you don't have to use C.

>>59783063
>"look everyone I can read"
>can't read

>>59782982
C have it also.
#include <threads.h>
it even have pthreads and OMP.

File: 1491039295086.gif (458KB, 256x256px) Image search: [Google]

458KB, 256x256px

>>59782967
>>59783063
>>59783090
Isnt that an condition? If c++ is better than c? So c++ has to be better before its worse?

>>59783115
>C11 threads
No compiler implements it, because its semantics conflicts with POSIX threads.

>pthreads and OMP
Non-standard and therefore non-portable

>>59783063
It's post-fix incremented

>>59783140
Mostly becouse there is no need ( threads is castrated pthreads)
OMP still much more efficient compared to any multithreading implementation.

>>59783119

C++ > C == false

This says "the truth value of the claim that C++ is greater than C is equal to false."
Or, in simpler terms, "C++ is not greater than C."

>>59783140

pthreads implemented everywhere.

>>59783160
>Mostly becouse there is no need ( threads is castrated pthreads)
C++11 threads are portable between Linux and Windows, that's a major feat.

>OMP still much more efficient compared to any multithreading implementation.
OpenMP is just compiler directives, and surprise surprise it uses pthreads under the hood. It's not any more or any less efficient than manually using POSIX threads.

>>59783181
>pthreads implemented everywhere.
Not on Windows.

>>59783164
I though == is checking whether something is true or false. Is that a C thing or is it common among other languages?

>>59783183
It detects on the fly how much threads are needed, manually you can do it, but with significant overhead.

If you have to ask, C++. I use C++.

>>59783195
>It detects on the fly how much threads are needed,
Not on the fly, at compile time. Which isn't always what you want.

>manually you can do it, but with significant overhead.
There is no overhead, it uses the exact same pthreads implementation.

>>59783189
No, == tests equality.

x == y

This is true if x equals y, and false otherwise. This is a common convention among many imperative languages.

C++ > C == false

This is true if C++ > C equals false, and false otherwise.

C++ > C equals false if and only if C++ is not greater than C.

>>59783115
It looks far worse than std::thread. Here is C++ equivalent of code from here https://en.wikipedia.org/wiki/POSIX_Threads:

#include <thread>
#include <cstdio>

#define NUM_THREADS 5

void perform_work(int arg)
{
    printf("Hello World! It's me, thread with argument %d!\n",arg);
}

int main(int argc, char *argv[])
{
    std::thread t[NUM_THREADS];
    for(int i = 0;i < NUM_THREADS;++i)
    {
        printf("In main: creating thread %d\n",i);
        t[i] = std::thread(perform_work,i);
    }
    for(int i = 0;i < NUM_THREADS;++i)
    {
        printf("In main: thread %d has completed\n",i);
        t[i].join();
    }
    return 0;
}

>>59783247
You don't actually need to call join manually either, joint is implicit (unless you specify that they are detached).

C++ is an abortion over perfect C. If anything Objective-C is a better object extension (and that says a lot). Though they all are ancient.

>>59783238
Makes sense

>>59782967
isn't C++ > C supposed to be undefined?

>>59783320
It is.

>>59783281
>Though they all are ancient.
This shows how out-of-date your opinion about C++ is.

>>59783320
C++ > C wouldn't be undefined unless C is undefined. If C is defined, then C++ > C would be true in all cases except the case where C equals INT_MAX, UINT_MAX, LONG_MAX, ULONG_MAX, SHRT_MAX, USHRT_MAX, CHAR_MAX, or UCHAR_MAX, depending on what data type C is. In that single edge case, C++ > C would be false.

>>59783354

C++ > C

is undefined you fucking moron.

https://en.wikipedia.org/wiki/Sequence_point#Sequence_points_in_C_and_C.2B.2B

>>59783364
no it true

File: 1483793067002.png (97KB, 508x600px) Image search: [Google]

97KB, 508x600px

I always use namespace std and there is nothing you can do about it.

>>59782641
both.
More knowledge is better.

>>59783384
>vomiting profusely

File: Screen Shot 2017-04-07 at 19.09.38.png (317KB, 2514x1652px) Image search: [Google]

317KB, 2514x1652px

>>59783372
It's undefined.

>>59783070
this.
OO make coding easier, in most cases cpp is just better.
C ist faster and need less resources so its used in embedded system and make great job here.

>>59783396
waht compilber u youse
it true

>>59783408
It's undefined behaviour.

>>59783405
Even if you don't use OOP, I'd argue that STL containers and RAII features such as safe pointers and lock_guard alone are reasons to use C++ over C.

However, you obviously need to use C for writing LKMs or embedded stuff. Use C when you have to and C++ when you don't.

>>59783422
no it are an true
c++ olny compoot sum, of c & 1
it desont bchange valeu of c

>>59783422
anyone in this world use cpp without oo??

>>59783449
i've been tempted to sometimes
the "c with templates" family of design patterns is useful sometimes

>>59783449
If I can do with already existing types, I never implement my own classes just for the sake of doing it object oriented.

>>59783435
You are undefined
Its true

>>59783372
>>59783408
>>59783435
Are you typing weird because there's a demon flying out your nose? Because that's what happens when you use undefined behaviour.

>>59782641
Depends on the project.
E.g., C for OS development. But I don't think it's feasible to write games, GUI, etc., with C instead of C++.

>>59783449
Yeah, some people use it just for the STL.

Unless you're working on embedded systems there's no reason to use C ever.

>>59783551
Or working on the most popular kernel in the world

>>59783563
Was just going to post this.

>>59783551
Plenty of FOSS projects are C only, like ffmpeg or Open/LibreSSL.

>>59782641
C is honestly better in my opinion due to the quadratic algorithms being more capable of pushing boolean codes efficiently. C has a more soild internal structure and a more viable anagram frame than most other programing software. The boolean codes synch up 100x faster than C++ and guarantees a not so cluttered coding experience given the optimal setting

>>59783589
>pushing boolean codes efficiently
The irony here being that C++ booleans are bitfields, whereas in C they are ints.

>>59783600
The difference between bitfields and ints really isn't that wide of a gap considering bitfields hold compressed vector brackets and ints are kernel based. They both hold the same amount of packet data and syntax exchange. I fail to see your point.

>>59783482
No, I noticed I was wrong and decided to turn into a parody of my own carelessness.

>>59783354
>>59783364
>>59783372
It's undefined behavior, but it's also false.

It's undefined whether the expression (C++) will be evaluated before the expression (C). But it's false because C++ is a post increment, so it evaluates to C before incrementing C.

So let's say C=0, if (C++) is evaluated before (C) then it will execute like this: First (C++) will evaluate to 0 and then increment C. So the expression will become 0>1 which will evaluate to false.

But if (C) evaluates before (C++), then first (C) will evaluate to 0, then (C++) will evaluate to 0, then (++) will increment C. So the expression will become 0>0 which will also evaluate to false.

Under no situation does C++ > C evaluate to true.

>>59783839
You are a legit dumbass

>>59783839
but what if it invoke nasle demuns

& HTE DEMUSN MAKE U SNEEZE OUT AN TRUE

File: 1465547979583.jpg (174KB, 640x640px) Image search: [Google]

174KB, 640x640px

>>59783589

>>59783864
Not an argument.

File: 1490742249644.jpg (93KB, 1280x720px) Image search: [Google]

93KB, 1280x720px

>>59783970
>posts nonsensical equations hoping nobody will be smart enough to call bullshit on
There is no argument to be had from that shit you smothered in that post. Please remember that stupidity is a privilege, stop abusing it.

>>59784094
Everything I posted is true. Maybe you could explain what you're having trouble understanding.

>>59782967

C > C++ == false

Checkmate

>if (C) evaluates before (C++), then first (C) will evaluate to 0, then (C++) will evaluate to 0, then (++) will increment C. So the expression will become 0>0 which will also evaluate to false.
>Under no situation does C++ > C evaluate to true.
C is treated as an unknown tangent in this equation because it equates to 0 until (C++) is confirmed to evaluate to OR from 0 which would change C to a random coefficient corresponding with the new variable. At no point can C ever evaluate without (C++) being altered first which is why C isn't even be factored in until (C++) has been established.

>>59783354
>>59783839
Undefined behaviour is more undefined than you think. These analyses are probably right in some other cases, but here, absolutely anything could happen.

Say you have this program:

#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv)
{
    int C = atoi(argv[1]);
    printf("%d\n", C++ > C);
    return 0;
}

All of the following are valid behaviours:

$ ./a.out
0
$ ./a.out
1
$ ./a.out
$ ./a.out
2
$ ./a.out
Check your nostrils for demons
$ ./a.out
Formatting hard disk, chomp chomp
$

Any undefined behaviour makes the whole program undefined, so don't bother reasoning about what might happen because anything could happen.

>>59784368
I forgot about the

argv[1]

, just pretend the program is run as

./a.out 30

each time.

>>59783188
>wincuck

>>59784368
What's the anagram program you're using for this?

>>59784422
>The program is perfectly portable, so long as you only run it on non-shitty systems!

>>59784368
This code always returns 0 for me, no matter what I pass as an argument. Compiled with gcc 6.3.1.

>>59784277
You're retarded.

>unicode era
>still using chars

This shit needs to stop.

>>59784277
what did he mean by this

so what are some basic things I should really be avoiding on C++
what about C

>>59783325
It's not.

>>59784591
using namespace std

>>59784611
what exactly is wrong with namespace std aside from the name having STDs in it

File: 1489449973150.jpg (81KB, 1280x720px) Image search: [Google]

81KB, 1280x720px

>>59784277

>>59784618
I meant that you shouldn't ever use

using namespace std;

in your code.

>>59784641
but why

>>59784661
Because you don't know what shit it will bring to global namespace. If you're making a library, this will also include all the shit from std to any project that will use your library.

>>59782967
lang1 = c++;
lang2 = c;
lang2 > lang1 // true

>>59784155
>Under no situation does C++ > C evaluate to true.

You completely fail to understand what undefined behaviour is.

Undefined behaviour means that your compiler might open up Emacs and run nethack or a Tower of Hanoii simulation rather than compiling code.

It may actually be true, false and some state in between for all you know. That's the problem with undefined behaviour, you can make absolutely no guarantees on the behaviour.

>>59784391
It's just another example of undefined behaviour.

>>59784466
The point is that undefined behaviour means that whatever might happen.

>>59784600
It is. See >>59783396

>>59784766
>a language where this needs to be discussed is supposed to be good

>>59784489
7 bits ought to be enough for anyone.

>>59784618
It causes namespace pollution by importing the entirety of the std namespace into the translation unit, which means you're at risk for name collisions with the standard library, even for identifiers you're not actually using.

>>59784784
C isn't a good language (which is why I made this post: >>59783070). C is a portable assembly language. You should only use C when it makes sense to use C.

Although technically, it shouldn't need to be discussed. Only people who are new to C are new to the concept of undefined behaviour. Any self-respecting C programmer should have at least skimmed through the standard a couple of times.

>>59784766
>It's just another example of undefined behaviour.
Dereferencing the null pointer argv[argc]? True, it's just less interesting than the postincrement in a comparison.

>>59784466
>Somebody once told me that in basketball you can’t hold the ball and run. I got a basketball and tried it and it worked just fine. He obviously didn’t understand basketball.

I guess most of my knowledge of undefined behaviour comes from http://blog.regehr.org/archives/213

>>59784943
Is argv[argc] always NULL ?

>>59784829
C++ has all the same undefined behaviours as C, doesn't it? It just also has more ways to avoid them.

>>59784971
>C++ has all the same undefined behaviours as C, doesn't it?
Yes.

>It just also has more ways to avoid them.
Exactly. Using safety semantics available in C++ is usually considered idiomatic, and "C with classes" is generally frowned upon.

>>59784969
Yes
http://stackoverflow.com/questions/16418932/is-argvargc-equal-to-null-pointer
(The question makes a small mistake by saying \0. The first argc elements of argv are pointers to '\0'-terminated strings, and the next one, argv[argc], is a NULL pointer.)

>>59783222
Not at compile time, you nigger!
At run time!
You can change number of threads with environment variable.

>>59785077
Still isn't remotely as flexible as just using pthreads.

>>59783188
It's implemented on windows.

>>59784716
This has a sequence point so you're right

>>59784716
>>59785093
Unless c was INT_MAX, I guess, in which case it's still undefined behaviour.

>>59785084
Using pthreads you constantly create and delete threads, it's huge overhead. OpenMP automatically does all dirty work, not deletes threads, don't creates more than necessary.

>>59785086
POSIX threads are non-standard and therefore not portable. C++11 threads are standard.

>>59785118
C11 thread are standard.

>>59785118
POSIX is a standard.

>>59785114
>Using pthreads you constantly create and delete threads
No, you don't. You create a pool of workers just like OpenMP does under the hood.

>it's huge overhead
OpenMP fucking uses POSIX threads under the hood for fuck's sake.

>OpenMP automatically does all dirty work, not deletes threads, don't creates more than necessary.
It's an abstraction that removes the threading semantics. It makes it easier for the programmer but also less flexible.

Just because you're namefagging now, doesn't mean that I can't tell that you are the samefag from before.

>>59785133
Name one C11 compiler that implements C11 threads.

>>59785137
It's not part of the C standard. You can be fully C compliant and not implement anything POSIX.

>>59785114
>spawning a thread is a huge overhead
Not that guy, but it actually isn't. Creating a thread in detached mode is actually negligible in terms of performance.

>>59785163
Non-POSIX platforms are either microcontrollers, where you don't need threads or are irrelevant.

>>59785163
clang, intel c compiler.

>>59785184
For simple task overhead so big that using single thread is faster.

>>59782641
C, because complexity is created by the author not the language.

File: Screen Shot 2017-04-07 at 21.55.28.png (250KB, 2514x1652px) Image search: [Google]

250KB, 2514x1652px

>>59785193
>you don't need threads on embedded environments
Opinion disregarded.

>>59785194
clang does not implement C11 threads.

>>59785233
On more powerful embedded systems you have linux, which has pthreads.

>>59785233
Shouldn't you be including pthread.h?

>>59785262
Or you may have VxWorks, which does not have pthreads. It's really not an argument at all. POSIX threads aren't part of the C standard. Neither is OpenMP.

File: Screen Shot 2017-04-07 at 22.01.35.png (208KB, 2038x550px) Image search: [Google]

208KB, 2038x550px

>>59785283
Not when I want to use C11 threads.

>>59785284
VxWorks does have pthreads.

>>59785303
Only when you throw hard realtime out the window and enable it in the kernel configuration.

>>59785233
did you specify -lthreads to clang?
It's actually not implemented in glibc, but implemented in musl.

File: Screen Shot 2017-04-07 at 22.08.14.png (309KB, 2514x1652px) Image search: [Google]

309KB, 2514x1652px

>>59785350

>>59785373
Use musl.

>>59785419
Not supported on macOS, so no. Also, your claim is disproven.

I only really like C++ for std::vector and templates.
But in C I can just write something ala

int array_max = 100;
int *array = calloc(array_max, sizeof(int));
size_t array_size = 10;
void push_int(int value) {
    if(array_size+1 > array_max) {
        array = realloc(array, (array_max*=2)*sizeof(int));
    }
    array[array_size++]= value;
}

and as far as templates go, I don't use generic types enough to warrant them (data-oriented design For Life; typing is important). And if I need some variety of polymorphic lists of whatever kind I'll use a void pointer or (more safely) a union type (or even a tagged union).

I really don't like C++ for OOP. I don't think OOP is good on its own. I prefer data-oriented programming and modular programming in different use cases. C fully supports encapsulation and file-level modularity, so OOP really draws no benefits.

File: Screen Shot 2017-04-07 at 22.46.17.png (323KB, 2514x1652px) Image search: [Google]

323KB, 2514x1652px

>>59785114
>>59785208
You're wrong actually:

#ifdef USE_OPENMP
#include <omp.h>
#endif
#include <stddef.h>
#ifdef USE_PTHREADS
#include <pthread.h>
#endif
#include <string.h>
#include <stdio.h>

#define SIZE    (1ULL << 25)
#define THREADS 32

unsigned char memory[SIZE];

#ifdef USE_PTHREADS
pthread_barrier_t barrier;

void* set_zero(unsigned char* start)
{
    unsigned i = (start - memory) / (SIZE / THREADS);
    unsigned char* end = memory + (i + 1) * (SIZE / THREADS);

    while (start < end)
    {
        *start++ = 1;
    }

    pthread_barrier_wait(&barrier);
    return NULL;
}
#endif

int main()
{
    unsigned i;

#if defined(USE_OPENMP)
    omp_set_num_threads(THREADS);

#pragma omp parallel
    for (i = 0; i < SIZE; ++i)
    {
        memory[i] = 1;
    }

#elif defined(USE_PTHREADS)

    pthread_t thread[THREADS - 1];
    pthread_attr_t attr;

    pthread_attr_init(&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

    pthread_barrier_init(&barrier, NULL, THREADS);

    for (i = 0; i < THREADS - 1; ++i)
    {
        pthread_create(&thread[i], &attr, (void* (*)(void*)) set_zero, memory + i * (SIZE / THREADS));
    }

    for (i = i * (SIZE / THREADS); i < SIZE; ++i)
    {
        memory[i] = 1;
    }
    pthread_barrier_wait(&barrier);

    pthread_barrier_destroy(&barrier);

#else

    // Note: memset would be faster
    for (i = 0; i < SIZE; ++i)
    {
        memory[i] = 1;
    }

#endif
    return 0;
}

This clearly illustrates that OpenMP has a significant start up overhead, while detached pthreads do not.

>>59785821
It also shows that even for a "trivial task", starting 31 additional threads is still slightly faster than linear write in a single thread.

File: puke-tan.jpg (53KB, 386x460px) Image search: [Google]

53KB, 386x460px

>>59785821
That's some terrible code. Who in their right mind would prefer the pthread clusterfuck over the nice and clean OMP?

>>59786034
Shifting the goalpost now, are we?

>>59785041
Usually the null pointer and \0 are the same datum though, just interpreted differently

>>59782967
that's a malformed statement, missing || or &&?
perhaps you meant = not comparative ==?

>>59786144
>that's a malformed statement, missing || or &&?
It's not malformed. It's undefined behavior, but it compiles.
>perhaps you meant = not comparative ==?
That would be even worse.

File: nice-move.webm (2MB, 720x1280px) Image search: [Google]

2MB, 720x1280px

>>59785821
Noice

>>59785163
gcc ≥ 4.9

>>59786508
https://gcc.gnu.org/wiki/C11Status

>Library issue
>not implemented in glibc

>>59786434
Niiiice

>>59782641
C < Forth

brainlets can't handle good languages though

also c is used on unix for historical purposes and there's no stopping it now

>>59782641
C++ is just like C only it's two extra.

>>59783013
underrated post

>>59787175
It's one extra
C++ is the same as C = C + 1

>>59782641
C++ because templates and class methods

>>59782967
>Knows basics of programming
>fucks up conditional

c++ have boost library, c not hahaha

>>59782641
So, at risk of starting another circle-jerk war, how do they both compare to C#?

>>59785163

Pelles C