Which way is correct?

Which way is correct?

Other urls found in this thread:

en.wikipedia.org/wiki/Persistent_memory
twitter.com/SFWRedditVideos

bottom

second because
void *ptr1, *ptr2;

K&R told me void *ptr when i learned c, it's pretty much correct but void* ptr makes sense as well

void *ptr_a, this_is_not_a_ptr, *ptr_b;

would
void* ptr1, ptr2;
work the same way?

If you declare variables like that then you're a dick

If C wasn't shit this would be correct


void* ptr1, ptr2

No, that'd be equivalent to:
void* ptr1;
void ptr2;

The way i fuck your mom

They both work

>

First one in C#, second one in C++.

How often do you need to use pointers in C#?

>variable of void type

Whynotjustwritevoid*ptr;Whitespaceiscancer.

/thread

obviously the bottom. Only niggers would think otherwise

void*ptr;

is fine.

void * ptr;
void * ptr1, * ptr2;

void* ptr;
makes more sense because ptr is type void*

this

void *ptr;
makes more sense because *ptr is type void

this

it's the exact same fucking thing since the compiler will trim/ignore white spaces.

"""code"""
"""/code"""

Gotta save those 2KB of memory when writing programs.

Sadly bottom.
It's dumb.
>captcha:Calle calle
Now you're just playing with me..

this is aids

C fags will defend this.

>muh optimization

it doesn't save any memory

It takes one byte to store one character. A space character is still a character. If you put 100 spaces in your code, that's 100 bytes of memory wasted.

>calling it memory
You mean storage space.

god it's true
nobody on this board knows anything about technology

when code is compiled, it doesn't matter how much white space is in it

void *ptr;

compiles just the same as

void *ptr;

it makes no difference to the program

The second one is better since it allows multiple variables:

void *ptr;
void a, *b, c;

Also it's more logical:
"void" is the type (-> what to store).
"*" is an operator at the variable (how to grab the value? by resolving the adress).

#include

int main(void) {
short *a, b;

b = 12;
a = &b;
printf("%d \n", *a);

exit(0);
}

It's only for the sources though. The binary doesn't have them.

> compiled
I was talking about the code, i.e. uncompiled source. Can you read?

en.wikipedia.org/wiki/Persistent_memory

>void *ptr;
>compiles just the same as
>void *ptr;
>it makes no difference to the program


Learn something new every day!
Teach me your ways, senpai..

And performance, don't forget gcc compiles whitespace to no-ops.

>main {
>do nothing
>exit(0);}

>exit(0);

damage control activated

bottom you dumbfuck

I bet you also do premature optimization, don't you?

>hey, I need a quick benchmark, I'll use a simple programm for it.
>what, why don't I get EXIT_SUCCESS ?
>oh ok, some fuckwit thought it would be smart to not use a termination status

All of that is kind of sad to read...
First, size of source code files is less important than improvement of readability. Source code files are typically stored on hard disk drives, where storage is extremely cheap.
From translator's perspective, spaces are required for the single purpose: to separate lexemes or tokens. Some of them can be removed during preprocessing and all of them are removed during lexing.
Second, the only reason, why "void *p" is better, is because spacing here appropriately describes grammatical structure of the language. "*" belongs to the same grammatical part as the declared identifier belongs: it's called a declarator. "void" is called a type specifier. And we are looking at an example of a declaration consisting of a type specifier followed by a list of declarators. The main rule is that the declared identifier is used as in the full declarator in an expression, then it has the type of its type specifier.

I'm not the user who you're replying to, but that has nothing to do with premature optimisation.
Returning anything from main is the equivalent of calling exit(). Calling it explicitly here is completely pointless.
Also, exit is a function found in , but you have not included it.
In later C standards (C99 and later), if you reach the } in main, there is an implicit "return 0;", so you can leave it out entirely.

b=a+++++b;

a++ + ++b ?

A compiler will read that as "((a++)++) + b", which is invalid and fails to compile.

kekd

I actually prefer "void * ptr;"

just stick to haskell

f :: a -> Complicated Type
f = undefined -- Write tomorrow, typecheck today!
-- Arbitrarily complicated types
-- welcome!


ohhh fuck

>void* ptr makes sense as well
explain yourself

...

>but that has nothing to do with premature optimisation.

Right, and I didn't say that it has.
It's more like people who get assblasted about such details are usually the same kind of people who get optimization wrong.

>Returning anything from main is the equivalent of calling exit().

Right. It would be better to use return(0) here.

>Calling it explicitly here is completely pointless.

It's about programming habits.
I have no problem if people don't return anything, there's a lot of arguing about the "right style" in C. But to go full retard about something that isn't even the point of the post (it was about pointers, right?) it just stupid.

>exit is a function found in , but you have not included it

Blimey, you are actually right.. I used an online REPL where it's auto-included.

>code tags

get fucking good then come back

