[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y ] [Search | Free Show | Home]

Which way is correct?

This is a blue board which means that it's for everybody (Safe For Work content only). If you see any adult content, please report it.

Thread replies: 143
Thread images: 5

File: ptr.png (12KB, 368x153px) Image search: [Google]
ptr.png
12KB, 368x153px
Which way is correct?
>>
>>57660166
bottom
>>
>>57660166
second because
void *ptr1, *ptr2;
>>
>>57660166
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;
>>
>>57660182
would
void* ptr1, ptr2;
work the same way?
>>
>>57660182
If you declare variables like that then you're a dick
>>
>>57660182

If C wasn't shit this would be correct

<code>
void* ptr1, ptr2
</code>
>>
>>57660193
No, that'd be equivalent to:
void* ptr1;
void ptr2;
>>
>>57660166
The way i fuck your mom
>>
They both work
>>
File: 1479087524944.jpg (10KB, 261x197px) Image search: [Google]
1479087524944.jpg
10KB, 261x197px
>>57660198
><code>
>>
First one in C#, second one in C++.
>>
>>57660218
How often do you need to use pointers in C#?
>>
File: rock.jpg (45KB, 1024x768px) Image search: [Google]
rock.jpg
45KB, 1024x768px
>>57660198
>variable of void type
>>
Whynotjustwritevoid*ptr;Whitespaceiscancer.
>>
>>57660198
/thread
>>
obviously the bottom. Only niggers would think otherwise
>>
>>57660166
void*ptr;

is fine.
>>
>>57660166
void * ptr;
void * ptr1, * ptr2;
>>
>>57660166
void* ptr;

makes more sense because ptr is type void*
>>
>>57660274
this
>>
>>57660274
void *ptr;

makes more sense because *ptr is type void
>>
>>57660314
this
>>
>>57660166
it's the exact same fucking thing since the compiler will trim/ignore white spaces.
>>
>>57660198

"""code"""
"""/code"""
>>
>>57660235
Gotta save those 2KB of memory when writing programs.
>>
Sadly bottom.
It's dumb.
>captcha:Calle calle
Now you're just playing with me..
>>
>>57660314
this is aids
>>
>>57660429

C fags will defend this.

>muh optimization
>>
>>57660429
it doesn't save any memory
>>
>>57660452
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.
>>
>>57660502
>calling it memory
You mean storage space.
>>
>>57660502
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
>>
>>57660166

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 <stdio.h>

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

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

exit(0);
}
>>
>>57660502
It's only for the sources though. The binary doesn't have them.
>>
>>57660525
>>57660535
> compiled
I was talking about the code, i.e. uncompiled source. Can you read?

>>57660519
https://en.wikipedia.org/wiki/Persistent_memory
>>
>>57660525


>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..
>>
>>57660429
And performance, don't forget gcc compiles whitespace to no-ops.
>>
>>57660528
>main {
>do nothing
>exit(0);}

>exit(0);
>>
>>57660544
damage control activated
>>
>>57660166
bottom you dumbfuck
>>
>>57660560

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.
>>
>>57660627
I'm not the anon 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 <stdlib.h>, 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.
>>
>>57660235
b=a+++++b;
>>
>>57660694
a++ + ++b ?
>>
>>57660710
A compiler will read that as "((a++)++) + b", which is invalid and fails to compile.
>>
>>57660552
kekd
>>
>>57660166
I actually prefer "void * ptr;"
>>
File: 1477330703606.jpg (259KB, 1280x974px) Image search: [Google]
1477330703606.jpg
259KB, 1280x974px
>>57660229
just stick to haskell

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


ohhh fuck
>>
>>57660192
>void* ptr makes sense as well
explain yourself
>>
>>57660756
>>57660274
>>
>>57660677

>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 <stdlib.h>, but you have not included it

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

get fucking good then come back

>>57660192
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.

>>57660749
i'd love to learn it desu but its easier to write shit in python and get paid for it
>>
>>57660252
The only correct answer.
>>
>>57660528
>"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.
>>
>>57660166
void* *ptr;

