int *foo = malloc(sizeof(int) * 4); int bar[5]; What are the

>>60242939
malloc returns void* so you need to cast it to an int* retard
and fuck off with your homework

File: C++.png (40KB, 1620x774px) Image search: [Google]

40KB, 1620x774px

>>60242982

>typical C++ programmer

Int pointer

>>60242939
int

Look at my portable and robust code

#include <stdio.h>
#include <stdlib.h>

int main (void) {
  char *p = malloc (4 * sizeof (int));
  if (p == NULL) {
    return 1;
  }
  p[0] = 'h';
  p[1] = 'e';
  p[2] = 'l';
  p[3] = 'l';
  p[4] = 'o';
  p[5] = 0;
  if (printf ("%s\n", p) < 0) {
    free (p);
    return 1;
  }
  free (p);
  return 0;
}

>>60242939
Bullshit code like this and especially this braindead style of identation is something that I unironically encounter every day at work. I don't even have the energy to refactor this junk anymore, every day I want to kill myself more.

>>60243536

>char *p = malloc (4 * sizeof (int));

>>60242939
int * and int [5]

>>60243650
Triggered?

File: sad-dog-copy-624x517.jpg (55KB, 624x517px) Image search: [Google]

55KB, 624x517px

>>60242939

the thing that makes me the angriest about this is the indentation.

i mean yes it's also completely retarded to not cast the return value of .getLabel(), decrement, and pass it directly to GUI.cards

but god damn, why is every successive else if block further indented? that's what really rustles up the old jimjams for me

>>60242939
foo: int*
bar: int[]

>>60243536
Nice dangling pointer you have there, faggot.

>>60243536
>portable and robust code
Only works on implementations with sizeof(int) > 1

>>60243816
No. char has exactly 256 values (otherwise it means that you use something that ain't ascii or utf8, but it's impossible there is nothing more than those two). So sizeof (int) >= 2.

Deal with it my code is portable.

>>60242939
It's right there in the type signature, dumbfuck.

File: 1493817354195.jpg (23KB, 552x535px) Image search: [Google]

23KB, 552x535px

>>60243660
This
>>60243751
Wrong

>>60243017
>implying java is any better overall

>>60245268

Nope, never said anything like that.

>>60242939
You laugh, but the textbook for one of my courses had code samples just like that.
The worst part is that the book was written by my professor.

>>60243660
This, come on guys

>>60243354
this

heap
stack

>>60243865
Read the relevant part of the standard again. A char just has to have at least 255 values, but it could be more. An int has to have at least 65,535 values. Of course sizeof(char) is always 1, but 1 byte doesn't necessarily mean 8 bits. You could have a 16-bit char, a 16-bit short and a 16-bit int, in which case sizeof(int) is 1 and p[4] is outside the array.

>>60243738
The indentation kind of makes sense. In a sense there's no such thing as elseif in C, it's just nested ifs inside the elses.

An if statement has the form (roughly)

if (expression)
    statement

or

if (expression)
    statement
else
    statement

To do else-if, you just replace the second statement (the one after "else") with a whole new if statement. So they're kind of all tail-nested or something.

But I agree that it looks bad to actually indent it that way.

>>60247081
Implying a char can be something else than ascii or utf8 part. Shut the fuck up.

>>60243865
>No. char has exactly 256 values
retard

>>60247193
Bastard encoding are a plague that must disappear. No code must acknowledge their existence.

>>60247230
this has nothing to do with encoding but the architecture.

>>60247259
A char os for text, text are ascii or utf. If you have strange numeric type, use int. It's da best.

Case closed.

>>60247360
read the fucking standard and learn about different cpu architectures.

>>60243660
This is correct.

>>60247360
and every char is 8 bit long, right ?

>>60243816
int by stadard must be least 2 bytes wide

>>60247401
>>60247417
You don't get it. I'm sorry for you.

>>60247081
>but 1 byte doesn't necessarily mean 8 bits

Citation needed.

>>60247543
seriously ? do you only know x86 ?

