How do you use malloc ? 1: int *variable = malloc(sizeof(int)

>>62402434
Option 3, and anybody who says the other two (especially option 2) is retarded.

>>62402434
use calloc

>>62402434
1.

File: weknowwhatsgoingtohappen.png (267KB, 543x711px) Image search: [Google]

267KB, 543x711px

>>62402434
>2017
>casting malloc

>>62402457
>>62402507
>enable -Wall
>enable treat warnings as error


WHY THE FUCK DOESN'T MY CODE COMPILE

Never use option 1. You will give your compiler malware

>>62402517
>treating warnings as errors
That's why your code won't compile.

I don't remember the last time I used malloc or new when there is safe-as-fuck RAII and unique&shared ptr initialization.

Enjoy your shitty fragmented memory

File: 1453301998037.png (239KB, 600x506px) Image search: [Google]

239KB, 600x506px

>>62402517

$ cat test.c 
#include <stdlib.h>

int main()
{
    int *ptr = malloc(sizeof *ptr);
    free(ptr);
}
$ clang -Weverything test.c
$ gcc -Wall -Wextra -Wpedantic test.c

>>62402859
ebin! nobody uses that archaic language called C

try

mv test.c test.cpp
g++ -Wall -Wextra -Wpedantic test.cpp

>>62402881
>Sepples
AHAHAHAHAHHAHAHHAHAHAHHAHHAHAHAHHAHAHHAHHA

>>62402859
>>62402881
also a much better, safer, more beautiful way

#include <iostream>
#include <memory>

int main()
{
    auto sp = std::make_shared<int>();
    return 0;
}

>>62402904
This is one of the most disgusting trivial programs I have ever seen.

>>62402924
lmao, let's see C """""safety"""""""""""

// function below is ran on a separate thread

void doshit() { // also superior way to put braces
    int *ptr = malloc(sizeof *ptr);
    doanothershit(); // <---- this somehow failed, thread aborts
    free(ptr); // OH NO I CAN'T FREE THIS
}

ABSOLUTELY EBIN! LMAO CFAGS, check the superior one:

void doshit() {
    auto *ptr = std::make_shared<int>();
    doanothershit();  // thread crashes, still freed
    if(idontlikeresult) return; // <---- still freed
    dothis(); // <--- threw exception, still freed
}

>>62402967

animefags BTFO

>>62402967
what is thread's cleanup handler?

>>62403924
destructor is ALWAYS called in RAII. because thread crashing will be throwing a runtime C++ exception. If your program is having a hard crash, then you won't need cleaning, because the process is killed already.

>>62402434

int *variable = ((int *) (malloc((size_t) ((size_t) (sizeof(int)) * (size_t) (length)))))

>>62403945
wait are we talking about threads or processes
anyways processes have exit handlers too seepeepeefag BTFO

File: c-brainlets-btfo.png (905KB, 725x1290px) Image search: [Google]

905KB, 725x1290px

>>62402434

>>62402434

std::vector<int> variable;

>>62404548

variable.reserve(length);

let v = Vec::with_capacity(length);

2 because c++ forces me to

>>62402434
All of them are wrong. You forgot to check if the return value is NULL.

>>62402507
C code that interoperates with C++ code has to do this.m

>>62402677
>I don't remember the last time I used malloc or new when there is safe-as-fuck RAII and unique&shared ptr initialization.
Modern malloc implementations like jemalloc and tcmalloc don't have fragmentation.

>>62404616
Why the fuck are you even using malloc/free in C++ in the first place?

>>62404626
Because OOP is a meme

>>62404632
Are you retarded by any chance?

>>62404639
Are you a OOP monkey by any chance?

>>62404639
Give me 1 reason I'm retarded for writing mostly C and compiling with a C++ compiler which have better support and certain features I need

int variable;
&variable = malloc(sizeof(int) * length);

>>62404670
Using malloc/free when far far better alternatives exist, such as new/delete or even better, std::unique_ptr/std::shared_ptr

>>62404669
If you think this has anything to do with OOP, you're retarded.

>>62404673
Do you work on printer drivers?

File: 1373118639991.png (589KB, 652x1024px) Image search: [Google]

589KB, 652x1024px

>>62402434
The picture is wrong: The heap can be anywhere in the virtual address space, in user-space.

It is -- at least on x86/x86-64 with ELF binaries -- not growing from the .bss segment against the stack. That was only the case 30 years ago.

Even Wikipedia knows that:
>note that the use of brk/sbrk and a single "heap area" is not required to fulfill the contract of malloc/calloc/realloc/free; they may also be implemented using mmap/munmap to reserve/unreserve potentially non-contiguous regions of virtual memory into the process' virtual address space

Today we are essentially just mmap'ing somewhere.

You see this shit even in the most up-to-date slides from Ivy League colleges.

>>62402434
I don't use malloc. Take your pills grandpa seriously

>>62404708
>touching something that is also used to allocate (((objects)))

>>62404743
Yeah man people dont even need to know what pointers are anymore lmao

File: 1499312303325.jpg (184KB, 800x980px) Image search: [Google]

184KB, 800x980px

>>62402434
>>62402457
>>62402461
>>62402497
>>62402677
>>62402904
>>62402967
>>62403971
>>62404620
>>62404626
>>62404673
>>62404708

>Not rolling your very own, 100% American-Fuzzy-Lop'ped allocator, handtuned to your specific application
i-shiggy-diggy

>>62404767
what is
>std::make_shared
>std::make_unique
>RAII

>>62404761

Foo *foo = (Foo*) malloc(sizeof(Foo));
new (foo) Foo();
...
foo->~Foo();
free(foo);

I guess you should stop using malloc then, since I just used malloc to allocate an object.
Why are you even using C++? Just go back to C.

File: c++14_memory.png (187KB, 1253x719px) Image search: [Google]

187KB, 1253x719px

>>62404767
This is basically the official position of the committee, you aren't supposed to use raw pointers anymore.

>>62404821
>Why are you even using C++? Just go back to C.
You're right. I'm just a giant faggot.

>>62404840
literally this. raw pointers are not necessary anymore, unless you are writing your own memory management. but again you will have to write your own allocator with your custom memory management and use that allocator with the new pointer arithmetic. so it's safe no matter what you do.

File: 1498400608841.png (612KB, 768x781px) Image search: [Google]

612KB, 768x781px

>>62404974
But I am writing my own allocator, Anon.

I also do not use any default headers and do not link with the C runtime (i.e. -nodefaultlibs or /NODEFAULTLIB).

This has the great advantage that you catch every idiot who is sneeking virtual functions into your code base.

>>62404673
That's a memory leak or not ?

>>62405975
It's a semantic error because &variable doesn't have a l-value

struct shit *poo = (struct shit*) malloc(pajeets * sizeof(*poo));

File: Screenshot_2017-09-13-14-15-46.png (233KB, 1440x2880px) Image search: [Google]

233KB, 1440x2880px

>>62404673
>>62406226
It no compiling

>>62406335
What part of "semantic error" didn't you understand?

>sizeof(*var)
does that work? I see dereferencing before assignment

>>62405975
You can't have memory leaks if your software won't compile.

>>62404189
how does the fourth one works?

>>62406394
>he doesn't know

>>62402434

int *variable = (int*) malloc(sizeof *variable * length);

:)