void* doesn't make sense, it implies that they type of all declared in the statement is a void pointer rather than 'the first variable declared is a void pointer.

i'd love to learn it desu but its easier to write shit in python and get paid for it

The only correct answer.

>"void" is the type (-> what to store).
Actually pointer is the type. You store a pointer, you can declare 1000 char pointers, but store no a single char in memory.
>"*" is an operator at the variable (how to grab the value? by resolving the adress)
Actually void is an operator specyfying the increment size of the pointer and what you get when you dereference it.

void* *ptr;
Because C pointer syntax is absolutely unreadable garbage.

>pointer to (pointer to void type)

in my opinion, if it weren't for that multiple variables declaration, it would be quite consistend with usage of "int* var", as "int*" is the type itself, and "var" is just the variable name of a given type, which makes no sense other way around, as something like "void *ptr" where is variable with a name "*ptr", which makes no sense, and type "void", which the variable obviously is not of this type. thus, logical version would be "void* ptr"

>a variable can be of type void

>Actually void is an operator specyfying the increment size of the pointer and what you get when you dereference it.
Keep in mind you can' perform pointer arithmetic on void pointers.

>>a variable can be of type void
void pointers are the one exception to that rule.
'void' in the context of a pointer means 'unspecified'. The type information is 'void'.
>*ptr is of unspecified type

Should i learn C or C++?

both

Definitely C.
C++ will only serve to taint you.

Learn C and expand on it with C++.

As someone who took the effort to learn C in depth, I can say that C++ is one of the most disgusting mainstream languages I have ever seen,
Languages like C force you to have some semblance of 'taste'.

The big problem with this nonsense is that * has two meanings. The first is for declaring a type (e.g. pointer to void) and the second is for dereferencing a pointer.
So void* ptr; would be preferable, since you aren't dereferencing anything and you don't want your code to look like you are. But then void* ptr1, ptr2; doesn't behave as expected. This stuff could have been designed a bit better.
Personally, I use void * ptr; and void * ptr1, * ptr2;

no big deal, it's retarded to begin with

void* ptr;

Obviously.

Because
void *ptr1, *ptr2;
is a travesty.

Right way to do it is
void* ptr1;
void* ptr2;

>t. never used any other "mainstream" language

I have. Another one I am particularly not fond of is Java, but that is for a fundamentally different reason.
C++ is just a kludge on a kludge on a kludge ad infinitum. It's a language that tried to do everything and doesn't do it well or elegantly. It's just a massive clusterfuck.

>I learned C therefore my opinion on C++ is valid

I've been programming C for the last 8 or so years, and C++ for the last 3. They are objectively different languages, C is for barebones shit and C++ (especially with modern variants such as C++11/14/17) is more similar to a modern high-level language than to C.

I program C when I have to, C++ is actually enjoyable.

That being said, Python is probably the most convenient for anything that doesn't require maximum speed or low level bitfiddling. I see the meme posted here on Sup Forums that it's only suitable for prototyping, but this is objectively wrong.

I strongly disagree, it's the closest you'll get to C without using C making it the second the most raw high-level language.

>>I learned C therefore my opinion on C++ is valid
Knowing C doesn't make my opinion invalid.
>They are objectively different languages
I completely agree. However, it's usually sepplesfags that try to act like it's a superset of C or some shit. I find it frustrating when people say "C/C++". That's about as helpful as saying "Java/Javascript".
They have both evolved in very different directions, and only retain trivial header-file compatibility, but even then, you still need to be careful.
>C++ is actually enjoyable
I find languages that were designed much better to be more enjoyable. I like writing for elegance, not just writing a bunch of shit.
Also, C++ sits in the weird "too high-level but too low-level" area of languages (I also think languages like Java are like this). If I wanted to write high level programs, I would certainly use a different language. If I wanted to write low level programs, I would certainly use a different language.

>However, it's usually sepplesfags that try to act like it's a superset of C or some shit.
Actually, it's not. It's more often C programmers that act that C++ is either "C with classes" or touting some bullshit about how bloated it is. Any good C++ programmer will stick to idiomatic C++, which is clearly extremely different from C in terms of type correctness, safe pointers, RAII, exceptions, templates etc. It's truly a high-level language, in contrast to C which is basically a portable assembly and slightly more comfortable to read.

>I find it frustrating when people say "C/C++". That's about as helpful as saying "Java/Javascript".
Agreed.

>They have both evolved in very different directions, and only retain trivial header-file compatibility, but even then, you still need to be careful.
Agreed.

>I find languages that were designed much better to be more enjoyable. I like writing for elegance, not just writing a bunch of shit.
Well, I happen to think that C++ is quite elegant, but then again, I come from a C background. I guess compared to other high-level languages, C++ is a bit pedantic and verbose.