>>60247595
Can you name a platform where it isn't 8 bit?

>>60247595
>>60247619
and something you just made on an fpga or asic doesn't count.

>>60247619
>>60247636
https://en.wikipedia.org/wiki/PDP-8

or pretty much everything there a parity bit is added

>>60247705
I meant something made in this century, or at least something made in the last 50 years?

>>60247705

A byte is always 8 bits on any machine.

That's like saying "I ran a race where one yard was equal to two feet"

>>60247155

i have always been an ardent follower of the "only indent after an forces you to do it. it keeps the scopes of conditional blocks and loop bodies consistent.

>>60248164

woah something got fucked right before i posted... what i mean to say was:

i have always been an ardent follower of the "only indent after an opening brace, and dedent for the closing brace". bsaically the way python forces you to do it. it keeps the scopes of conditional blocks and loop bodies consistent.

>>60248116
funny, i just posted a link to a machine where a byte is 12 bits.

>>60247845
>or at least something made in the last 50 years
https://en.wikipedia.org/wiki/CDC_6600
+ there are still some embedded architectures

File: 1469904636514.jpg (55KB, 479x592px) Image search: [Google]

55KB, 479x592px

>malloc

>>60248289
1965 was more than 50 years ago

>>60242939
>int* foo = new int[4];

C fags will attack this.

>>60250199

>naked new
>C arrays
Not idiomatic enough.

std::vector<int> foo(4);

>>60250289

std::array<int, 4> foo;

>>60250380

nah that's

int foo[4];

senpai

>>60250434
Please, you're old grandpa. Use modern method.

>>60250469

I think you misunderstand senpai.

std::array<int, 4> foo;

is the i d i o m a t i c way to do

int foo[4];

Likewise

std::vector<int> foo(4);

for

int* foo = new int[4];

or

int *foo = malloc(sizeof(int) * 4);

>>60250512
OK. We agree. I just misunderstood your laset post. Yes array and vector are not the same thing.

>>60242939
they are both pointers

>>60250562

this is why C was a mistake

File: 1483722174179.jpg (162KB, 828x960px) Image search: [Google]

162KB, 828x960px

>>60250606
>tfw to smart to understand pointers

int* ptr = 0;
ptr++;

What is the value of ptr after these two statements?

>>60250780

we just don't know

>>60250780

platform dependent

But typically 4

File: 6jqju2dhpeky.jpg (359KB, 1639x2048px) Image search: [Google]

359KB, 1639x2048px

>>60250780
1. You incremented 0.

>>60250780
4 [spoiler]on my machine xd[/spoiler]

>>60250853
1. No he didn't

>>60250780
depends on the architecture, most likely 4 on 64bit systems and 2 on 32bit systems

extern int* ptr = new int();

What does this line of code do? Don't disappoint me, /g/, you can do it!

>>60250853

no he incremented 0 by ptr

>>60250900
No, he incremented the fucking pointer, you retard.

File: lol.gif (538KB, 358x234px) Image search: [Google]

538KB, 358x234px

>>60250893

>most likely 4 on 64bit systems and 2 on 32bit systems

>>60250898
Fails to compile.

>>60250911

Yeah, the pointer was 0 and he incremented it by ptr, which is of an unknown size to us

File: Untitled.png (7KB, 787x257px) Image search: [Google]

7KB, 787x257px

/g/ btfo

>>60250938
>the pointer was 0
The pointer can't be an int, because the pointer is a pointer, you fucking retard. Go read up on what pointers actually are and do.

>>60250938
its a pointer to an int which is at least 2 bytes. other than that, you are right.

>>60250945
POO

>>60250780
value of prt is sizeof(int)

>>60251020
It depends of the pov. For me it's 1.

>>60250780
Probably, but not necessarily, 4 or 8.

File: kobold has seem some shit.jpg (39KB, 408x360px) Image search: [Google]

39KB, 408x360px

Is the following statement legal?

int test[] {1, 2, 3};

The answer may surprise you!

>>60251056
Language?

>>60251086
C++