>>62402904
>using shared_ptr for everything
You disgust me.

>>62403971
This is what unironically happens if there is an error and you're trying to fix it

>>62404840
> you aren't supposed to use raw pointers anymore.
Only for ownership.

>>62406643
It doesn't.

>>62404673
I don't think you can assign to references

>>62406226
Who the fuck came up with these obscure names? lvalue or rvalue is the least descriptive thing I've ever seen

File: c++ values.png (33KB, 505x433px) Image search: [Google]

33KB, 505x433px

>>62408199
What's worse is that they keep adding more.

>>62408223
Are they genuinely retarded?

>>62404840
what are good books for learning proper c++ for the year 2017?

>>62408594
as long as it teaches C++11 or above you're good
C++11 changed everything

>>62402434
All of them are wrong.

int *variable = calloc(length, sizeof(*variable));

A sane calloc implementation will always check for overflow. Never multiply without an overflow check.

>>62408199
It's not that bad. lvalue can go on the left side of the = sign, rvalue can go on the right.
So if i is an int, you could write

i = i + 1;

It makes sense because i is a variable, and i + 1 evaluates to an int. You could also do i = i;.

But you would never write

i + 1 = 5;

. i can be an lvalue, but i + 1 can't because it's obviously not something you can set. An rvalue is just something that evaluates to a value, so i + 1 is a valid rvalue.