Because C pointer syntax is absolutely unreadable garbage.
>>
>>57660944
>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"
>>
>>57660314
>a variable can be of type void
>>
>>57660917
>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.
>>
>>57661029
>>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++?
>>
>>57661106
both
>>
>>57661106
Definitely C.
C++ will only serve to taint you.
>>
>>57661106
Learn C and expand on it with C++.
>>
>>57661166
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'.
>>
>>57660166
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;
>>
>>57660726
no big deal, it's retarded to begin with
>>
>>57660166
void* ptr;


Obviously.

Because
void *ptr1, *ptr2;

is a travesty.

Right way to do it is
void* ptr1;
void* ptr2;
>>
>>57661185
>t. never used any other "mainstream" language
>>
>>57661230
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.
>>
>>57661185
>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 /g/ that it's only suitable for prototyping, but this is objectively wrong.
>>
>>57661258
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.
>>
>>57661275
>>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.
>>
>>57661340
>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.
>>
>>57661340
>>57661402
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.
>>
>>57661476
>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.
>>
>>57660252
This for Christ sake.
>>
>>57661476
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).
>>
>>57661166
Assuming you're also this guy: >>57661275

What's the value in learning C first if they're objectively different languages?
>>
>>57661550
Learning C first will give you the perceptive to see how poorly designed C++ actually is.
>>
>>57661530
>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.
>>
>>57661558
How is C++ poorly designed?
>>
>>57661550
>Assuming you're also this guy:
He's not.
>>
The correct way is not using pointers in order to avoid dangerous buffer overflows.
>>
>>57661568
std::list<std::shared_ptr<sf::Drawable>> x;
>>
>>57661594
So the syntax is difficult? Are there any other poorly designed features?
>>
>>57661566
>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.

>>57661589
Pointers are a fundamental tool in C. You could never write a non-trivial program without using them.
>>
>>57661550
>>57661577
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.
>>
>>57661609

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?
>>
>>57661607
>So the syntax is difficult?
Yes. It's horrendous. The example that anon 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.
>>
>>57661609
>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.
>>
>>57661629
>Pascal
Are you fucking kidding me?
Go to bed, granddad.
>>
typedef void* voidptr_t;
voidptr_t ptr1, ptr2;

This is the only correct way.
>>
>>57661664
_t is for POSIX types only, you fool
>>
>>57661663
>someone missed the point
>>
>>57661642
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.

>>57661664
But what if I want to use an int pointer?
'intptr_t' is taken.
>>
>>57661667
Whatever, you get the point. Typedef the pointer to something else.
>>
>>57660198
no.
>>
>>57661594
>typedef std::list< std::shared_ptr< sf::Drawable > > DrawablePtrList;

Just make types, anon. What's the point of using a language with a rich type system, if your plan is not to use custom types?

>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.
C++ doesn't have any more features than any modern programming language. In fact, it has way less. It's actually possible to read the entire C++ standard. It's not feasible to learn Java or Python from reading the specs only.
>>
>>57661622
>I might as well provide you my opinion on that
It's nice to get an opinion from someone who doesn't downright hate C++.

I've heard people say that learning C++ teaches you most of C anyway. Is this true? Should an effort be made to learn C on its own first then?

>knowing how C synthesises to machine code
Would this require learning assembly as well or just the general process?
>>
>>57661675
 typedef int* int_ptr; 
>>
>>57661568
std::chrono::high_resolution_clock::time_point myTime = std::chrono::high_resolution_clock::now();
>>
>>57661716

DELTE THIS
>>
>>57661687
>Should an effort be made to learn C on its own first then?
Yes it's better to learn them seperately because of the way you can write both in the same program, can be very confusing for a new comer. Learn plain C then C++ once you're comfortable with C.
>>
>>57661683
>C++ doesn't have any more features than any modern programming language
I'm talking about actual language features, not the contents of the standard library. Although I suppose iostreams are the standard library. It just goes to show how operator overloading is horribly misused, and how virtual functions are slow as fuck.
Yes, Java has a fucking massive standard library, but it terms of 'language features', it is nowhere near as complicated as C++.
>>
>>57661675
>Doesn't C++ just fix that shit with 'extern "C" { }' or whatever?
This only ensures that function declarations (aka symbols) are generated using the C ABI rather than with C++ ABI, in other words make it easy to call C functions from C++. The other way around is non-trivial, and especially when you throw objects into the mix.

>You don't need to mix C and C++ in the same source file. Interface using the header files.
I agree with this, my point is that it's nice to be able to compile with the same compiler.

