Car* car = new Car()

Car* car = new Car()
car.init()

Attached: 6d851e8b8da31769f123857e23e6.jpg (621x480, 57K)

Other urls found in this thread:

godbolt.org/z/71FEJ7
godbolt.org/z/mIXy6r
godbolt.org/z/R7hs-B
godbolt.org/z/dn-1fQ
godbolt.org/z/MfddyB
twitter.com/AnonBabble

you forgot your ; user

Car::Car()
{
init();
}

car()

car* makeCar(){
struct car myCar = { .color = C_BLUE, .speed=220, .wheels = 4 }
struct car* car = malloc(sizeof(myCar));
memcpy(car, myCar);
return car;
}

THE
SHEER
ELEGANCE OF C

OOP BTFO FOREVER

For(int x=0; x

New old = new Old();

looks inefficient

At least declare the first struct as const otherwise you're copying data twice for no reason. Anons these days waste moar CPU cycles than niggers with welfare.

>nobody knows C well enough here to see that I forgot to get a pointer for the second memcpy parameter

Behold
var car = new Car() { Wheels = 4, Color = Color.Red };

auto car = std::make_unique();
car.init();

It says you're going to return a direction, but you return a struct

You don't eve need a memcpy

car* makeCar(){
struct car* car = malloc(sizeof(struct car));
*car = { .color = C_BLUE, .speed=220, .wheels = 4 }
return car;
}

return &car

no?

no

S C O P E A N D L I F E T I M E

Actually you can't do this, I forgot that you can only use that initialization shorthand when creating the object. Otherwise you need to initialize every attribute.

That's why C is a bad language. Shit like that shouldn't even compile.

It's not about that. It's about not returning a pointer to a pointer.

its on the heap. lifetime is ok

Poo poo = new Poo();
poo.init();

Nobody uses memcpy to assign structures. That's why.

holy shit you can actually make a struct within a function and make the function return a struct thingie?!

let mut car = box Car::new();
car.init();

Attached: highiq.png (602x301, 94K)

It won't compile

if you move the data onto the heap, sure?

You can return a struct, but it is not what that code was trying to do. (tip: it returns POINTER to a struct)

>box Car::new();

What? Isn't Car::new() already a pointer?

oh, good

>Nobody uses memcpy to assign structures
if you're cloning some expensive struct instead of making a new one, why not

>mfw no variables
comfy a.f.

Attached: 1200px-Haskell-Logo.svg.png (1200x847, 15K)

nvm, I thought wrong

(car (cdr Car))

It is perfectly valid C to have a function return a struct, even one that isn't a pointer to a struct.

No. Pretty sure box isn't used like that too. And Car::new would include init.

>does nothing 99% of the time
>runs out of memory evaluating a thunk

yes if the lifetime doesn't end at the returning function

Just download some ram. Are you poor or something?

No it will return a copy of the return on the stack. Which may be inefficient if it's a very large struct.

Why the fuck are you all heap-allocating?
struct Car makeCar(){
struct Car c = { .color = C_BLUE, .speed= 220, .wheels = 4 };
return c;
}

oh yeah my bad. You only can't return a pointer to a local stack value

>not using pointer
this nigga lmao

it is more efficient to return the struct by value if it is

create struct on stack
copy struct into return value
copy return value into local variable of caller

you can, it will probably just be garbage

does C have guaranteed NRVO?

>Language has no pointers
>Still uses "new" operator to create objects

That's so fucking dumb. Using Dart made me realize how pointless that keyword is.

Programmers nowdays can't even get a correct C yet they want to replace it with even more complicated things like Rust.

>it will probably just be garbage
i suppose yeah. The question was if it was valid though, and undefined behavior is probably invalid

so how does that look?

MyThing m = new MyThing(params);

becomes

Mything m(params);

or what

struct Car car = makeCar();

>that thing again
The cancer that is killing Jow Forums

just write a factory patter then

class Car{
...
static Car makeCar(params){
return new Car(params);
}
...
}

C99:
struct Car makeCar()
{
return (struct Car){ .color = C_BLUE, .speed= 220, .wheels = 4 };
}

hide/don't bump

C doesn't have the new keyword to begin with

You also forgot a semicolon in the first line.
And the size argument for memcpy.

The compiler generates almost the exact same code.
godbolt.org/z/71FEJ7

C compilers are pretty smart.

var things []Thing

Oh I fucked up, should have malloc'd sizeof struct car in the second one.

>mfw someone actually implemented my shitty example
>twice
>and disassembled it
>to see how efficient it is
cool

Wonder why GCC changes RSP manually in the frist one, but uses pop and push in the second one.
godbolt.org/z/mIXy6r

Yes, and? Sepples doesn't even have designated initializers yet. Only beginning with C++20. C has them since C99. It was time, heh.

>201x
>still using pointers
boomers pls go

clang optimized a lot less it seems

Attached: clang.jpg (732x547, 48K)

You were never supposed to call it car you monkey. Call it Honda or Toyota

Any C compiler worth its salt can optimize out the additional return, but no C compiler can optimize out a malloc().
See godbolt.org/z/R7hs-B - versus godbolt.org/z/dn-1fQ (I had to fix the code, because "*car = { }" isn't valid C).
makeCar:
movabs rax, 17179869404
movsd xmm0, QWORD PTR .LC0[rip]
ret

vs.
makeCar:
sub rsp, 8
mov edi, 16
call malloc
mov rdx, QWORD PTR .LC0[rip]
movabs rcx, 17179869404
mov QWORD PTR [rax+8], rcx
mov QWORD PTR [rax], rdx
add rsp, 8
ret

GCC can't even inline the function because of your stupid malloc, now tell me how that's somehow "more efficient". Use stack allocation like a white man.

That's why even today you use clang for fast compilation and useful analysis and GCC to produce the final binaries.

Although clang is pretty smart at one thing:
godbolt.org/z/MfddyB

clang is trash confirmed

That's not a factory pattern. Try more like this:
abstract class CarFactory
{
abstract public Car FactoryMethod();
}

class HyundaiFactory : CarFactory
{
public HyundaiFactory() { }
public override Car FactoryMethod()
{
return new Hyundai(params);
}
}

A factory object is like a glorified function pointer. Its sole purpose exists in the virtual method for creating the object in question. It's a little more useful than say, using a pointer to the class' constructor, since the factory itself may have instance variables to serve as a form of partial function application.

```I am code```

The linux kernel makes extensive use of this.

underrated

Attached: 1530745997321.png (300x250, 19K)

Programming is more akin to maths and logic than it is to engineering and industrialization, at least that's how I idealize programming here. Outside of that ideal, it quickly falls into the same sins as you see everyday on Jow Forums: muh shills, muh jobs, muh politics, etc,.

shameless samefagging frogposter

Appeal to authority. Because it's the linux kernel doesn't mean it's very high quality code. It uses GNU extensions for one.

>Because it's the linux kernel doesn't mean it's very high quality code.
Heretic!

Technology is not a religion.

based

Attached: 1522599766136.png (1790x1640, 56K)

>Just allocate everything on the stack
Gee I wonder what could go wrong...

Not exactly a fair comparison, because allocating on the stack limits it's scope, and there is no functional difference from just defining the struct directly in the caller (which is what the compiler does). For many purposes, the heap is what you will need.

>If I don't see the pointers, they don't exist!

Attached: 1534605781426.gif (652x562, 626K)

What does the * do?

pointer is an abstraction
if there is no such abstraction in your programming language, they don't exist in your programming language
pointers are not real
but tidepods are

>pointers are not real
Pointers are implemented physically in your CPU you fucking idiot

Attached: 1540714717019.png (1190x906, 178K)

God I hate faggots that don't know how to use constructors and destructors propertly

So say you declare a struct, malloc, then assign values to it's fields directly. Is this objectively more efficient than making a constructor function with arguments to supply values to assign to a malloced struct's fields? Can gcc or clang inline it?

>Pointers are implemented physically in your CPU you fucking idiot

Yes you larping faggot, both ARM and x86 are engineered to use pointers

there are no size limits for stack in 64 bits.
On windows there's a leftover from the past days in the file structure that sets the maximum stack, but it can be set to 1TB if you want

Size should not be a consideration, use stack when the lifetime is scope limited, heap when it's independent

And you are incapable of having an intelligent discussion. All von Neumann architectures have addressable memory, so you have cpu instructions for accessing memory by its address. Pointers are not a physical thing on a CPU. ALU is. Cache is. Register is. But not a pointer.