>>60251102
It depends of the compiler. I think g++ on OpenBSD refuse it but not on Linux. It's probably a new syntax.

>>60251056
Yes, it is valid, but it's not surprising, considering

int a{4};

is also valid and a syntax that (for some stupid reason I don't understand) I see pretty often.

>>60251056
in c++11

>>60251139
They try to unify C++ syntax by introducng that stupid {} notation for constructors. C++ is a pile of poor design choices.

File: 1487021442145.jpg (103KB, 726x600px) Image search: [Google]

103KB, 726x600px

Hardcore version of the previous question:

#include <vector>
myFunc(std::vector<int> test) { };
main ( ) 
{
    myFunc( { 1, 2, 3 } );
};

DOES
IT
WORK?

>>60251201
>myFunc lacks return type

>>60251165

What do you expect when you have a language that wants to remain backwards compatible with a 70s programming language, while also declaring any use of those features evil and insisting you make a whole bunch of other constructs your main tools instead?

>>60251201
>main without return type
no senpai, how would this shit work

>>60251221
No. That's not C. It;s just C++ is totally crazy. Please leave C alone.

>>60251165
But templates

>>60251233

C is OK enough.
Maintaining C compatibility while doing all this other crazy shit is a large part of the problem.

File: Untitled.png (14KB, 798x379px) Image search: [Google]

14KB, 798x379px

>>60251223
main without return type is legit though

int* ptr = 0;
ptr = (int)(ptr)+(int)(ptr+(int)(ptr));

what is the value of ptr?

>>60251246
No. Here we're just talking about pure C++ syntax. It's pure C++ notation.

>>60251259
Illegal code.

>>60251260

And that notation is shit, because all of C++'s new syntactical features need to squeeze around the requirements of C compatibility. Get it?

>>60251275

the compiler didn't stop me

>>60251280
No. Initialization without = is pure C++. It has nothing to do with C, nothing. Dirtiness always come from C++, not C.

>>60251285
Your compiler should. The compiler in my head refuse to compile that illegal code.

>>60251298

I thought we were talking about initializer lists.

>>60251327
We were talking about initializer without = sign.
C++ is dirty, not C.

>>60251346

>We were talking about initializer without = sign.
>>60251165
>They try to unify C++ syntax by introducng that stupid {} notation for constructors.

No, the issue you raised is definitely one of initializer lists.

File: main.jpg (128KB, 789x468px) Image search: [Google]

128KB, 789x468px

>>60251256
that must be some compiler-specific extension shit

>>60251367
>No, the issue you raised is definitely one of initializer lists.
Without = sign
Why do you brague about C compatibility? Why?

>>60251372
Works on all modern compilers. Try it on yours, anon.

>>60251372

void main() is C style

>>60250780
That's literally undefined behavior.

>>60251475

undefined =/= implementation defined

>>60251495
Like I said, it's undefined behavior.

>>60251507

it literally isn't, it's implementation defined

File: 2017-05-07-004721_597x84_scrot.png (21KB, 597x84px) Image search: [Google]

21KB, 597x84px

>>60251520

>>60251562

>If both the pointer operand and the result point to elements of the same array object
They don't point to any object. Try again?

int a = 0;
a = (a++);
printf("%d\n",a);
a = a++ + ++a;
printf("%d\n",a);

what does the output look like?

>>60251416
>>60251455
>error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
C-ucks on suicide watch

>>60245268
nobody implied that you retarded tripfag

File: 1473999778666.jpg (54KB, 500x500px) Image search: [Google]

54KB, 500x500px

>>60247845
>get btfo
>t-that one doesn't count!

>>60247845
That's not how question marks work.

>>60251612
its undefined behavior you thickhead
http://stackoverflow.com/questions/43673104/incrementing-null-pointer-in-c

>>60252459

We're talking about an int pointer here, bud

>allows main not returning a value
>doesn't allow declaring main without return type
Really jogs the noggin.

>>60242982
this is deprecated
OP is right

>>60251620
The behaviour is undefined so any and all output is meaningless.