>>57661687
>I've heard people say that learning C++ teaches you most of C anyway. Is this true?
It can be, but I would argue that it wouldn't be very beneficent. It might lead to a situation where you'd expect C to do something, and then in reality it behaves completely different.

>Should an effort be made to learn C on its own first then?
I would say so, yes. But I know people would disagree with that.

>Would this require learning assembly as well or just the general process?
Well, in my opinion, the general process cannot be fully comprehended without a rudimentary knowledge of assembly and how executables are stored on file and loaded into memory (ELF, Macho, PE etc) with different sections and segments and so on. It's not strictly necessary, but it greatly improves your understanding.
>>
>>57661728

std::chrono::high_resolution_clock::duration<double> deltaTime = std::chrono::high_resolution_clock::duration_cast<std::chrono::high_resolution_clock::duration<double>>(mytime1 - mytime2);

>>
>>57661530
>Source compatibility with C isn't a requirement at all for a language to be able to be able to use header files.
It obviously is. You MUST have at least preprocessing directives compatible.
>C's ABI is so damn simple
C itself doesn't have an ABI.
>Every other language gets around that
Those methods are ad-hock, because writing a big part of C translator and making your language depend on the C standard is kind of bothersome. Hence, the methods are inferior to reserving some compatibility, when your language was designed as an extension of C.
>There is no good reason
Yes, there is. It has something to do with availability of compilers.
>there are more differences that most people realise
What is to realize? All differences are summarized at the end of the C++ standard.
>>
>>57660182
what about
void function(void*)
.
>>
>>57661757
void function(void *)
>>
>>57661769
What about
void* function(void*)
>>
>>57661787
void *function(void *)
>>
>>57661716
auto myTime = std::chrono::high_resolution_clock::now();


>>57661739
>I'm talking about actual language features, not the contents of the standard library.
Despite what /g/ believes, the content of the standard library is always part of the language and it's features. But even so, I was also referring to language features.

>Although I suppose iostreams are the standard library. It just goes to show how operator overloading is horribly misused, and how virtual functions are slow as fuck.
It shows neither. Virtual functions is basically just a memory lookup, and is often not only optimized by the compiler, but because of hardware functionality such as caching, just as fast as non-virtual functions. As for operator overloading, I would argue that it is more handy, but I can understand the arguments against them. However, this leads to what I call Java-style signatures, where you have signatures such as the following:

Vector newVector = vector1.dotProduct(vector2.horizontalAdd(vector3));



>Yes, Java has a fucking massive standard library, but it terms of 'language features', it is nowhere near as complicated as C++.
Java has a massive threading model as well as a clusterfuck of remote and distributed objects. In order to fully understand Java, you would not only be required to read the Java spec, you'd also be required to read the spec on the JVM which is five to six times the number of pages compared to the C++ spec (which even contains the C standard library).

There's also a bunch of other functionality and features, such as garbage collection, unsafe vs safe references, generics, generics in Java 8, Java 8 style lambdas, language support for dynamic code, etc.
>>
 *function 
just looks ugly
>>
>>57661799
no
>>
>>57661807
yes
>>
>>57661807
What about declaring a function pointer for a function which returns (void*) and takes in a single argument of type (void*)?
>>
>>57661748
>You MUST have at least preprocessing directives compatible
Reading back on what I said, I realised that isn't what I wanted to say at all. I was mixing two thoughts there.
>>Source compatibility with C isn't a requirement at all for a language to be able to be able to use C functions
Yeah, I was wrong.
>C itself doesn't have an ABI.
Sure, but due to its design, it allows implementations to have stable ABIs. I'm pretty sure the standards committee is very concious of not breaking anything that already exists.
There have been several occasions where C++ ABIs have had to change as more features are added. Also, C++ compilers usually have incompatible ABIs, even on the same platform.
>It has something to do with availability of compilers
In what situation would you have a C++ available, but not a C compiler?
>All differences are summarized at the end of the C++ standard.
I've never read it before, but just scrolling to the end, the index section is seriously like 100 pages long.
That reinforces the "too much shit" thing I was talking about.
I doubt most programmers have read this.
>>
wtf you nerds arguing about fucking starcommas
just buy a fucking smartphone
>>
>>57661821
void *(*function)(void *)
>>
>>57661844
See, that's retarded.
void* (*function)(void*)

