Java is not C

Thats about it, no freedom... No power, no flexibility.

LOL nobody cares about your moldy languages, grampa. Rust is better and faster and stronger than C and Java COMBINED.

go back to /g/ faggot, go back sucking dicks

No shit Rust is faster than Java and C combined. EVERYTHING is faster than anything combined with Java, even PHP.

So LibGDX is out of the question, then, huh.

...

Heh. They didn't create C# aka MS Java for nothing.

On the contrary. Abstracting away low-level details grants you a lot of power and flexibility. It's just at a different level.
The cases where C's low-level features really shine aren't cases where you're supposed to use Java.
Say it with me, "Java and C cover different sets of use cases."

I don't even like Java, but your criticism is dumb.

The main reason to use Java is you can sandbox Pajeets and limit the scope of the damage they can do. That lets you pay people peanuts and throw a hundred "programmers" at a task one good programmer would have done. It's the language of outsourcing.

Thanks, we know. I'd still like something template-like in C, instead of doing some macro witchcraft.

200% retarded, reducing granularity CAN'T give you more possibilities i.e. "power and flexibility". All it does is save time (time to search and compare algorithms and time to implement); developement time, not execution time.

There's very little that you can't do in a typical Turing-complete language given enough time and autism. I think that easing development is absolutely a form of power.

Pretty much this. Java dev reporting in.

Java 8 has a lot of cool functional improvements.

I use java for GUI intensive programs and that's about it.

You idiots can all go fuck yourselves. I'm writing my own language.

You can do anything, but you can't choose how, thus getting hit by the abstraction cost when you don't need to.
Basically, Java is Playmobil or Action Man while C is Lego or Mecano.

If you like c but wants some high level abstractions jus use c++. Zero or almost no overhead and you can use it as plane c if you want.

As a C dev who recently started dicking around Arduino without previous C++ knowledge: No. Writing C++ as if it were C has a lot of corner cases. Want to use "pointer++" as a shorthand for "pointer += sizeof(*pointer)"? Well, you can't. Arrays declared as array[] are some special weird C++ type and you can't treat them as pointers either. The second you touch a C++ library and you're still writing it as if it were C you know you've fucked up.

In the end, your code ends up being a mess, things behave very differently, and you can't get shit done. Please, write C++ as C++, not C.

Fuck, that should've been: pointer = (typeof(pointer))((uintptr_t)pointer + (uintptr_t)sizeof(*pointer))
But you get the idea.

Sure, c++ has a slight differences like that, another example is that in c++ func (void) takes no arguments where in c it can take any amount of arguments (iirc). What I meant by saying you can use c++ like c is that you can use the c library. Fopen, printf etc. You don't have to use the niggerlicious cout

And btw your example pointer++ works for me in g++ I use it myself

Shameful.

What?

Mixing C++ with C calls is a practice maintained only by the inner circles of the highest order of sodomite niggers. C++ granted you cout, yet you cast it away like a primitive fool and resort back to "MUH C" because the overloaded shift operator boggles the primitive mind.

A turd with 8 kernels of corn in it is, in the end, still a turd.

The turd is large, solid, easier to pass, healthy, and doesn't burn on the way out. Which is more than C niggers can say.

I just want c with classes fuck off

No one is impressed

...

No one but amateurs use C++ streams in the real world. Go look at the source of a large project, that shit's been forbidden for decades because of how hopelessly awful the design is. They will bloat your code and slow your compiles faster than just about any other feature in C++, and they're impossible to internationalize and run slow.
Most large projects wind up using ICU's C++ bindings.

std::endl calls std::flush which makes it 9x times slower than simple \n. Too bad people are not being thought
that.

Top wew my friend. And you tell me that I'm supposed to use cout. It's a class you know ? Make up your mind.