>Also, C++ sits in the weird "too high-level but too low-level" area of languages
Well, the only thing I come to think of here is the fact that C++ also have undefined and implementation defined behaviour, because it compiles down to really low-level units, as compared to Java or C# that has a virtual machine or a bootstrapped runtime to rely on. I don't really think that's the main issue with C++, but I guess I can understand why people who expect a high-level language would get that impression (since UB isn't really something you'd expect in those). C++ has quite the amount of gotchas that requires you to be aware all the time, and this is quite challenging.

Personally, my biggest issue with C++ is the long time insistence on being compatible with C. Until C++11, this was the sole thing that really held C++ back from reaching its potential.

The existence of a subset of the C++ language that the C++ community calls "clean C", is extremely important for satisfaction of the original goals of the C++ language.
C++ has objectively bad design. If it was for compatibility with C language libraries and their header files, which dominate Unix world, then there is no reason to use this horrible language.

>The existence of a subset of the C++ language that the C++ community calls "clean C", is extremely important for satisfaction of the original goals of the C++ language.
I get that, but I mean that this original goal is flawed. It did contribute to its popularity and adoption though, but they should have moved away from C in the late 90s.

This for Christ sake.

Source compatibility with C isn't a requirement at all for a language to be able to be able to use header files.
C's ABI is so damn simple, that every single language that isn't complete garbage can interface with it.
Being able to use C header files is nice, but is it really necessary? Every other language gets around that, even if they have to write a little bit of glue code.

There is no good reason to try and write a program that can be compiled with both a conforming C and C++ compiler. All it does it severely limit what you can do, and adds all sorts of extra pitfalls where C and C++ have different semantics (there are more differences that most people realise).

Assuming you're also this guy: What's the value in learning C first if they're objectively different languages?

Learning C first will give you the perceptive to see how poorly designed C++ actually is.

>There is no good reason to try and write a program that can be compiled with both a conforming C and C++ compiler. All it does it severely limit what you can do, and adds all sorts of extra pitfalls where C and C++ have different semantics (there are more differences that most people realise).
Nobody is doing this, but being able to link together compiled C and compiled C++ is nice in many circumstances though.

Is it strictly necessary, maybe not. You could always do some wrapper stuff, like Python or Java to interface with C code. But it's convenient in many cases.

How is C++ poorly designed?

>Assuming you're also this guy:
He's not.

The correct way is not using pointers in order to avoid dangerous buffer overflows.

std::list x;

So the syntax is difficult? Are there any other poorly designed features?

>Nobody is doing this
I still think there are people who try to do this.
People who weirdly stick with C89, insist on casting void pointers and the like.
>being able to link together compiled C and compiled C++ is nice in many circumstances though
You don't need source compatibility to do this. It's all assembly at the end.
You can like a C code and Fortran code together if you wanted to, as long as you get the ABI correct.

Pointers are a fundamental tool in C. You could never write a non-trivial program without using them.

But since you linked my post, I might as well provide you my opinion on that.

>What's the value in learning C first if they're objectively different languages?
While I stand on my case claiming that they are different languages, I would say that knowing how C synthesises to machine code (something that is a must to claim that you "know" C) to a great extent makes it easier to learn how C++ synthesises as well.

I objectively think that all programmers aiming to work as software developers at some point should at least have made an effort to learn C (and rudimentary assembly), even if they hate everything about it. Simply because it gives you an impression on how modern languages have evolved since concepts from C have been adopted and extended in virtually all modern languages, and it also gives you an overview of how software works on lower levels, which is good for understanding certain programming constructs and why they are made in that way.

That's why it's a legacy shit language. Face it, even Pascal has evolved beyond pointers and allows you to write advanced programs, even system software, without even knowing about pointers' existence.

The only reason C is even relevant is because of the UNIX cancer. How bad of a language do you have to be to be technically inferior to fucking Pascal?

>So the syntax is difficult?
Yes. It's horrendous. The example that user posted is a very tame example.
>Are there any other poorly designed features?
C++ has so many god-damn features, that no mortal could possibly know all of it.
Of the ones I can think of, exceptions, iostreams, the type system, invisible references, classes (having to put private details in the public API), turing complete template system (this is not a good thing) and so on.

>You don't need source compatibility to do this. It's all assembly at the end.
It is, but as you mentioned, C ABI is nice. C++ is not. It's a lot easier to compile C using the same compiler in order to generate appropriate symbols.

Calling C from C++ is trivial. Calling C++ from C is not and, just like calling Python from C, requires a lot of glue.

>Pascal
Are you fucking kidding me?
Go to bed, granddad.

typedef void* voidptr_t;
voidptr_t ptr1, ptr2;

This is the only correct way.

_t is for POSIX types only, you fool

>someone missed the point

Doesn't C++ just fix that shit with 'extern "C" { }' or whatever?
You don't need to mix C and C++ in the same source file. Interface using the header files.

But what if I want to use an int pointer?
'intptr_t' is taken.

Whatever, you get the point. Typedef the pointer to something else.

no.