Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

How to Improve C/C++

Name: Anonymous 2016-10-29 3:47

Just let p++ to be *p++. Its value never used other than with dereferencing. You won't see q = p++ in practice.

Name: Anonymous 2016-10-29 4:22

That's just plain inconsistent. Even if you don't increment a pointer, there are cases where pointer artihmetic is the only sensible option.

Name: Anonymous 2016-10-29 5:08

postincrementing

Summerscum spotted

Name: Anonymous 2016-10-29 7:04

what a fucking stupid fuck

Name: Anonymous 2016-10-29 14:21

>>2
Convenience is more important than consistency.

Name: Anonymous 2016-10-29 15:16

>>5
Consistency is a part of convenience. It's called 'Principle of least surprise'.

Name: Anonymous 2016-10-29 17:40

>>6
Convenience is relative. What is convenient for a professional is inconvenient for a newbie.

Name: Anonymous 2016-10-29 17:42

>>7
Which is why consistency is more important than convenience.

Name: Cudder !cXCudderUE 2016-10-29 17:52

You won't see q = p++ in practice
HIBT?

Name: Anonymous 2016-10-29 18:33

How to Improve C/C++
Add purity, lazy evaluation, monads and immutability.

Name: Anonymous 2016-10-29 18:42

whats a pointer

Name: Anonymous 2016-10-29 18:47

Real languages don't have pointers. They have references.

Name: Anonymous 2016-10-29 19:40

>>9
You got trolled by truth. Guess wind blowing and water flowing get you trolled too.

Name: Anonymous 2016-10-29 19:41

>>12

Java has iterators, which act like pointers.

Name: Anonymous 2016-10-29 20:09

>>14
Can you use iterators to swap two integers?

Name: Anonymous 2016-10-29 21:16

why is this stupid thread getting replies?

Name: Anonymous 2016-10-29 21:36

symbol $ is unused in C/C++. I propose to map $p to *p++. That will immediately improve readability and source code of typical C program like two times in size.

Name: Anonymous 2016-10-29 21:47

>>17
What about *++p, (*p)++, ++*p, *++p++, *p--, etc?

Name: Anonymous 2016-10-29 22:05

>>18

*p--
rarely used

*++p, (*p)++, ++*p, *++p++
almost never used and considered to be a bad practice.

Name: Anonymous 2016-10-29 22:59

>>16
I have to agree with you. This is really a non-issue.
If I were to ``fix'' C, such things would be the last I'd think of.

Name: Anonymous 2016-10-29 23:20

>>20

what would be the first?

Name: Anonymous 2016-10-29 23:52

Checkem!!!!!!!!!

Name: Anonymous 2016-10-30 2:34

>>21
Erase Seeples style comments. Enforce twos complement for signed integer encoding -- easily doable and might simplify conversion rules a lot.

Name: Anonymous 2016-10-30 3:39

>>23
Enforce twos complement for signed integer encoding
Ever seen CPU using other encoding?

Name: Anonymous 2016-10-30 3:52

>>24
No, that's why it would be so easy to fix and why it is so amazing that even C11 still supports sign+magnitude, one's complement and two's complement (§6.2.6.2). Ensuring two's complement would probably also fix other issues, e.g. undefined overflow behaviour (INT_MAX + 1).
I'm not even sure there are any IC-based CPUs at all that don't use two's complement, which makes it even more ridiculuos. We're talking about backwards support for tube-based machines here.

Name: Anonymous 2016-10-30 4:25

The problems with C/C++ are unfixable due standards and backward compatibility.

Name: Anonymous 2016-10-30 6:12

And those probelsm are...?

Name: Anonymous 2016-10-30 6:15

>>27
Mainly long compile times, poorly defined program behavior, ugly syntax, and lack of support for lazy evaluation and self-modifying code.

Name: Anonymous 2016-10-30 6:20

the real problem with C/C++ is undefined behavior, not this shit. boring C is the way

Name: Anonymous 2016-10-30 6:57

>>28
Dumb troll

Name: Anonymous 2016-10-30 10:26

>>27 Templates and reliance on template everywhere, the crippled and unintuitive operator overloading, no stabke ABI, no reflection, crippled and inefficient tuples, no native varargs(the equivalent is "template-based paramerer pack") despite RTTI, Standard Library bloat and cludges (EASTL exists for a reason), C++ being hard to parse and optimize itself.

Name: Anonymous 2016-10-30 11:09

Name: Anonymous 2016-10-30 11:42

>>19
and considered to be a bad practice
By you and only you.

Name: Anonymous 2016-10-30 22:07

>>33
Please don't use these forms and expect code to be comprehensible. You're not helping readability by being clever in the way you write your code.

Name: Cudder !cXCudderUE 2016-10-30 22:45

>>34
Bullshit!

It's not "being clever", it's called "using the language".

"readability" is in the eye of the reader. Maybe if YOU can't read the code, the problem is in YOUR head, you fucking illiterate retard!

Name: Anonymous 2016-10-30 23:53

>>35
I can very well read the code and know what its semantics are. Readable code is instantly recognizable to have a single meaning. If you have to interpret the meaning because it's not instantly obvious at first glance, then that code is a source of bugs. These are the tricks that people use to introduce backdoors by intentionally causing buffer overruns and it's not a practice that the secure code industry recommend.

Name: Anonymous 2016-10-31 13:35

>>36
It's instantly obvious if you know the language.

secure code industry
What?

Name: Anonymous 2016-10-31 13:36

*p++ is a bad practice because I say so even though no sane person agrees with me!

Name: Anonymous 2016-10-31 17:15

>>33
Try writing *++p++ in production code and enjoy being fired after the first review.

Name: Anonymous 2016-10-31 17:22

this is suc a shit thread full of fucking noobs

i wish /prog/ was good again

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List