C++ classes are equally as efficient and structures and functions that tale a pointer to the struct as the first argument. They compile to the same code. Virtual functions are also as efficient as you would do it yourself (each object has a pointer to it's function) I like those features because I know exactly to what assembly code it will be compiled. I learned c++ a bit backwards. I knew some c and I started reverse engineering a mmo server executable. It was built in debug with symbols, so it wasn't that hard, but it made me learn assembly and appreciate the low level coding. It also showed me how for example the virtual functions are handled (vtables).

If you think pointer arithmetic is a good feature then you are a fool.

Can you name it the 'Fuck you' language or the 'go fuck yourself' language.
It might meme it into life.

C++ classes are not as efficient due to it not being possible to portably pass 'this' directly as the first argument to a member function pointer for some autistic historical reason. This means that the pattern of passing callback + void * can't directly call a C++ class member. So people that are trying to stick to OOP get around this using functors, and functors require an extra load and jump. Scrub.

I'm using gcc mingw and it works as I said.

I'm not sure if I understand what you said correctly, but this code
#include class Cstuff{public: int var1; int var2; int var3; Cstuff(int v1, int v2, int v3) { var1 = v1; var2 = v2; var3 = v3; } int addVars() { return var1 + var2 + var3; }};struct Sstuff{ int var1; int var2; int var3;};int stuff__addVars(Sstuff* ptr){ return ptr->var1 + ptr->var2 + ptr->var3;}void stuff__constructor(Sstuff* ptr, int v1, int v2, int v3){ ptr->var1 = v1; ptr->var2 = v2; ptr->var3 = v3;}int main(){ Cstuff cstuff(1,2,3); Sstuff sstuff; stuff__constructor(&sstuff, 1, 2, 3); printf("%d\n", cstuff.addVars()); printf("%d\n", stuff__addVars(&sstuff)); return 0;}

Compiles to this
.text:080484A5 lea ecx, [esp+arg_0].text:080484A9 and esp, 0FFFFFFF0h.text:080484AC push dword ptr [ecx-4].text:080484AF push ebp.text:080484B0 mov ebp, esp.text:080484B2 push ecx.text:080484B3 sub esp, 24h.text:080484B6 mov eax, large gs:14h.text:080484BC mov [ebp-0Ch], eax.text:080484BF xor eax, eax.text:080484C1 push 3.text:080484C3 push 2.text:080484C5 push 1.text:080484C7 lea eax, [ebp-24h].text:080484CA push eax.text:080484CB call _ZN6CstuffC2Eiii ; Cstuff::Cstuff(int,int,int).text:080484D0 add esp, 10h.text:080484D3 push 3.text:080484D5 push 2.text:080484D7 push 1.text:080484D9 lea eax, [ebp-18h].text:080484DC push eax.text:080484DD call _Z18stuff__constructorP6Sstuffiii ; stuff__constructor(Sstuff *,int,int,int).text:080484E2 add esp, 10h.text:080484E5 sub esp, 0Ch.text:080484E8 lea eax, [ebp-24h].text:080484EB push eax.text:080484EC call _ZN6Cstuff7addVarsEv ; Cstuff::addVars(void).text:080484F1 add esp, 10h.text:080484F4 sub esp, 8.text:080484F7 push eax.text:080484F8 push offset format ; "%d\n".text:080484FD call _printf.text:08048502 add esp, 10h.text:08048505 sub esp, 0Ch.text:08048508 lea eax, [ebp-18h].text:0804850B push eax.text:0804850C call _Z14stuff__addVarsP6Sstuff ; stuff__addVars(Sstuff *).text:08048511 add esp, 10h.text:08048514 sub esp, 8.text:08048517 push eax.text:08048518 push offset format ; "%d\n".text:0804851D call _printf.text:08048522 add esp, 10h.text:08048525 mov eax, 0.text:0804852A mov edx, [ebp-0Ch].text:0804852D xor edx, large gs:14h.text:08048534 jz short loc_804853B.text:08048536 call ___stack_chk_fail.text:0804853B ; ---------------------------------------------------------------------------.text:0804853B.text:0804853B loc_804853B: ; CODE XREF: main+8Fj.text:0804853B mov ecx, [ebp-4].text:0804853E leave.text:0804853F lea esp, [ecx-4].text:08048542 retn.text:08048542 main endp
and as you can see it's exactly the same procedure.

...

Something not originally created by Microsoft, with (if I remember correctly) a Windows 10 edition that's not written in Java

holy shit why do you indent brackets like a faggot?
you're what's wrong with the world. follow the standards everyone else does.

lol, i'm pretty sure you're the faggot here

You were wrong both times before, now you're just shit flinging. I mean, it's Holla Forums so I shouldn't be surprised.

If you don't put your braces on a newline you're cancer. K&R style is for fucking plebs. With Allman style bracket placement you can actually tell where your constructs begin and end.

...

...

Damn straight. Braces on the same line are only used by hipsters and Javascript, streetshiting coders.

Huh? Explain.

What in good fuck are you talking about? Arrays are not pointers, this is true in C as well.

So can I with braces on the same line. I just look for the line that's shifted to the left.

Explained here:
Debunked here:
I haven't touched C++ enough and it didn't work for me the first time I tried doing it. Basically pointer += 1 should increment the actual pointer by sizeof(typeof(*pointer)) * 1.

C has no actual array type. If you compare:
char string[] = {'a', 'b', 'c', '\0'};char *string = "abc";
In C, in both cases you're defining a pointer to an array. The only difference lies in that sizeof returns the actual size of the array for the first example, and in the second it returns the size of the pointer type.
In C++, the first example actually gives you some kind of array type, which you can't really treat like a pointer. If you want to loop through it with something like this:
for (char *x = string; x < string + sizeof(string); x++)
Well, you can't. This is perfectly valid C.

#include int main(int argc,char *argv[]){ char string[] = {'a', 'b', 'c', '\0'};#ifdef __cplusplus printf("C++: ");#else printf("C: ");#endif for (char *x = string; x < string + sizeof(string); x++) { putchar(*x); } putchar('\n');}~ $ gcc test.c -Wall~ $ ./a.out C: abc~ $ gcc -x c++ test.c -Wall~ $ ./a.out C++: abc

I await your response.

This is what I expected, I don't know what this guy is talking about

I'd like to see some actually differences between c and c++ . One that I know of (and already mentioned in this thread) is that a function (void) in c++ doesn't take any arguments (same as function () ) but in C it can take any argument.. I didn't test it, only read about it once upon a time. I'm not on computer right now, someone might want to test it.

A fantastic game that runs like ass because its written in Java.

Just remember, kids... adding training wheels to your bike really adds a lot of speed, power and flexibility. :^)