>>62408825
It's still a pile of shit.

>>62408594
effective modern c++

>>62402434
int* variable
variable = (int*)malloc(length*sizeof(int))

>>62409152
>int*

>>62409152
int *variable is objectively superior

#1 if I alloc after the declaration
#3 if allocing in the declaration

>>62409152
The star belongs to the Identifier, bloody hell!

>>62409266
>>62409222
>>62409152
>>62409301

template <typename T>
using type = T;

type<int*> ptra, ptrb;

where is your god now

File: 1487577208243.jpg (130KB, 766x864px) Image search: [Google]

130KB, 766x864px

auto variable = new int;

>>62409685
>naked new
disgusting

>>62402434
It's a code monkey's business. Everything except MATLAB is for code monkeys.

>>62409301
Your reasons? int* is a pointer type pointing to an int, so it makes more sense to think of int* as a type.

>>62410219

int* a, b;

What's the type of b?

>>62409322
>not #define intptr int*
Sepples please.

>>62410326
>text substitution macros behaving unpredictably/incorrectly.
What a shock!

>>62410326
Fug, #typedef

int *variable;
variable = malloc (length * sizeof (*variable));

>>62410278
oh fuck you, just because you can write retarded code doesn't mean you should

>>62410369
s m h

>>62410370
>not even refuting my point
Boring.

>>62410342
Typedef works as expected though, e.g. >>62410278
would work.

>>62410447
using statements are just an alias for typedefs. It's the same shit.

>>62410415
what point? that it's easier to write retarded code this way?

>>62410486
>what point
That * belongs to the identifier. You literally can't disprove that, only claim that int* makes more sense. It does, but that's not how things work.

>>62410549
>It does, but that's not how things work.
This is the important thing to remember when writing C.

>>62410549
>You literally can't disprove that, only claim that int* makes more sense. It does, but that's not how things work.
That's exactly how I think too. We just understand "belongs to" differently.

>>62410549
>>62410581
nevertheless, it doesn't follow from that the asterisk should be placed next to the identifier

>>62410626
It does, because that's how the language's grammar works. All the other tokens (subscript, function call) are placed next to the identifier.

if proper memory management is so hard for people that they want people to not use it and phase it out, why not just call it c#

>>62410903
who said its too hard and wants it removing?

File: 1493901349094.jpg (127KB, 745x717px) Image search: [Google]

127KB, 745x717px

>>62402507
what is wrong with casting malloc

struct kittenbox * box_of_kittens = (struct kittenbox *) malloc(sizeof(struct kittenbox))

>>62402904
>>62402967
Why are you using a reference-counted shared_ptr for this instead of just

auto ptr = std::make_unique<int[]>(123);

or even better, for your example, as you're only allocating one int,

int thing;

>>62410991
in C, it can hide bigger problems with your code that will literally break your code, kill your dog, hurt a kitten, etc. But all the same, if you use malloc properly you don't need to cast the output of malloc.

>>62404974
Raw pointers are good as a way of internally storing a reference to a class which always lives longer than the class holding a pointer where it doesn't make sense to use shared_ptr, as you weren't responsible for creating the referenced class, rather than making a reference member field in your class, which would stop you being able to implement things like a move assignment operator properly.

Friendly reminder that the sizeof keyword is not a static macro function.
When you wirte sizeof(char *), it is interpreted as sizeof (char *) with the second token being an explicit cast operator for char *, it's taking the byte count of this type cast.
This is why you can write sizeof *ptr, and sizeof(*ptr) never produces the result you want.