C or C++?

C or C++?

Why?

Other urls found in this thread:

en.wikipedia.org/wiki/POSIX_Threads:
en.wikipedia.org/wiki/Sequence_point#Sequence_points_in_C_and_C.2B.2B
blog.regehr.org/archives/213
stackoverflow.com/questions/16418932/is-argvargc-equal-to-null-pointer
twitter.com/NSFWRedditImage

C++ because it's a better C

C because it's a better C++

C because
C++ > C == false

C++ because std::thread

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

But that shows C++ as being greater than C

C when you have to.

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

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

C have it also.
#include
it even have pthreads and OMP.

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

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

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

It's post-fix incremented

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

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."

pthreads implemented everywhere.

>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.

>pthreads implemented everywhere.
Not on Windows.

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

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++.

>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.

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.

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

#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;
}

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.

Makes sense

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

It is.

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

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.

C++ > C is undefined you fucking moron.

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

no it true

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

both.
More knowledge is better.

>vomiting profusely

It's undefined.

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.

waht compilber u youse
it true

It's undefined behaviour.

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.

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

anyone in this world use cpp without oo??

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

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

You are undefined
Its true

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

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++.

Yeah, some people use it just for the STL.

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

Or working on the most popular kernel in the world

Was just going to post this.

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

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

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

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.

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

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.

You are a legit dumbass

but what if it invoke nasle demuns

& HTE DEMUSN MAKE U SNEEZE OUT AN TRUE

...

Not an argument.

>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.

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

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.

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
#include
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.

I forgot about the argv[1], just pretend the program is run as ./a.out 30 each time.

>wincuck

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

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

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

You're retarded.

>unicode era
>still using chars

This shit needs to stop.

what did he mean by this

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

It's not.

using namespace std

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

...

I meant that you shouldn't ever use using namespace std; in your code.

but why

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.

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

>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.

It's just another example of undefined behaviour.

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

It is. See

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

7 bits ought to be enough for anyone.

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.

C isn't a good language (which is why I made this post: ). 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.

>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.

>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 blog.regehr.org/archives/213

Is argv[argc] always NULL ?

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

>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.

Yes
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.)

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

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

It's implemented on windows.

This has a sequence point so you're right

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

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.

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

C11 thread are standard.

POSIX is a standard.