void function(void) in both C and C++ takes no arguments. void function() in C takes any number of arguments, and in C++ takes no arguments. Tested in GCC 6.3.0 with compile command gcc ./c_function_test.c -o ./c_function_test -std=c89 -Wall with std=c89, c99, and c11. I'm sure there's a warning flag that'll warn about it.

#include void function(void){ printf("Hello\n");}int main(int argc, char **argv){ function(1,2,3); return 0;}


C arrays are arrays and not pointers. They decay to pointers in situations where it kind of makes sense such as passing an array into a function, but they're not the same thing. This is why the output of the following is different.

#include int main(int argc, char **argv){ char a[] = "abcdefghijklmno"; char *b = "abcdefghijklmno"; printf("Sizeof a: %d\n", sizeof(a)); printf("Sizeof b: %d\n", sizeof(b)); return 0;}

Further, defining a pointer to a string constant puts the string constant into constant memory and will most likely cause a segfault should you try to modify it. The same is not true for the array because its memory is in local scope.

So I had it backwards.

I have so many I told you sos for so many people.

This

First. You are right arrays and pointers do not have equal properties in the C language. However...

Funny thing is if you do "gcc -S" and look at the assembly of your example, there is only one string literal.

This is what it says in c89 about sizeof array
When applied to a parameter declared to have array or functiontype, the sizeof operator yields the size of the pointer obtained byconverting as in $3.2.2.1; see $3.7.1.
So even in the standard, they say that an array is a pointer with a size and even initializing your array with a string literal is assuming that an array and a char pointer is the same. Otherwise you would have initialized it a[] = { 'a', 'b' .. }.

An array is an aggregate type and has the [] operator which does the same as you do when you would find the position in "contiguously allocated set of element types"...

and an addition to your example could be to return a character from b using the array operator [].
printf("%c\n", b[0]);

Arrays and pointers are not the same, but arrays are a solution to adressing continguously allocated memory.

..and here you are confusing the terms string literal and a const type.

...

...

No. Read the excerpt you posted:
Notice the word "parameter". There are special rules for parameters of array type, which is what this clause is defining.

No. The standard itself states that string literals are of array type. The string literal's value will decay into a pointer to the first character, however decay does not occur when used in the initialization of a variable with array type. This is one of the three cases where decay does not occur, the other two being when used with the unary & operator and when used with the sizeof operator.

In the C89 draft I have found online, this is defined in $3.2.2.1 (this is also referenced in your excerpt).
> Except when it is the operand of the sizeof operator or the unary & operator, or is a character string literal used to initialize an array of character type, or is a wide string literal used to initialize an array with element type compatible with wchar_t, an lvalue that has type ``array of type is converted to an expression that has type ``pointer to type that points to the initial member of the array object and is not an lvalue.

What you are calling the "array operator" in your post also applies to pointers. In fact, it only applies to pointers. Array values decay to pointer values when used with [] which is how the [] operator sees usages with arrays.

Hi Makise, long time no namefag.

The stupidity of some of the (anti)fanboys here is really reaching critical mass.

Mind blowing! One programming language is not another programming language!

Well, apparently to OP it is. He thought that Java was just a different name for C all along. Now it turns out it's actually a different programming language... Breaking news!

You are absolutely right.

Thanks for making me read the c89 standard. I learned something :)