is so much more readable.
>>
>>57661861
it's not. you simply can''t understand the mantra of C.
>>
>>57661663
What's wrong with Pascal?
>>
>>57662005
What's wrong with COBOL?
>>
>>57662025
Nothing. It's a great language. It's just unfashionable.
>>
>>57662025

What does it tell you when even Pascal manages to be better than your dogshit programming "language"?
>>
>>57662057
C is truly garbage.
>>
>>57661106

>Should i learn C or C++?

Always start with C, even if you plan to learn C++ somewhere in the future.

Protip: Don't learn C++.


>>57662025

What?!?
Literally everything is wrong with COBOL.
It was literally designed for people who can't program, everything is extra verbose for increased saftey (that's what they really though, back then).

Here is "Hello World" in COBOL, I shit you not:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
>>
>>57661106

Neither

Learn a modern language like nim.

http://nim-lang.org/
>>
>>57662133

Or compare those (note the cobol porgramm accepts only single digits here):

#include<stdio.h>

int main() {
int a, b, c;

printf("Enter two numbers to add\n");
scanf("%d%d",&a,&b);
c = a + b;
printf("Sum of entered numbers = %d\n",c);
return 0;
}



      $ SET SOURCEFORMAT"FREE"
IDENTIFICATION DIVISION.
PROGRAM-ID. Multiplier.

DATA DIVISION.

WORKING-STORAGE SECTION.
01 Num1 PIC 9 VALUE ZEROS.
01 Num2 PIC 9 VALUE ZEROS.
01 Result PIC 99 VALUE ZEROS.

PROCEDURE DIVISION.
DISPLAY "Enter first number (1 digit) : " WITH NO ADVANCING.
ACCEPT Num1.
DISPLAY "Enter second number (1 digit) : " WITH NO ADVANCING.
ACCEPT Num2.
MULTIPLY Num1 BY Num2 GIVING Result.
DISPLAY "Result is = ", Result.
STOP RUN.
>>
>>57662164
>unironically using scanf
Enjoy your buffer overflows, fag.
>>
File: fucking balls.jpg (96KB, 600x600px) Image search: [Google]
fucking balls.jpg
96KB, 600x600px
>>57660314
just no.
the variable is ptr, no *ptr. probe: you can still use ptr alone.
*ptr means the content under location ptr, which is a sequence of bytes (may be length 0)
>>
>>57660198
this

Its not "a pointer-variable holding voids" its "a variable holding void pointers"
>>
>>57662148
>Still no compiler
Sticking with C/C++ was a good idea after all.
>>
>>57660166
It doens't matter.

void* ptr;
void * ptr;
void *ptr;


all mean "compiler... I will be using a void pointer called ptr later in this program, blease pe aouair k thx."
>>
>>57660221
In a way, unavoidably 100% of the time because C#
>>
>>57660166
the correct way is to not use pointers, it's unsafe and a bad practice overall. use a language that doesn't have pointers instead, like javascript, or python.
>>
>>57661340
you can mix together both languages in the same sources without any specifiers to difference them and have it compiled with any C++ compiler.
Nothing wrong with saying C/C++, you're an overreacting faggot.
>>
>>57661795
>Vector newVector = vector1.dotProduct(vector2.horizontalAdd(vector3));
What's wrong with that? It's easy to read/understand.
>>
>>57660166
there the same
>>
>>57660726
>which is invalid
How so? Post increment post increment addition with b.
Result should be a+b+1. With a being assigned a+2.
Someone should fix whatever compiler you're using.
Thread posts: 143
Thread images: 5


[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y] [Search | Top | Home]

I'm aware that Imgur.com will stop allowing adult images since 15th of May. I'm taking actions to backup as much data as possible.
Read more on this topic here - https://archived.moe/talk/thread/1694/


If you need a post removed click on it's [Report] button and follow the instruction.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com.
If you like this website please support us by donating with Bitcoins at 16mKtbZiwW52BLkibtCr8jUg2KVUMTxVQ5
All trademarks and copyrights on this page are owned by their respective parties.
Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
This is a 4chan archive - all of the content originated from that site.
This means that RandomArchive shows their content, archived.
If you need information for a Poster - contact them.