[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vip /vp / vr / w / wg / wsg / wsr / x / y ] [Search | Home]
4Archive logo
what's wrong with c++?
If images are not shown try to refresh the page. If you like this website, please disable any AdBlock software!

You are currently reading a thread in /g/ - Technology

Thread replies: 337
Thread images: 9
File: programming.jpg (638 KB, 2192x1594) Image search: [iqdb] [SauceNao] [Google]
programming.jpg
638 KB, 2192x1594
what's wrong with c++?

pic unrelated
>>
>>43567271
Plenty. Unfortunately, it's the least wrong programming language we have.
>>
>>43567271
I dunno, what's wrong? I like it.
>>
wahhh pointers are too hard for me and i cant think of a meaningful criticism so i just say classes are bloat and claim that c is the master race even though i cant program in it ):
>>
File: 1407888117430.jpg (298 KB, 932x1388) Image search: [iqdb] [SauceNao] [Google]
1407888117430.jpg
298 KB, 932x1388
>>43567271
see >>43567292
All programming languages are shitty, but C++ and Python are the best you are going to get this decade, so learn em.
>>
>>43567317
kek right b4 me.
>>
File: codes.png (41 KB, 804x631) Image search: [iqdb] [SauceNao] [Google]
codes.png
41 KB, 804x631
java master race

>pic related, what I have to deal with
>>
>>43567348
>>>>>>>>>>>>>>python
>>
>>43567348
I made another language for the collection, is even more shitty hahahah:
https://github.com/elmeunick9/xirita
>>
>>43567379
java is great for making programs with an automatic garbage collector that does not work.

btw which text editor is that and what font
>>
>>43567388
>not embedding a lua terminal
>2014
>>
>>43567397
eclipse 4.4, ProggySZ
>>
>>43567271
that pic, while horrible, isn't even c++, it's c#. c++ code that does the same would look about 50 fold even worse structured
>>
>>43567423
ty
>>
>>43567384
You can have your opinions with Python, but it still makes it the most elegant and provides the most simple OO. The second part is good because complicated OO is what is harming us now. I think in order to improve we need to develop more simple abstractions so our solutions can be more elegant (aka not 1k SLOC of Java spaghetti code when it can be done in 100 lines of C) and Python supports that belief.
>>
i think c++ is a pretty good language, but imo there's some problems with it that make it a bad choice, especially for beginners
it basically boils down to it simply being too fucking huge. you can write c++ code for years without knowing even half the language. i mean, why the fuck are templates turing complete? it just leads to code that's hard to understand and maintain
>>
C++ is a terrible language, what the fuck are you all on about? C is great. C++ is C trying to be something it should never try to be, Java. And every other bloated [P]OOP language.

Everything you can write in C++ can be more succinctly written in C. OOP is the invention of business folk that need to continually tell each other that they're perfecting the engineering process. It's total bullshit, don't let anyone sell it to you. Observer pattern? Factory pattern? Blowjob pattern? All bullshit. A direct ticket to stack overflow, and I don't mean the website. Though I could, because every pattern is more difficult to understand than it needs to be.

What is the greatest operating system of all time?

Write small, testable functions. Complex functions should be small, and testable simply because they're made of calls to small and testable functions.

C++ is a perfectly fine language trying to keep with the fad. Don't bother with it. C is here to stay.
>>
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know anons jokingly said "C++ a great big shit!", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of shit that it's not even funny), inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your entire project. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C anyways. And limiting your project to C means that people don't screw that up in the first place, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" garbage. So I'm sorry, but where efficiency is a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.
>>
>>43567271
OO is shit.
>>
>>43568036
Wow, anybody likes OO xD. Well it's not like I understant it neither. Why I have to make a class that will have only one object, and that will declare only one object of another class? It happens a lot and its useless, it's fine to organize the project, but for that we already have namespaces, and for data we have structures... Or meybe it's me that don't know anything good XD
>>
#include <iostream>
int main ()
{
int* ptr;
int i = 5;
ptr = new int[i];
delete[] ptr;
}

Everything wrong with c++.txt
>>
>>43568744
Hey, how you put code in the comment?
And also, what's wrong with the code. Using a pointer to call allocated memory doesn't seems that bad.
>>
>what's wrong with c++?
It's a seriously complicated language with plenty of gotchas that will fuck you in the ass if you aren't careful. Unfortunately there are good reasons for both, and it still beats the alternatives.
>>
>>43567388
>https://github.com/elmeunick9/xirita
It's seriously like you mix up COBOL and assembly.
>>
>>43568813
[cod] (put code here) [/cod]

but spell code correctly
>>
>>43569032
test
>>
>>43567271
>uppercase method names
disgusting
>>
>>43568744
I'm guessing the issue is in
ptr = new int[i];
instead of
ptr = new int[*i];
?
>>
>>43567379
Please tell me this code was machine-generated, it hurts to think that interns don't get fired and actually go on to full-time work writing this sort of stuff
>>
>>43567379
aaaaaaaAAAAAAAAAAAAGGGGGGGGGGGGHHHHHHHHHHHHHHHHHH
AGH
UH
>>
>>43568744
>manual memory management
Into the trash it goes.
>>
nothing, retard
>>
>using c++
>managing your own memory
>literally reinventing the wheel with half the code you write
>>
>>43573444
Daily reminder that Stroustrup originally wanted to make Algol68 with Classes.
It would have had garbage collection instead of smart pointers and a real module system instead of include files.
>>
>>43572988
yes the code was obfuscated then I deobfuscated it and am in the process of refactoring it.

its a fucking 3d rasterizer and its a nightmare
>>
>>43568036

Can you use namespaces in C?

I like the OO aspect of C++. I think it makes things neat and easy to document.

In saying that though, I would have no problem with doing:

struct Person {
char *firstName;
char *lastName;
int age;
}

void commitSuicide(Person *person) {
// Blah blah blah
}


Instead of...

class Person {
char *firstName;
char *lastName;
int age;

void commitSuicide() {
// Blah blah blah
}
}


... so long as I could somehow group the commitSuicide function with Person somewhere in documentation.

Also, how could one do inheritance in C?
>>
>>43574082

Also, correct me if I'm wrong, but these two code samples would compile to, pretty much, the same thing, yeah?
>>
>>43574082
There are no namespaces and no real inheritance. Things like inheritance would be in conflict with C's nature. Namespace equivalents are like NS_function(), generally.
>>
>>43567271
>what's wrong with c++?
Peoples opinions on it.
>>
C++ is fine, it has problems (like every other language). You can use it as an enhanced version of C, or use objects as much as possible so it looks like Java, or anywhere in between
>>
>>43575367
>an enhanced version of C
>enhanced
>>
>>43567271
Nothing. It is an excellent language. To all the people who hate OOP. STFU unless you have a job where you program and don't use it.

I am not saying you cannot do this, but it would certainly sieve out the retard comments and maybe an actual discussion could happen.

I work in video games indusrty and OOP is right there in the heart of it.
>>
>>43567271
Nothing as such. It's usually a PEBCAK thing.
>>
>>43575528

> implying the video game industry isn't the most behind in development trends
>>
>>43575445
Yes enhanced you fucking autist, if you want you can write in pure C using a C++ compiler. But it has a lot more features than C, which you're not even forced to use. Can you tell me how that isn't enhanced?
>>
>>43575598
It's enhanced in the same way that your computer would be enhanced if you were to attach a fire hose to it.
>>
>>43575586
OFC. Rendering billions of vertices each with at least 128 bytes of information in a real time environment, while simulating weak AI and audio streamer and physics.

There are some bad games out there granted, but the industry is running the fucking show.
>>
>>43575622
I think a lot of stuff in C++ is quite handy eg Vectors. But I guess it boils down to opinion and what the program needs to do.

I'm sorry for calling you an autist
>>
>>43567317
ayyy but c has pointers too?
>>
>>43575643
That's okay, anon, it made me chuckle.
>>
>>43567379
>.anIntArray1671
how horrifying
>all those numbers
fucking why
>texturedTrianglePointsX
why not just go the entire fucking way and remove all the spaces (+ special characters) from the function documentations and set them as the function names?
>>
>>43575625

I'm not talking about performance or neat tricks you can do with your graphics cards, I'm talking about actual development.

I've never seen a game with any sort of automated testing system, proper support for i18n or debugging that's applicable to simulations.

Pretty much the solution to that is to have glitchy products and a QA team that slaves away doing what a computer should be doing.
>>
what's with all the hate towards OOP?

Do you just hate that some languages (like java) are stricter about making you put everything in its own class? Or am I missing something here?
>>
>>43575598
>it has more features therefore its good
until some fucking currynigger puts multidimensional external polymorphism or some arcane shit in your mainPipeline class for future refactor, yet instead it breaks everything (and I mean EVERYTHING) a few days in development later.
>>
>>43575682
Pretty much that. There's a lot more structure than plain C and many programmers don't like that structure. Yes Java is strictly OO and you should not use it if your specific problem isn't easily modelled into objects.
>>
>>43575682
People who don't agree that OOP is the be-all and end-all paradigm are labelled OOP haters by OOPfags.
>>
>>43575745
Personally, I just don't like half-assed paradigm implementations. Go all out or don't bother.
>>
>>43575655
>why not just go the entire fucking way and remove all the spaces (+ special characters) from the function documentations and set them as the function names?

the fuck do you think i'm doing? there is no documentation. the original names are unknown. thats why i'm re-factoring them......
>>
STL is shit. They fucked it up even more with C++11.
>>
>>43567379
This code looks pretty nice and organized, even though it has some inane variable naming
>>
>>43567379
It'd look 100x cleaner if the open curly brackets were on a new line
>>
>>43574082
>Also, how could one do inheritance in C?
vtables
>>
>>43575995
In C? Can you expand on that?
>>
>>43575643
Vectors are slow and bloated as fuck, don't use them, or C++.
>>
>>43576011
struct base {
int x, y;
int (*op)(int, int);
};

struct plus {
int x, y;
int (*op)(int, int);
};
struct mul {
int x, y;
int (*op)(int, int);
}

static int plus_op(int x, int y) { return x + y; }
void *new_plus(int x, int y) {
struct plus *p = malloc(sizeof(*plus));
p->x = x;
p->y = y;
p->op = plus_op;
}

int do_op(struct base *b)
{
return b->op(b->x, b->y);
}

struct base *b = new_plus(5, 7);
int z = do_op(b);
>>
>>43576034
>Vectors are slow and bloated as fuck
Compared to what?
std::vector and raw arrays generate identical machine code when traversing them.
>>
>>43576083
Inheritance is a LANGUAGE feature. You just IMPLEMENTED it - but the language still doesn't natively support it.

You can implement closures in x86 assembly - but that doesn't mean that your processor supports functional programming.

And also that is horrible
>>
>>43576101
>Inheritance is a LANGUAGE feature.
No, it's a concept.
>>
>>43567271
nothing is wrong with c++. People who dislike it and say it's outdated simply do not know what they are talking about. It is almost impossible to find a operative system that does not contain c++ code
>>
>>43576034
In modern languages raw arrays shouldn't even exist for that purpose.

They are the best structure for abstracting computer memory, but that doesn't mean you should use them as containers in logic code.

Using vectors means that you cannot commit mistakes such as with arrays.

If I ever saw you using them, you'd get fired. Why do you think security vulnerabilities exist? Because arrays forget their size. Almost all serious vulns are because someone used C-style code where he shouldn't have.
>>
>>43576109
Actually, since words have multiple meanings, it is *also* a concept, not exclusively.
>>
>>43576109
features are concepts
>>
>>43571095
dank maymay
>>
The problem is that people think that they can just pick up one language and use it for everything, because it is "the best".

Wrong. Languages are tools. You wouldn't write your hip new app in C++ because that would be a retarded waste of resources.

But you wouldn't write a complex embedded system that benefitted from OOP abstractions but where performance was critical in them either - you'd have to choose a language with good performance and access to low-level machine features.

That said, even Stroustrup admits C++ has acquired a lot of "barnacles". The CONCEPT of a low-level, performant language with powerful abstraction features was a revolutionary idea that will live on, but C compatibility and base model are holding it back. Also the syntax is plain horrid.

That's why I'm excited about languages like Rust, Go, and (less so) D. All the benefits of C++, with added safety, even better abstractions (mostly from functional programming), and much better syntax.
>>
>>43568036

C is just C++ with significantly less features. No RAII, no templates, no anonymous functions. You say everything that one can write in C++ can be written more succinctly in C? How about a function that takes in any unary function and any collection as an argument, and either applies the unary function in place to the structure or applies it to a copy of that structure. In other words, write Scheme's map function in C, and write it more succinctly than a C++ equivalent would be.

>>43576034

Care to show a better implementation of a dynamic array than what is provided by the STL?
>>
File: uriel.png (2 MB, 1440x1681) Image search: [iqdb] [SauceNao] [Google]
uriel.png
2 MB, 1440x1681
Was he right, /g/?

What do you think of Go, Limbo and Rust?
>>
>high enough to be bloated
>not high enough to have significant abstraction when coding
>shit tier syntax
>shit tier creator
>shit tier Qt
>shit tier name
>shit tier programmers
>>
>>43576172
/thread
>>
>>43568036
>Everything you can write in C++ can be more succinctly written in C.
Thread and memory safe cache in C++, lets see the C version.
shared_ptr<widget> get_widget(int id)
{
static map<int, weak_ptr<widget>> cache;
static mutex m;
lock_guard<mutex> lock(m);
auto sp = cache[id].lock();
if (!sp)
cache[id] = sp = load_widget(id);
return sp;
}
>>
>>43567271
It's the fastest OOP language.
>>
>>43576204
He was right. He considered Uriel harmful so he did the logical thing to fix it.
>>
>>43576204
That image is harmful.
>>
>>43574082
#define :: _NAMESPACE_

and enjoy your namespaces.
>>
>>43576323
Not a legal preprocessor symbol, but even if it was it doesn't do the same thing as c++ namespaces.
The deal with namespaces isn't the name prefix, it's the ability to import them into other namespaces, dropping the suffix or giving another alias for it.
>>
>>43568036
>Everything you can write in C++ can be more succinctly written in C.

here is a basic example of generic programming.

template<typename T>
void swap(T& a, T& b)
{
T temp = b;
b = a;
a = temp;
}


how do you write this more succinctly in c?
>>
>>43573523
>a real module system instead of include files.

can someone explain how this works? i only have experience with c.
>>
>>43576372
Not going to happen more succinctly in C. Generic programming is far easier in C++. IMO, if you need that level of flexibility, you may as well use a language like Scheme.
>>
>>43572960
>dereferencing an integer

u wot
>>
>>43576402
import std.io

benefits:

- not local, i.e. you can't fuck it up by ordering your includes differently

- faster compilation times, compiler inspects type metadata in object files for example

- MUCH easier to work with. No need to maintain additional header files just to get the compilation to work - compiler technology is lightyears away from that

- just more logical, the C preprocessor is the worst feature ever

- proper namespaces / packages (the current ones are a joke honestly, other languages have it much better)
>>
>>43576510
- modular imports, just import one function / class you need, and make it explicit

here's some docs: http://clang.llvm.org/docs/Modules.html

I hope GCC catches on, although they are working on interesting stuff as well.
>>
/g/
what book would you suggest for learning algorithms in c?

Im looking for basic like implementing stack to more complicated
>>
>>43576034
>Vectors are slow and bloated as fuck

wow, a c++ hater that doesn't know what the fuck he's talking about. shocking.
>>
>>43576738
Algorithms in C
>>
>>43567379
>2014
>still fucking around with Runescape shit

It's over anon. Give up.
>>
>>43576034
>slow and bloated as fuck
lel
>>
Preprocessor. Context dependency - order of declaration of functions or prototypes. No single root type system.
The worst part sepples coders' code and habits depend on it and it's better to just scrap the whole thing.
>>
>>43567271
It's object-oriented
>>
>>43578193
Isnt that minecraft? lol because x,z,y models (blocks) not sure thought
>>
The standard library contains lots of deprecated stuff.

raw pointers are still a thing even though there's no reason to use them anymore thanks to unique (and shared) pointers.
>>
>>43567271
>Console.Writeline

Damn right pic unrelated
>>
The problem with C++ is that it isn't a Lisp dialect.
>>
File: 1402740990468.png (224 KB, 720x400) Image search: [iqdb] [SauceNao] [Google]
1402740990468.png
224 KB, 720x400
>>43567379

go home, notch, you're drunk
>>
>>43580257
I can't believe that was actually the name of a Dragonball Z episode.
>>
>>43576172

>muh middle ground fallacy

There's ALWAYS a best option adn it's NEVER C++. The best option 9/10 times is ALWAYS C (the other 1 time is when you just need a bash or a perl script written)
>>
>>43580641
k tard

You don't have any fizzbuzz to write?
>>
>>43581057

Don't you have some ENTERPRISE(tm) level software to write? Let me know when you're done with your pointless and bloat filled abstractions.
>>
>>43581095
Abstractions are good, the problem with most C NEETs is that they never need them for they toy projects and C is really bad at abstraction so they think it's a bad thing
>>
https://code.google.com/p/v8/source/browse/branches/3.0/src/api.cc

C++, not even once
>>
>>43581129

>C
>only good for toy projects

I guess the majority of software used by corporations all over, linux being the biggest one, is just a bunch of toys banged out by le NEETs.

GB2 /leddit/ with your bullshit and comeback when you actually grow the fuck up.
>>
>>43581185
>most
>>
>>43581290

>B-b-but not EVERY C coder is a silly poopie head NEET, just most of them I am so smrt lel he is so butthurt :^)
>>
>>43568036
>C++ is C trying to be something it should never try to be, Java
C++ existed long before Java and it never tried to be Java. You should sometimes watch a presentation by Stroustrup he usually explains the real concepts behind C++ which someone who grew up on Java/C# probably wouldn't ever thought of.
>OOP is the invention of business folk that need to continually tell each other that they're perfecting the engineering process.
You don't know what OOP is. Take a look at smalltalk appeared in 1972.
>Observer pattern? Factory pattern? Blowjob pattern? All bullshit.
No one said you should use those without any reason even in OOP. Putting patterns together like a retard is not OOP nor programming.
A simple C++ class is simply syntactic sugar for a function operating on a struct.
Nice b8 though.
>>43568378
Nice b8 and Linus copy-paste.
Also, C++ is not strictly OOP.
>>
>>43581309
If you read my post carefully, you will realize it refers to "most needs that use C [...]" rather than "all C programmers which are all NEETs"

You should definitely improve your reading comprehension
>>
>>43581342

If you're trying to analbast every C programmer you're not doing a very good job. Simply put C > C++ for all cases and you haven't put any good evidence for your side of the argument other than lel NEETs.
>>
>>43581381
I'm tired of discussing with them. I can provide arguments (I've done so many times), but seeing that you can't even understand my comment I don't think you are prepared to talk about how namespaces, templates or RAII.
>>
>>43581428
>namespaces, templates or RAII.

Unnecessary bloat
>>
>>43576083
Are you purposefully re-implement what's already in C++?
>>
>>43581448
>hurr everything C can't do is bloat

You consider the preprocessor and array indexing sugar bloat too, right?
>>
>>43567455
>elegant
>whitespace significant

pick one
>>
>>43581457

consider there are faster and more efficient way of doing it, yes.
>>
>>43581448
Top kek. Not knowing what namespaces or templates or RAII are.
None of them are bloat. In face they you probably do the RAII equvivalent in C without knowing what it is. Templates are no bloat because they are compile-time code generation. It generates what you would write yourself in C.
Someone with your mindset should only program in assembly. Anything other than assembly is bloat.
>>
>>43581493

C is portable assembly, so writing C is writing assembly :^)
>>
>>43581493
Assembly is bloat anon, write machine code
>>
>>43581508
Machine code is bloat. Write HDL for custom ASICs.
>>
>>43581506
But it's too bloated!444 I can write that in pure assembly I don't need one moar layer! :-)
>>43581508
Hehe. I can imagine there are people who actually believe this.
>>
>>43581540

I don't get why people are so worried about bloat. It's like all they've used is Firefox/Chrome with 20-30 tabs and they're shocked that it uses up a bit of memory.
>>
>>43581575
Most of them think that any kind of even minimal bloat is the end of the world. Some of them also think that there is bloat where in fact there is no bloat. :-)
Actually it depends on what you develop, but you always need to make a compromise. Development speed, the ability to make certain abstractions easily, being able to manage complexity rather easily are all important factors so you won't shit bricks.
This only gets worse when they don't what they are talking about. Usually this is only 80-90% percent of a general /g/ thread if you are lucky.
>>
>>43568744
C++ RAII model explicitly avoids manual memory management. This is everything wrong with c
>>
>>43581381
If you're working with professionals, there's absolutely no reason to use the lesser language. C++ gives you more tools and allows metaprogramming with no downsides. You can still write the same C code in C++, barring some very minor differences.

The only reason to use C over C++ is if you don't understand C++ (which honestly isn't something to be ashamed of, as it's a very difficult language) or if you otherwise can't keep yourself or others from using some of its undesired features or idioms.
>>
>>43581633

Also I think they're shocked that a non trivial program uses 500MB of storage space when the average HD has terabyes of space. Even some shitty laptop has 500GB of hard drive space.
>>
>>43581655
>This is everything wrong with c

Ignoring the preprocessor, treating pointers and arrays as being completely interchangeable for exploit nirvana, making pointer declarations identical to pointer dereferencing for some reason, ...
>>
>>43581824
>pointer declarations identical to pointer dereferencing for some reason
what the ... C purists are this stupid?

This isn't C, you don't need to declare every variable before you use it, and I find it the most humorous that you included <iostream> and you never used it. First learn to code before you speak.
>>
>>43582168
Not a C purist, read the comment again.

/* making '*' part of the declaration and not part of the
type itself is retarded. Using the identical syntax
for the declaration and dereferencing is not as
clever as the language designers thought. */
void foo(char *c) {
char *d = '?';
int *x, *y, *z; /* this was a bad idea. */
int a[1] = 99; /* seriously, fuck this too. */
*c = *d;
}
>>
>>43580042
It's possible he's on the Forge team.
>>
>>43581720
If it's easier to make that program and/or they can make it better by using a little more disk space and there's no disadvantage other than that little disk space they should do that if they want to.
However unnecessary mindless bloating is something I don't like either, but since you said non-trivial programs I can agree in most cases.
>>
>>43572960

This doesn't make sense.

Anyway, I'd just like to say that C++ is the "natural progression" of C, in terms of organization. OOP is necessary for building modular and scalable code, and the C++ implementation is an excellent starting point for that.

I've been developing in C for years, and my job is mostly focused on C, but in most cases, I would choose C++ if I could.
>>
>>43576034

Actually, vectors may be referenced like an array. The assembly behind it is similar to that of a C array (relative offset). Every time you resize the array, however, that array structure must be reallocated and all data copied. So when you use a vector, make sure to predict it's maximum capacity, to avoid the need of resizing.
>>
>>43582404

char *d = '?'; is illegal. Single quotes is a constant. Double quotes is a pointer to a constant. Assigning a pointer to point to a constant does not make sense, and it will not compile.
>>
>>43567348
>python
>>
>>43582404
[Me] Okay, I agree with you on the
int *x, *y, *z;

You should be able to write it
int* x,y,z;

As for this
int a[10] = {0};

It should be
int[10] a = {0};


So that the array (or pointer) is attached to the type and not the variable thus you can declare multiple variables of the same type with ease without redundant code.
>>
>>43567379
Model.anIntArray171234923749[i_43456_++] = Kappa;
>>
>>43567379
My brain hurts looking at that shit.
>>
>>43583210

You do realize that you can do smth like:

typedef char *PCHAR;
PCHAR x, y, z;

Also the [10] is not a property of int, it's a property of a. A datatype is not the same thing as an array of that same type. That's why int[10] a; is garbage syntax.
>>
>>43582874
>char *d = '?'; is illegal
yeah, and the "int a[1] = 99" was fucked up too, whoops

horrible mistakes aside, the notion that pointer/array declaration syntax should exactly match dereferencing/indexing operation is not completely intuitive when examined from a distance
>>
>>43583909

How so? When you declare a type, you declare it as a pointer to a type - using * as a symbol for pointer makes sense to me. When you dereference that pointer, you know (by deduction) that it is not a declaration. If you declare and initialize in the same line, then you know that you are initializing the pointer. It's pretty logical and efficient to me.
>>
>>43567379
what the h#ck is going on in this picture
>>
>>43567271
That's Java you fucktard.
>>
>>43583779
I'm trying to argue the standards of the language buddyboo

>[10] is not a property of int
that's the problem buddyboo

>>43583981
int** p;

What does this read?
It is not consistent at all

>>43584054
>pic unrelated
how does it feel to be retarded and project it?
>>
>>43584144
I think of it as, ptr<ptr<int>>. Now replace ptr<T> with T*
>>
>>43584054
>Console.WriteLine
>Java
>>
>>43584144

An array is not a datatype. An array is an array of the same type. Therefore, int[10] a; doesn't make sense. Do we need a datatype for int[n], then? Think about how stupid/confusing that would be for someone trying to learn the language. Or how confusing it would be for someone trying to actually code in it.

int** p; is declaring a double-pointer, p. int** p, a; is declaring a double-pointer-p, and declaring an integer a;, which makes sense because int** is not a datatype.

If you want to make your own datatypes, you can using type definitions. I just think that the most elementary types need to be apart of a language, everything else is not necessary for all applications.
>>
>>43583779
>Also the [10] is not a property of int, it's a property of a. A datatype is not the same thing as an array of that same type.

The syntax is consistent with C's ideas of pointers and arrays, but the design choice of having array sizes always being only dynamically state instead of static type is not without tradeoffs.

It's a pure loss in safety and utility for cases where buffer sizes are statically determined.
>>
>>43582404
Compare Algol 68's mode declaration and procedure type syntax to C's typedef and function pointer syntax.
mode m1 = ref int,
m2 = [1]int,
m3 = proc(int)proc(int,[]proc([]int)int)int;
(ref int x, y, z;
[1]int a := 99;
proc(int)proc(int,[]proc([]int)int)int p, q;
~);
(m1 x, y, z;
m2 a := 99;
m3 p, q;
~)
>>
>>43567271
Nothing. Best compiled Language IMO. I also like Lua and bash.
>>
>>43584263

What exactly do you mean by array sizes being "only dynamically state?"

As far as I know, declaring int a[10] declares an array of 10 integers, or 40 bytes statically.

If you need a dynamically-expanding buffer, then you need to pull it from heap memory. If you need a static buffer, then that should be determined compile time, and stored in run-time in a statically determined buffer.

I imagine you're worried about overflowing a statically defined buffer. That's fine, but "buffer overflows" are not a property of the syntax, or design, but rather the carelessness of the programmer.

Unfortunately for programmers, computer memory is not a magically infinite resource. You may not care about it when writing Java, but you sure as hell need to know it when you're designing something serious.
>>
>>43584255
I disagree. Pointers and arrays should be considered type-level functions (if C had this concept).

[/code]
Array :: Nat -> * -> *
Pointer :: * -> *
[/code]

So that applying Array to 3 and int, you get the type "array of 3 ints". Applying Pointer to int you get a pointer to an int, and the same if you apply Pointer to Pointer(int). There's no need to hardcode these concepts as "variable modifiers". They are just generic types, and the dereference/indexing syntax is just another operator like (+) (do you declare integers with + or -?), it doesn't even need to be the same syntax (perhaps only for the mnemonics).
>>
>>43584255
>An array is not a datatype. An array is an array of the same type.

It's perverse to think of memory layout being determined by object state instead of static type:

struct foo {
foo *a;
int b[4];
char c;
};


Requiring lengths to be statically available to the compiler but in no treating it as static type information that could be used for safety, etc., is bizarre. (Yes, I'm ignoring C99 VLAs)
>>
>>43584492

A data type is a container that is interpreted in a unique way. For example a char is 1 byte in size. An int is 4 bytes in size, and meant to store a number. But also, a data type defines the types of operations that can be performed on that type, the meaning of the data, and the type of storage.

Accordingly to *that* definition (as per wikipedia), it makes sense that a pointer to a datatype is a type "pointer", not "pointer to datatype". If that's the case, then it is necessary to use modifiers for elementary types.

Think about how infinitely many combinations of data types there would be, if a data type was defined as being both a type, and a modifier of that type.

C emphasizes that concept, and its syntax is reflective of it.

Also "generic" types are defined compile-time. For example, using a template in C++ isn't *exactly* a generic type - it's explicit. Otherwise the compiler wouldn't know how to treat that type. Generic programming works, but only if you understand *why* it works.
>>
>>43584404
C is not strongly typed enough to give you out of range errors, which could fix many mistakes because a standard encourage compilers to be intelligent enough to fix _obvious_ mistakes humans will always make.
// gcc test.c -o test
#include "stdio.h"
int main()
{
int a[5] = {0};
printf("%i, %i\n", a[4], a[5]);
}

Output: 0, 32767

>>43584492
Yes, this makes the most sense and allows you to declare multiple variables of a specific type without redundant code (typedefs make me puke) but C has no templates to implement this. In the future buddyboo.
>>
>>43584492
That would be a very anti-C language.
>>
>>43584640

Why on *earth* would I want a computer to fix my errors?

>>43584541

This isn't clear to me. If the processor interprets int a[10] as an array of 10 integers in size, or 40 bytes, then how could this affect safety?

Furthermore, even in Java, the program has statically-defined memory (stack), and dynamically expanding memory (heap). Just because you don't worry about memory in Java doesn't mean memory is pulled out of Stallman's ass.
>>
>>what's wrong with c++?

int x = 1+1;


x might not be 2 after executing that.
>>
>>43584720
>Why on *earth* would I want a computer to fix my errors
the compiler wouldn't be "fixing" your errors without your knowledge, they would be telling you your program has a buffer overflow if you overlook it. You could always ignore the warning, but if I get no warning, then now the _compiler_ is overlooking an obvious error which should be checked at compile time (if you aren't accessing a variable within its array bounds).

>>43584772
What compiler?
/* g++ test.cpp -o test */
#include <cstdio>
int main()
{
int x = 1+1;
printf("%i\n", x);
}

Output: 2
>>
>>43584824

Only new compilers warn you of using unsafe functions that may result in a buffer overflow. Clearly the amount of shit programmers out there necessitated that need.
>>
>>43584824
I'm referring to operator overloading
>>
>>43584824

Also a compiler would not know if a buffer overflow would happen. Buffer overflows occur in runtime, generally due to some kind of input that is not properly stored. This is not a problem with C, but yet again, with shit programmers. Simply using Java does not make this problem go away. Java is not magic. It follows the same rules of computing as any other language. Just because your Java interpreter is well-designed doesn't mean there aren't bugs in it.
>>
>>43584870
>shit programmers
It's not really about being a shitty programmer or not, all humans will make mistakes in their lifetimes and if you are working on a large scale project you could overlook a buffer overflow. The worst case scenario of having out of bounds checking is you never get the warning, which means you are a perfect C purist programmer congratulations!

>>43584919
You are adding two integers, this has nothing to do with operator overloading
>>
>>43584919

'1', and '1', are constants, and since they are not typecasted, we know that they are both type ints. The operation '+' would always be integer addition, and it would always output integer 2. I don't see any mention of operator overloading in that statement.
>>
>>43567424
So C# and Java are more or less identical?
>>
>>43584949

I don't know what a purist C programmer is. I always figured everyone would know how to write C perfectly. How people manage to code serious projects in Java, without knowing C, is beyond me.
>>
>>43584637
>Accordingly to *that* definition (as per wikipedia), it makes sense that a pointer to a datatype is a type "pointer", not "pointer to datatype". If that's the case, then it is necessary to use modifiers for elementary types.
Wrong. A pointer to struct S1 is not a pointer to struct S2.
struct S1* and struct S2* are different results of the applications of the Pointer type function (it is injective)

>Think about how infinitely many combinations of data types there would be, if a data type was defined as being both a type, and a modifier of that type.
The compiler is perfectly capable of representing that if there are others with dependent types and impredicative polymorphism

>Also "generic" types are defined compile-time. For example, using a template in C++ isn't *exactly* a generic type - it's explicit.
There are two main implementations of generics. Specialization and boxing with erasure and dictionary passing. For example, Haskell uses the second one but when it's possible it uses the former because it's way more efficient
>>
c++11 is mostly fine, stop your bitching. c++14 will add "concepts lite" and fix some annoyances in STL, and when we finally see a first version of modules in c++17/20, the language is going to be really really decent.

Honestly, what's your alternative? C#/Java are bloated as shit, C is hardly as productive for application development (rather than system development), and stuff like D, Go, and rust are just not ready yet.
>>
>>43584263
You want static array sizes?
#typedef char buf_t[1024]
or something

Okay, so it won't check for buffer overrun, but you can't accidentally pass a char[512] instead, and I think that's enough
>>
>>43584669
The C type system is a joke
>>
Every time I read some spec from the new C++11 I feel proud to be a C++ programmer.

Such good designed specs. Some of the most horrible things came from C for sure (like time_t not being required to be in UTC).
>>
>>43585077
>you can't accidentally pass a char[512] instead
actually you can, and you won't see as much as a warning on most compilers. Arrays are not a part of C/C++'s type system. They decay into a raw pointer when you do anything with them (passing as a parameter included)
>>
>>43584720
I'm not a fan of Java et al., but I don't consider C flawless either.

It seems very wasteful to me that the compiler uses array lengths (which as you say it rightfully requires) for layout and then discards the information forevermore afterwards.

Since it's not possible in C to make functions that accept proper arrays, and since pointers aren't actually address/length tuples, buffer length must determined by in-band signaling (i.e., null termination) or passing explicit length parameters.
Both of these options suck and have caused umpteen bazillion code flaws over the decades.

Pointer/array complete equivalence probably seemed like a great trick at the time, but it has always been shit.
>>
>>43585089
Pretty much every bad aspect of C++ is due to backwards-compatibility with C
>>
>>43585112
Last time I checked, I got a compile error with something like
int myFunc(buf_t b);
char t[500];
myFunc(t);

But my memory may be playing tricks on me
>>
>>43585065
>Wrong. A pointer to struct S1 is not a pointer to struct S2.

Not explicitly. You can, however, type cast a pointer to point to any data. This means that a pointer to S1 *can* be a pointer to S2. I can't imagine how you process the existence of a void pointer.

>The compiler is perfectly capable of representing that if there are others with dependent types and impredicative polymorphism

The compiler can do anything you want. It can compile a turd, so long as you make it valid. Ask yourself what a data type is, and why it does not make sense for an array of those types to be a type in itself.

>There are two main implementations of generics.

Call it what you want. A computer *must* know what kind of data it is processing. A compiler must know what to do with the generic data. In C++, a generic type is always determined statically. How else would a computer know which implementation to choose?
>>
>>43567271
>what's wrong with c++?
C++ is a little incomplete and the development around the standard is too slow.

but that is the price you have to pay to create a well designed spec
>>
>>43585112
>>43585159
Just tested it. You (first poster) are quite right, which means I (second poster) am very confused.
Because I swear this happened to me once...
>>
>>43585123

My point is that C is simple. Its datatypes are simple. Its modifiers are simple. The combinations of those produce expected assembly.

>Since it's not possible in C to make functions that accept proper arrays

"Accept" as in a parameter that is an array? Sure it does.

>and since pointers aren't actually address/length tuples

Why would a pointer need to be an address/length tuple? Length of the pointer? That depends on architecture, let the compiler worry about that. Length of the data it is pointing to? But that's explicit in the code itself.
>>
>>43585237
Don't sweat it, I was pretty surprised at first too. Arrays are a very ugly hack in C, due to historic reasons relating to C's forefathers - BCPL & B. If you're in for an history lesson: http://cm.bell-labs.com/who/dmr/chist.html

Anyhow, it's a shame it can't be fixed without breaking backwards-compatibility, it's one hell of an ugly scar that we've been stuck with for nearly 50 years.
>>
>>43585185
>You can, however, type cast a pointer to point to any data.
The number of casts required to perform a task represents how shitty a language is.

>I can't imagine how you process the existence of a void pointer.
I don't use it. Never

>Ask yourself what a data type is, and why it does not make sense for an array of those types to be a type in itself.
It does make sense. In fact there's a STL type that does exactly that (std::array)

>A compiler must know what to do with the generic data. In C++, a generic type is always determined statically. How else would a computer know which implementation to choose?
As I said, Haskell uses dictionary passing and specializes as an optimization. I know this isn't viable in C, but I dont see the problem with the C++ approach (in fact I never use raw C arrays and go with either std::vector or std::array)
>>
>>43585055
>I always figured everyone would know how to write C perfectly.
Dr. Henson? Is that you?
>>
>>43581467
>Haskell
>>
>>43585324
>The number of casts required to perform a task represents how shitty a language is.
It's required for interfacing with hardware, when implementing memory allocators, dynamic loading and for various efficiency tricks.
>>
>>43585361
Think about it. Is that too high of a demand? C is syntactically simple. Hell, it's the *easiest* syntax to learn. Learning how a computer processes data, on the other hand, takes lots of effort to learn. This is why C should be taught in schools. It teaches you how a computer works. High level languages obfuscate the complexity of a computer, something that every computer programmer should know.
>>
>>43585085
C's type system is bytes and contiguous groups of bytes. It's all you need to make a kernel on PDP-11-like hardware or to create applications that run in kernel mode and access memory-mapped I/O and structures at specific addresses.
If you're using it for anything else, you're using it wrong.
>>
>>43585394
>It's required for interfacing with hardware, when implementing memory allocators, dynamic loading
Those are very specific uses, it's fine there. However, it's not okay to cast stuff away in most (not-so-low-level) tasks

>and for various efficiency tricks.
Not really if the design is good
>>
>>43567271
// test_lang_status.cpp
#include <cassert>
int main() {
const int shit = 0;
int c = 0;
assert(c == shit);
assert(c++ != shit);
return 0;
}
>>
>>43585464
Hear hear! This is why I love C - It's awful to write anything particularly large in, but for the low-level stuff it gives you such a great insight.
>>
>>43585324

>The number of casts required to perform a task represents how shitty a language is.

I get the feeling you were trying to make a point.

>I don't use it. Never

But I'm asking you what kind of a type is a void pointer. Is void a datatype?

>It does make sense. In fact there's a STL type that does exactly that (std::array)

std::array is a container template. You must specify datatype when you initialize an std::array.

Just a side note: Generic programming is not as 'generic' as one may think. A template initialized as char uses a different implementation than a template initialized by an int. This must be known compile-time.
>>
>>43585476
I agree. The problem is that there's too much people here advocating C for any task
>>
>>43585499

But the Linux kernel is written in C. AFAIK, Linus Torvalds *hates* people muttering C++, especially for something like the kernel.

It demands patience, knowledge and skill. Try writing something serious in Java, I dare you.
>>
>>43585488
>Not really if the design is good
You can't implement a fast memcpy() without type punning, can't align things without being able to do integer arithmetic on them, can't extract mantissas and exponents out of a float without reinterpreting the bits, can't do efficient I/O without being able to to widen reads and writes to form word size chunks.
>>
>>43576372
with macro functions and void pointers
>>
>>43567271
It's too hard for the dipshits who criticize it
>>
>>43585542
>I get the feeling you were trying to make a point.
Kinda. Type systems can do a lot more than just telling you that a long doesn't fit into a char

>But I'm asking you what kind of a type is a void pointer. Is void a datatype?
No it isn't in C. Allowing a poimter to it is just an ugly hack to have a way to represent "pointer to anything" because it doesn't make sense to have a pointer to nothing, so they used it for this instead of the usual meaning

>std::array is a container template. You must specify datatype when you initialize an std::array.
>Just a side note: Generic programming is not as 'generic' as one may think. A template initialized as char uses a different implementation than a template initialized by an int. This must be known compile-time.
Just stop thinking about bytes and CPU cycles for a second. In C++ you can refer to the vector type template without any argument (higher kinded type), but obvioisly you can't instantiate it (just like you can't use the result of a function without providong arguments. Functions are a very useful abstraction mechanism, and they are about the same thing as generics (effectively they are, C++ templates are turing complete)
>>
Is Rust the current best systems-level programming language, /g/, or is it still C?
>>
>>43585739
nice bait
>>
>>43585646
Again, those are very low level primitives that the common programmer doesn't use too often
>>
>>43585721
>Kinda. Type systems can do a lot more than just telling you that a long doesn't fit into a char
Pretty sure the compiler would warn you if you tried to do that. Even in C.

>No it isn't in C
But doesn't that imply that a pointer is a type itself? Also, not just in C, but I don't think void is a type at all. It can't be. It doesn't have the properties of a type.

>Just stop thinking about bytes and CPU cycles for a second.
No, you can't instantiate an std::vector, because it's a container, and not a type. Functions aren't generic - they're explicit. I'm just saying that "generic" programming doesn't really exist. Also, C is sufficiently/necessarily typed. C++ is strongly typed, and it has the option of 'generics,' but those must be explicit when allocating memory.
>>
>>43585270
>"Accept" as in a parameter that is an array? Sure it does.

You can say
void foo(char *a, int l);
or
void foo(char a[], int l);
, but it's really just passing a pointer with a decoupled length.

Something like this might compile but is horribly misleading:
char const n[] = "whatever";
int nl = sizeof(n); /* 9 bytes, because why not chose null termination? */

void bar(char b[42]) {
int x = sizeof(b); /* sizeof(char *), not 42. */
}


If passing like
void baz(int b[]);
passed a hidden length parameter that could be accessed by the function body via
sizeof(b);
, a lot more folks would be happy.
Having this with an explicit pointer+length -> array conversion builtin that could be used where needed would be preferable to what we got IMO.
>>
>>43576083
>look mom I'm reinventing the wheel
>>
>>43585835
Goddammit anon, read the whole thing before posting. You are just rephrasing what I said
>>
>>43576083
You didn't even reinvent the wheel correctly, like most C purists. void* new_plus doesn't return anything so struct base *b isn't being assigned anything.
>>
>>43585857

I think that's because sizeof(n) is a macro, it's a constant and not processed runtime. It's meant to be easier to write. Besides, when you initialize n as being 9 bytes in size (accordingly to the declaration), that won't change. So it doesn't matter what n contains, it will always be 9 bytes in size.

However, since b is a parameter, it hasn't been initialized in compile-time, so sizeof(b) is 4, or rather the size of the pointer type b.

Also, it's 9 because it included the null terminator.
>>
>>43585970
You missed the point.
>>
>>43585863
My bad. Must've confused you for the guy who said that "pointer to an array of 40 characters" should be treated as a datatype. That's what I get for taking too much xanax - can't remember shit.
>>
>>43586073
Must of been a terrible point
>>
>>43582404
Read the Unreal Engine coding style guide. Using
char* d

Is prefered because now you can grep your code easily for all char pointers. Grepping for 'char *' only works if you always leave one space between char and the asterisk.

Lots of people do shit like this though:
int  * big;
double butts;
>>
>>43586009
>I think that's because sizeof(n) is a macro
The term macro in this context refers only to the preprocessor, while sizeof() is a builtin operator keyword handled by the compiler proper.

>>43586009
>However, since b is a parameter, it hasn't been initialized in compile-time, so sizeof(b) is 4, or rather the size of the pointer type b.
I was arguing that the semantics of sizeof() could be modified for the case of function array parameters to do what I'm saying, not what it does in reality.
This could be done semantically consistently with the language I believe.

>Also, it's 9 because it included the null terminator.
No shit. I was just making a jab at C strings with in-band length handling.
>>
>>43586106
I'm that guy (the Array and Pointer function thing). The point is that an array of 40 chars and an array of 41 chars should have different types (at most perhaps some kind of subtyping). Also please re-read my last post, it contains some interesting (IMO) insight
>>
>>43585769
But they are necessary for fast system such as kernals
>>
I want to know what I can supplement with my PLSQL career. I don't care about compatibility between the two, just wanna do some real programming!
>>
>>43586173
sizeof() computes the size of the data type. As the size of a data type cannot change in run-time, I treat sizeof as a macro. It is a constant value, generated by the compiler (and true, not the preprocessor). Changing the contents of a data type will never change its type size, unless its recompiled.

>This could be done semantically consistently with the language I believe.
Type Pointers and arrays are closely related, and they are interchangable through type casting. Also, I'm not sure why passing an array as a parameter is legal - I guess to confuse comp sci students. Either you pass by value, or pass by pointer. "Passing an array" is passing a pointer. That's why its size is the size of a pointer.

>No shit. I was just making a jab at C strings with in-band length handling.
I don't see your point. I don't agree with it, but it's there to make it appear simpler for CS hipsters. You know, make it more like Java.
>>
>>43567271
>what's wrong with c++?

Keeping backwards compatibility with C was a Faustian bargain.

It would almost certainly not be as successful had it not built off C, but the shit it kept is awful.

Foremost: the preprocessor and pointer/array equivalence.
Honorable mentions: operator pre/post/in-fix variations and precedence nightmare, and that null pointer handling is a language Pattern/Idiom, not part of the type system.
>>
>>43586164
Just use fucking regex retard.
char \**
>>
>>43586365
C's const and "ANSI-style" prototypes were backported from C++. Pre-C++ C was even more barbaric than it is now.
>>
are any of yall good with the computers and stuff (duh) lol i could use some help please :) if you dont mind please :(
>>
>>43586365
I Consider an array like a pointer with an offset. If you look at the assembly, the processor treats an array like a pointer, computed with an offset relative to the base.

>operator pre/post/in-fix variations and precedence nightmare
Oh cry me a fucking river. RTFM.
>>
>>43586364
>sizeof() computes the size of the data type.
As noted above by others, this is also not strictly true, since array sizes are not part of type information.

>I guess to confuse comp sci students. Either you pass by value, or pass by pointer. "Passing an array" is passing a pointer. That's why its size is the size of a pointer.
Yeah, I know why it yields those results, I'm just arguing that allowing the []-passing syntax as-is was a confusing mistake, and distinct, more useful semantics could have been created for it instead.

>>No shit. I was just making a jab at C strings with in-band length handling.
>I don't see your point. I don't agree with it, but it's there to make it appear simpler for CS hipsters. You know, make it more like Java.
WTF? Java string aren't even mutable.
C strings are the way they are (in-band null termination) because C's pointer/array equivalence semantics make passing buffer lengths around cumbersome.
All so we can do:
/* soooo elegant, omg! */
char *strcpy(char *p, char const *q) {
while (*p++ = *q++);
return p;
}
>>
Arrays as pointer+length tuples would be a good idea now that we have fast processors, but was a bad idea when C was invented.
Remember C is pretty much only concerned with speed, that's why it's hardly convenient for the programmer.
Pretty much any new programming language designed today keeps 'length' information tied to arrays
>>
>>43586576
>Arrays as pointer+length tuples would be a good idea now that we have fast processors, but was a bad idea when C was invented.
>Remember C is pretty much only concerned with speed, that's why it's hardly convenient for the programmer.

This has proven to be the biggest and most heavy-handed case of premature optimization in the history of computer science.
The number of critical bugs/security vulnerabilities in "heavily audited/high-profile/mission critical" projects like the Linux kernel and OpenSSL has shown this over and over.
>>
>>43586576
>but was a bad idea when C was invented.
Wrong. Look at PL/I and Algol 68 to see what arrays were like before C brought about the dark age of computing.
>>
>>43586690
Okay maybe, but C certainly thought it was a good idea
>>
>>43586572
>As noted above by others, this is also not strictly true, since array sizes are not part of type information.
Yes, but the array initialization example is the only such case, no?

>Yeah, I know why it yields those results, I'm just arguing that allowing the []-passing syntax as-is was a confusing mistake, and distinct, more useful semantics could have been created for it instead.

I agree. It's superfluous syntax. That doesn't make the language fundamentally flawed, though.

Also I think you implemented that strcpy incorrectly. It should not copy a null terminator. Just so you know, a lot of those trivial functions are intrinsic - especially in optimized code. You can make any language's code look ugly, that depends on the programmer.

I haven't yet seen any convincing argument of a fundamental flaw that makes C a justifiably "bad" language. C has been around for longer than most posters on this board. It's been fixed, ridiculed and used for decades - and it still is. It's no wonder that some prehistoric examples of syntactic failure still exist.
>>
>>43586690
>Look at PL/I and Algol 68 to see what arrays were like before C brought about the dark age of computing.

Sure but look at the problems Pascal had with strings > 256 bytes.
>>
>>43586719
>It should not copy a null terminator
I believe you are wrong?
strncpy() doesn't copy \0 but strcpy() does

>I haven't yet seen any convincing argument of a fundamental flaw that makes C a justifiably "bad" language
It's the best at what it does (simplicity and speed, at the cost of ease) but unfortunately for every other use case, there is a lot of room for improvement. It's simply outdated, there's a reason buffer overflows don't exist in any other language
>>
>>43586719
>Also I think you implemented that strcpy incorrectly. It should not copy a null terminator.

That's the classic K&R example, it's correct.
>>
>>43586783
No, strncpy has a third parameter: the maximum size of the string. strcpy will copy everything up to the end of the string (null).

>It's simply outdated, there's a reason buffer overflows don't exist in any other language
Buffer overflows are a property of x86. You can't overflow a buffer using the SPARC architecture in the same way you can with x86, regardless of C. Subverting overflows starts with YOU, the programmer, and not using unsafe functions like strcpy().
>>
>>43586719
>Also I think you implemented that strcpy incorrectly. It should not copy a null terminator.
The code is virtually verbatim from what K&R commends as an "idiom that should be mastered", regardless of what the C runtime actually does internally.

>>43586719
>I haven't yet seen any convincing argument of a fundamental flaw that makes C a justifiably "bad" language.
C leaves all forms of correctness as idioms to be followed rather than statically verifiable core language semantics and functionality.
Whether this matters is just a matter of personal taste apparently.
>>
>>43586843
>You can't overflow a buffer using the SPARC architecture in the same way you can with x86,
Buffer overflows still cause plenty of other issues.
>>
>>43575951
No it would be worse
>>
>>43586843
>Buffer overflows are a property of x86. You can't overflow a buffer using the SPARC
Hardware bounds checking is the exception, not the rule.
Even so, language semantics have to support it to be useful anyway.
The hardware can't check a length that isn't passed into a function.
>>
>>43586857
>Whether this matters is just a matter of personal taste apparently.

Apparently it doesn't matter.

>>43586873
Yes, but that's what happens when dealing with memory. If there is a fault in *your* code is *your* problem. It's not C's fault. You can't obfuscate memory for *many* vital computing applications.

>>43586932
But the language semantics do support it - it's strictly up to you. Yes, it's harder, but in the long run, at least you know that it can be a serious problem. Contemporary compilers force a fault if an overflow occurs.
>>
>>43587055
>If there is a fault in *your* code is *your* problem.
I never make my shit vulnerable to buffer overflow because I program C consciously
Even then, buffer overflows are the one of the most common and most vulnerable errors in C programs.
Array-length would prevent so many of these errors and the "overhead" is miniscule. Also you wouldn't have to pass "int length" (or unsigned int, or size_t?) as a separate parameter constantly

Keep in mind I'm not advocating for these to be "added" to C or anything, just that it was a bad design choice
>>
>>43587055
>But the language semantics do support it - it's strictly up to you.
This is a bullshit argument.

Claiming that adding extra length arguments to function signatures is as good as intrinsically length-indicating buffer handle types is completely retarded.
>>
>>43587155
Oh, so I can claim that since you can perform SQL injections, that PHP is a "bad" language for not doing your work for you. Or that SQL is a shitty design because it doesn't sanitize input for you.

Lots of problems with memory can happen if you're using a language which directly works with memory. You don't get these problems in Java, but then again, you don't get to touch memory in Java either.
>>
>>43587181
What's wrong with adding length checking in your code? That's simple if you write well thought-out code. Be a lazy programmer and you'll pay the price. Can't expect the compiler designers to do *everything* for you.
>>
>>43587217
Array-length wouldn't solve every single memory problem but would fix some and be more convenient overall.

Evaluating user-input as code (SQL) is a bad idea, and PHP is a shit language so I don't really see what your point is. A better solution to SQL would be something like mongo where you use JSON structures that get converted to strings (and therefore escaped) and send those to the server.

>>43587274
>Can't expect the compiler designers to do *everything* for you.
That's an absolutely horrible argument and is screaming stockholm syndrome/"C-hacker syndrome"
>>
C++ is a fine language for when performance is an issue.
It is a horrible language for when performance is not an issue and you need to produce a large app that is:
Easy to maintain
Easy to extend
Inexpensive.

Remember that every line of code = money. You pay developers for their time and developers are plenty expensive. I do not see C++ making a comeback into mainstream despite the efforts from everyone and their dog ( looking at you MS). Java and C# are the languages of the now
>>
>>43586843
>Buffer overflows are a property of x86.
That's what segments and the BOUND instruction were for. C compilers have no way to use these features. If compilers have no use for it, it doesn't get optimized. If it's not optimized, it doesn't get used.
x86 is terrible, but if it was used the way Intel wanted it to be, it would have evolved into something much nicer than it is today.
>>
>>43587274
Not anon you're replying to but array length is pretty much expected in every language nowadays. Stop living in 1988 please
>>
>>43587299
>Array-length wouldn't solve every single memory problem but would fix some and be more convenient overall.

I don't want the program do all this crap for me. Getting the length of an array is not a simple task, and when performance is necessary to consider, it makes it completely redundant and useless.

I don't know PHP, nor do I care about it. My point is that it's not the fault of the language that the programmer fails to write good code.

>That's an absolutely horrible argument and is screaming stockholm syndrome/"C-hacker syndrome"
Oh, sue me. I'm the kind of guy who enjoys having full control over what he's doing. I would never rely on something as systematically vague as "array length checking" that's built into the language. It's unnecessary, slow and overly redundant. Maybe this would suit the trivial programmer, but not someone who has a sense of dignity.
>>
>>43587274
This is a stretch.
It is literally impossible to sanely use a buffer/array sanely without knowing its length OR doing in-band length signaling via nulls, etc.

The better solution for C would have been to support these semantics:
#define LEN 3;
#define ALEN(X) sizeof(X)/sizeof(X[0]) /* ideally a keyword for this would exist */

/* statically-sized array typing: */
void foo(int[LEN] a) { for (int i = 0; i < ALEN(a); ++i) { /* ... */ } }

/* and transparently-passed lengths: */
void bar(int[] a) { for (int i = 0; i < ALEN(a); ++i) { /* ... */ } }

/* in-band signaling for the retarded: */
void baz(char *a) { /* ... */ }


This would be exactly as efficient as C ended up being while being a whole lot less error prone.
>>
>>43587408
>Getting the length of an array is not a simple task
If you're calculating it, but not if its stored alongside the array.
>>
>>43587373
Just because BOUND exists, doesn't mean that the stack is no longer subjected to overflows. This is entirely compiler based, and even without BOUND, you can check for overflows. C doesn't need this one bit. And if you're really anal about it, I suppose you could write your own compiler (in C).
>>
>>43587447
>writing compilers in C
Sure, if you want to spend more time managing memory and reinventing strings than actually optimizing and generating code.
>>
>>43587427
>int[] a
Ugly as sin. Why not just pass a pointer and an int with its respective length?
>>
>>43587408
>It's unnecessary, slow and overly redundant.
If you hate 4 or 8 bytes that much, the overhead from malloc would give you a heart attack.
>>
>>43587365
>no other language has true generics
>Easy to maintain
>Easy to extend
>Inexpensive.

>I do not see C++ making a comeback into mainstream despite the efforts from everyone
C++ is steadily growing while Java is declining
>>
>>43587496
Kind of like the overhead you get from allocating heap for all the useless objects in Java? Yes, I imagine it's quite bad. This did actually concern me, so I wrote my own malloc which uses allocated pages.

>>43587496
Yeah, glad I went with C++. Now I have a job, lol.
>>
>>43568036
>[p]oop

Raging 4 year old detected
>>
>>43587477
>>int[] a
>Ugly as sin.
opinions

> Why not just pass a pointer and an int with its respective length?
Because:
>>43587427
>It is literally impossible to sanely use a buffer/array sanely without knowing its length OR doing in-band length signaling

Given that, syntactic sugar to support passing the length in an error-proof way would have saved untold amount of coding time and the consequences of god knows how many bugs. See HEARTBLEED if you don't believe me.

Even syntax like the following would have been a substantial improvement:
void bar(int a[length]) {
for (int i = 0; i < length; ++i);
}
>>
>>43568378
Copypasta bitch
>>
File: 1398833392168.jpg (68 KB, 749x434) Image search: [iqdb] [SauceNao] [Google]
1398833392168.jpg
68 KB, 749x434
>>43568036
>C++ is C trying to be something it should never try to be, Java. And every other bloated [P]OOP language.
>>
>>43568744
I don't get it, it seems fine.
>>
>>43576034
I've heard a lot of things about c++, but this is the first time I've seen someone call it slow.
>>
>>43587609
Why would you be passing a buffer unless you knew its length? Would you pass a buffer full of random shit? I always thought that a buffer was supposed to contain useful data, not nonsense. If it's a string, use strlen. If it's a PE raw image, parse the header, or pass its physical length. It's not that hard.

>>43587694
You're right. Vectors are dynamically expanding arrays. They're much like C arrays, except you can resize them. This is the same as, or faster than any other non-transparent high-level language.
>>
>>43587609
>HEARTBLEED
I can't imagine OpenSSL being written in Java, lol.
>>
>>43587845
>Why would you be passing a buffer unless you knew its length?

Of course you need the length, that's the entire point.
The idea is that it's so important, it should be all but impossible to omit or incorrectly pass.

C buffers are really just ad-hoc pointer tricks with syntactic sugar that improves only brevity and not utility or safety.
The language would have been massively improved if dynamically and statically sized buffers were first-class language features.
>>
>>43587889
>I can't imagine OpenSSL being written in Java
No shit, but things like C++11's std::array<char> are as fast as anything in C and make creating bugs like Heartbleed much harder to do.
>>
>>43588002
whoops, should be std::array<T, size_t> or std::vector<T> for that matter.
>>
Nothing in user mode needs C. With managed languages, the CPU wouldn't even need a user mode.
OSes used to be written entirely in high-level type-safe garbage-collected languages with no assembly at all. It's all 60's/70's technology that people forgot about around the time when we stopped going to the moon.
>>
>>43587969
You're not making any sense. A buffer is a region in memory with a base pointer, and a size. You can pass its size, if you need to. To free memory, you don't need to know its size, that's handled by C runtime.

>C buffers are really just ad-hoc pointer tricks with syntactic sugar
Uh I think you were trying to say that there is no language-specific syntactic sugar, that's the whole idea. If you really cared for nonsense, you can make a structure in C:

typedef struct {
void *buffer;
UINT size;
} BUFFER, *PBUFFER
>>
Assembly
>>
>>43588054
This. It's 2014, we no longer need assembly. We can just make everything interpreted. And that interpreter will run purely on "magic." We can run one giant interpreted kernel, together with user code, much like DOS, except with a lot less sense.

>>43588002
Uh I don't have a problem with C++. Everyone creates bugs, what's your point?
>>
>>43588054
>With managed languages, the CPU wouldn't even need a user mode.
Please god no.
Hardware process virtualization is infinitely more trustworthy than bytecode static analyzer verification, and address translation is pretty computationally cheap anyway.
>>
>>43588116
The interpreter is called a CPU and the magic is called hardware.
>>
>>43588132
There is still hardware-enforced protection with no user mode with tag bits. Instead of protection on the process level, you have protection on the byte level. It worked for Lisp machines and plenty of other CPUs before Unix took over.
>>
>>43588142
Wait a second. You want a CPU to interpret Java. This has got to be the single worst argument I've seen today.
>>
>>43588181
Modern CPUs have billions more transistors than the 70's. You really think x86 crap is the best we can do with them?
>>
>>43588075
>You can pass its size, if you need to.
Please explain how a function can ever safely accept and operate on a buffer without having a size passed or known statically.

Remember that if you are using convention via size typedefs, thing could only get less worse by making buffer size part of static type signatures.

> To free memory, you don't need to know its size, that's handled by C runtime.
Congrats, the heap is self-consistent. Unfortunately, buffers sourced from "void *malloc(size_t)" need to be used for things other than "void free(void *)".
>>
>>43588219
PowerPC
>>
>>43588256
>via size typedefs
whoops, meant size #define statements
>>
>>43588219
Do you realize how complicated it is to do high-level things in hardware? Do you not realize that this is why we have simple assembly, and complicated software? It's trivial to recompile a software interpreter. It's impossible to reflash your CPUs hardware. If you need to get the latest revision, you need a new CPU. This has got to be a troll.

If it isn't, then this is a terrible idea, you will not be the next Steve Jobs.
>>
>>43587274
>What's wrong with adding length checking in your code?

It's not as reliable or compiler injected length checking.
>>
>>43588319
Yes it fucking is. It does what you tell it to do.
>>
>>43588256
>Please explain how a function can ever safely accept and operate on a buffer without having a size passed or known statically.
I think you can pass size to a function. void f(const void *buf, int size);

>Congrats, the heap is self-consistent.
So what? You use the buffer based on its need. C obviously allows this. When you allocate a buffer, you know its size, no? I'm not sure if there's any API out there that would allocate a buffer, and not return its size. Absolute nonsense.
>>
>>43588345
Which is good until you or someone on your team forgets to add a bounds check somewhere.

Security through convention is piss poor compared to having it built into the language with strong guarantees.
>>
>>43588431
This is extremely rare, it doesn't happen very often unless one of your team happens to be stoned. You can crash a car if you're stoned too.
>>
>>43567271
OP's pic is shit code.
>>
>>43588412
Are you being intentionally obtuse here?
C's handling of buffers in unquestionably more error prone than systems that use address/size tuples or addresses with statically-typed size information.
>>
>>43588460
>This is extremely rare
[citation needed]

Human error is not "extremely rare".
>>
>>43588472
>Are you being intentionally obtuse here?C's handling of buffers in unquestionably
If you produce that many serious and careless bugs, and fail to check *very* basic things yourself, then you shouldn't be entitled to touch a fucking computer, let alone be a programmer. It's dangerous, yes, but it comes with great advantage. Learn to ride your bike, kid.
>>
>>43588496
A successfully exploitable C-compiled program is extremely difficult to find. Chances are, today's compilers will cause an exception, and at worst, you have a crash.
>>
>>43588509
>>43588460
>This is extremely rare, it doesn't happen very often unless one of your team happens to be stoned.

I think you should quit using C/assembler as a crutch and just go with straight machine code, mr. professional. I mean, you don't seriously need a crutch like a translated programming language, righ?
>>
>>43588573
I do use assembler, on a daily basis. I don't think you know what "machine code" is.
>>
>>43588596
> I'm loser who doesn't even know all my architecture's opcodes by heart.
>>
>>43588538
I doubt you have any evidence to back that or your original claim up.

For someone who thinks errors are extremely rare, you sure do make a lot of them in your thinking.
>>
>>43588629
Trivial argument - I know most x86 opcodes and encodings. I can tell that you lost, since you're resorting to personal insults as a last desperation.

>>43588656
What was wrong about my statement? You can make errors in any language, not just C. Think about how rare and difficult it is to find a vitally exploitable program these days. Maybe you ought to read more carefully, I was talking about buffer overflows, which can be exploited. Errors can be rectified, overflows can be disastrous. Also there is a reason why we having exception handling, this is not new to Java.
>>
The biggest mistake C made by far was that arrays decay to pointers when passed through function, so buffers have to be idiomatically reconstructed inside the calls.

Remember that language idioms are just gaping holes from missing semantics, and C decided that keeping buffer size around was just not important enough.
I guess maintaining pure pass-by-value conventions was just too important.
>>
>>43588728
>I can tell that you lost, since you're resorting to personal insults as a last desperation.

You first.

>>43588460
>it doesn't happen very often unless one of your team happens to be stoned.

>>43588509
>If you produce that many serious and careless bugs, and fail to check *very* basic things yourself, then you shouldn't be entitled to touch a fucking computer, let alone be a programmer. It's dangerous, yes, but it comes with great advantage. Learn to ride your bike, kid.
>>
>>43588734
Or maybe they're not. Maybe they're not necessary? I don't see why my language should check buffer length, if I didn't explicitly tell it to do so. I'm starting to think that you don't know what a buffer is.
>>
>>43588753
A whole post without actually stating anything about C at all. We've reached the final level here.
>>
>>43588813
the meta*-commentary has only just begun, anon.
>>
>>43588728
>I know most x86 opcodes and encodings.
Then what's the opcode for VFNMSUB231SD?
>>
>>43588845
That's not x86 numbnuts, it's FPU. Moot point anyway. Even if I didn't know what it was, I could have found this:

http://www.felixcloutier.com/x86/VFNMSUB132SD:VFNMSUB213SD:VFNMSUB231SD.html
>>
I have been reading this discussion for a time. Actually the C arrays part and I think some you guys seem to be missing an important point.
C is sometimes jokingly called the portable high-level assembler. This has some truth in it.
They created C back then specifically for very low-level systems programming among other things. That's why it's missing some features such as the proposed pointer/length pairs.
Lot of languages are based on some highly abstract "stuff" which makes it abstract form the machine in a lot of ways hiding a lot of "stuff".
I think the purpose of C is the exact opposite: to be really close to the machine. What you write gets compiled in a trivial way to machine code.
A lots of high-level languages for example C# has pointers in them (I just take pointers as an example.), but that doesn't mean they can be used for the same purposes as C. It's sometimes comes in handy to have a pointer in a high level language and you don't have to resort to C, but that doesn't mean that you can use a high level language for the same purposes as C.
Take for example embedded development or low-level kernel development. Even if your functional language has a pointer in it, doesn't mean it's best to write your kernel in it.
If you want to make checks regarding buffers then by all means do it it's important, but the beauty of C is that you don't have to do this everywhere and this can come handy. You can decide where you want to do what.
>>
>>43588793
>I don't see why my language should check buffer length, if I didn't explicitly tell it to do so.
The point isn't just about implicit length checking, anon.
It's that you can't pass an array field through a function call without losing the length information.
Checking is still the responsibility of the function implementer, but it's not even theoretically possible to have a function that safely accepts arbitrary-length arrays without knowing their lengths, so why make the process of passing the lengths so needlessly cumbersome?

> inb4 C-strings
>>
>>43588881
Agreed, C is far from obsolete if the general idea of assembly hasn't changed that much. Doesn't make C suitable for all things, but it doesn't make it unnecessary either.
>>
>>43588728
>You can make errors in any language

This is stupid egalitarian spiel.

Some languages are easier to make errors in than others. Some languages, like PHP and C, make it harder to write safe code than it needs to be. You can make considerably less errors in languages that have safety mechanisms built in.
>>
>>43588898
Passing a buffer length by value is not particularly cumbersome. What if the buffer had a header? Couldn't you just parse the header to determine its length. Trivial example, but I don't see why its necessary to pass/process/check buffer lengths in all cases. Look at the glibc, or the win32 API. All functions that require a buffer length have an appropriate field for it, assuming that it's required.
>>
>>43588954
But you make all sorts of new errors, don't you? I know when I started working with C++ that a lot of the errors I used to have were replaced by bugs that I needed to learn to solve. Errors will exist regardless of language, what's your point?
>>
>>43567271
>what's wrong with c++?

All the shit it inherited from C and earlier.

> the fucking preprocessor
> pass-by-value
> null pointers
> the aforementioned hack that is C arrays.
> completely manual memory management

I look forward to Rust getting more fleshed out. I like 90%+ of what I see going on there.
>>
>>43588981
>Trivial example, but I don't see why its necessary to pass/process/check buffer lengths in all cases.

Every buffer-processing function needs one of the following to be safe:
1) Statically known size, or:
2) Dynamically-passed size.
(The latter can be send out-of-band or in-band like null terminated strings, but the latter is error prone.)

The point that people above are making is that static size information should be a part of a function signature, and the dynamically passed sized would be better handled at no extra cost whatsoever if the language provided syntax/semantics for treating passed arrays as address/size tuples.
>>
>>43589004
Some errors are solved problems that don't need to exist any longer and can be easily prevented with language features.

When someone comes up with a way to reliably prevent a host of new errors at compile time, you would be the first to label it redundant because "Errors will exist regardless of language" and go back to back to writing retarded error prone security by convention code.
>>
>>43589111
Passing a parameter in a C function is extremely efficient, in its assembly. Probably more so than anything Java could do. It does not require more convoluted syntax, it has everything it needs to do this already.

>>43589115
I haven't seen one language yet that produces completely bug-free code. Let me know when Java supports completely bug-free code.

>go back to back to writing retarded error prone security by convention code.
Yeah, because the kind of code you write in C is extremely sensitive, and vital for security. But also necessary, as you need completely command of the computer.
>>
>>43589157
>completely bug-free code
This is not the point you fucking moron. Christ you are retarded.

> vital for security
Which is more reason to have better safety features in the language.
>>
>>43588932
You got it.
That's exactly my point. C is not for everything.You can do everything in it if you want, but that's a bad idea.
>>43589115
I'm a different guy, but if you don't need what offered by C then by all means don't use it. Use a language which offers all that built-in safety-checks. Especially if it's not necessary to what you are doing and doesn't limit you in any way.
Arguing that a certain language doesn't do what another language does after a certain point always seemed to me like saying "Hey, why this screwdriver can't break this brick into half? My hammer can do this so well and I can even get a screw off with it If I really want it. So why hell did those guys design a screwdriver?".
>>
>>43589197
You don't deal with memory-related bugs in Java, because you don't deal with memory directly in Java. There is a huge difference in the paradigms of C and Java, and it seems that *you're* missing *that* point.

>Which is more reason to have better safety features in the language.
But everything you need is right there. No need to add extra crap.
>>
>>43589207
There are zero-overhead solutions to some errors. There are ways to reduce the occurrence of some errors with zero-overhead. C is not beyond criticism. I never see anyone give this retarded shit about being able to make errors in any language when other languages are shit on.

Troglodytes with baby duck syndrome are the worst.

>>43589249
>Java
Irrelevant.

>you don't deal with memory directly
There are ways to deal with memory directly in a safer manner.

>But everything you need is right there.
Security by convention is unreliable and inadequate. I already told you why and you never gave me a good come back, so I suggest you stop bringing this up and arguing in circles like a retard.

I'm still waiting for your evidence that programmer errors are "extremely rare".
>>
>>43589299
>There are zero-overhead solutions to some errors.
I can agree with this. As long as it doesn't take away flexibility from a language which is created for a certain purpose.
>Troglodytes with baby duck syndrome are the worst.
WTF
>>
>>43589299
Perhaps you ought to clean your ears a bit and reread that exact post in which i put the keywords "extremely" and "rare."

>Security by convention is unreliable and inadequate.
NO! Do you not get that it's HOW you use the language that is more important than the syntax itself? When it comes to security and precision, I would simply never let the language decide what I should use, and what I shouldn't.

>There are ways to deal with memory directly in a safer manner.

This is true. There are ways to deal with memory in a safe manner - C provides everything you need to accomplish that.
>>
>>43588460
Perhaps you ought to give me evidence that programmer errors are "extremely rare".

I don't particularly care how you write programs. You've already shown to me that you're a moron and have never worked with other people on a project.

>C provides everything you need to accomplish that
In a way that is unreliable and inadequate. I'm still waiting for a real response to this >>43588496
>>
>>43589535
This looks hard for you, so I'll just explain. I used "extremely rare" in the context of exploitable bugs like Heartbleed, which was the topic of discussion at the time. Quit making something out of nothing.

>I don't particularly care how you write programs. You've already shown to me that you're a moron and have never worked with other people on a project.
I don't see how you could possibly draw that conclusion. Maybe it's insight, or maybe you're just full of it.

>In a way that is unreliable and inadequate.
Since it's possible to write bug-free code in C, I don't see how the mechanisms of the language would make it inadequate.
>>
>>43589048
> pass-by-value
The style of call by value used in Algol 68 and ML is the most elegant calling mode for a non-lazy impure language.
Stateful references are first-class values and the only source of mutability. All other types of value are immutable.
Other values are stateful if and only if they are composed from (for compound data types) or capture (for closures) stateful values. Everything else has no state.
http://home.pipeline.com/~hbaker1/ObjectIdentity.html
>>
>>43589573
There is no evidence to suggest that exploitable bugs are extremely rare either. On the contrary, 0-day exploits are found all the time. Guess what? Exploitable bugs are all the result of programmer error. Amazing, isn't it?

Possible does not mean reliable and adequate. Saying it's possible to write bug free code is meaningless because you can write bug free code in any language. By that logic all languages are "adequate". In this context it only makes sense to talk about a language's security features and the ease at which it allows you to write safe code. C is a miserable failure at both.
>>
>>43589586
While logically elegant, pass-/call-by-value is inefficient on real general-purpose hardware for objects bigger than a machine register.

Shoehorning in efficient access to structs/arrays by passing the value of a memory reference is a more cumbersome system than one of simple pass-by-const-reference with optionally qualified pass-by-mutable-reference.
An ABI standard of transparently passing const objects of machine word size or smaller by copied value would take care of any efficiency gripes with this system.
>>
>>43589697
0day exploits are found, but that doesn't mean that they're found frequently. They're difficult to find, and take a lot of time, effort and skill to actually produce one. I don't get why you're lingering on this. Must be the only thing you have going.

If the nature of the language allows the programmer to check for exploitable code, then I don't see how it's inadequate. That doesn't make sense.

I don't see the reason to use garbage like pairing a buffer with its size, when you can just pass that as a parameter and accomplish the exact same thing, without the need of creating new syntax or a new language. And no, not all languages are adequate for what C can accomplish. Ease is in the eye of the beholder. Just because you find it difficult to check the length of a buffer, doesn't mean it is.

C doesn't fail at anything, anon, you do.
>>
>>43589769
>C doesn't fail at anything
You ought to have that engraved on a plaque for your cube.
I swear I can smell the greasy sweat in your neckbeard from here.
>>
>>43589868
Lol, and sometime in the future, far after the decline of Java and other shit-tier languages, maybe you will engrave "I should have learned C instead," on your fucking tombstone.
>>
>>43589769
>0day exploits are found, but that doesn't mean that they're found frequently.
You have no evidence for this. Errors are extremely common in programming, I know that much. Go to any bug tracker to find out for yourself. Your claim that exploitable bugs are "extremely rare" is entirely unsubstantiated.

>Must be the only thing you have going.
This is funny coming from you, considering you continue to rehash your tired old arguments that get shot down every time and fail to see the errors in your thinking.

>If the nature of the language allows the programmer to check for exploitable code, then I don't see how it's inadequate
Perhaps you suffer from autism and are interpreting "adequate" in an extremely pedantic and meaningless manner in the context of this conversation.

>I don't see the reason to use garbage like pairing a buffer with its size, when you can just pass that as a parameter and accomplish the exact same thing
I don't see the reason to do tedious garbage like requiring everyone to litter their function parameters with an extra argument to do basic bounds checking when the process could be entirely automated and done much more reliably with built in languages constructs and the compiler.

>Just because you find it difficult
I don't, I'm just not delusional enough to think security by convention is a good solution because I'm not a deluded neckbeard like you.

>C doesn't fail at anything, anon, you do.
You fail at defending your pet language.
>>
>>43589913
I'm not actually the anon above, and I can (and do professionally) actually code primarily in both C/C++ and limited assembler.

C is prolific because it was the first system language to be "good enough", not because it's flawless.
I know it's fun to troll Java/CLR programmers all day long, but there are plenty of shit-tier aspects of C that you've Stockholmed yourself into loving.
>>
>>43589980
Maybe so, I mean C has its faults. But all the arguments brought up in this thread are nothing close to justified. I also hardly ever code in C, lol.

>>43589978
>You have no evidence for this.
I suggest you read a bit further into this.

>Perhaps you suffer from autism
So what if I do? That doesn't prove you right. What you said is a logical contradiction.

>I don't see the reason to do tedious garbage
Hilarious, considering Java is construed as being entirely tedious garbage.

>I don't, I'm just not delusional enough
You're barely holding onto justifying using Java, I'd say you're about to snap.

>You fail at defending your pet language.
kek
>>
>>43590074
>But all the arguments brought up in this thread are nothing close to justified. I also hardly ever code in C, lol.
Most of the arguments in this thread about C are in regards to its deficient type system, particularly in regards to pointers and arrays.

It seems to me that you and most other people here are erroneously conflating the cost of bounds checking random array access with the issue of array->pointer demotion in parameter passing.
Having properly typed statically-sized arrays and first-class dynamic array-size handling would have had zero performance impact and prevented countless bugs over the years.

I think comments like this are conceptually on-track, even if I disagree with the syntax choices:
>>43587427
>>
>>43590074
Hilarious. I have no clue where this Java shit is coming from. I guess it's all you have left.
>>
>>43590308

>Having properly typed statically-sized arrays
An array is not a datatype, it shouldn't be typed.

>first-class dynamic array-size
Sounds like I'm Qatar Airlines. You can create an object in C that expands the size of an array. By the way, dynamic arrays are extremely time expensive when not properly implemented. I've never needed expanding arrays so badly that I had to use Java.
>>
>>43590326
Oh, I had the impression that you were a Java coder for like 4 hours. You must've sounded like one, I don't know.
>>
>>43590363
>An array is not a datatype, it shouldn't be typed.
An array of statically known size is equivalent to a homogeneous tuple, which is clearly a distinct type that can be supported in a programming language.

>dynamic arrays
not dynamically (re-)sized arrays, functions that accept arrays of sizes known only at run-time.
I.e., support for the position/size tuple syntactic sugar you seem so opposed to.
>>
>>43589733
That's precisely why Algol 68 and ML's call by value with object identity is so different from call by value that other languages like C and Scheme use. Immutability and first-class references make the distinction between a value and a constant "reference" to an object completely meaningless as far as semantics go.
Everything, whether it's a single byte or an enormous array can always be passed without copying, whether or not it has state. It's up to the compiler to decide whether it's more efficient to pass a value by copying instead of as pointers.
>>
>>43585686

show me an implementation of this that is more succinct than the c++ version.
>>
>>43580641

wow, you've got a bad case of c hacker syndrome, kid. get help, before it's too late.
>>
>>43591023
Ain't gonna happen.
The C preprocessor with its unhygenic macros and general lack of power and safety is no real substitute for real generic programming.
That said, C++'s struggle to get Concepts in the language is approaching being a running joke at this point.
Thread replies: 337
Thread images: 9
Thread DB ID: 9637



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

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

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 shown content originated from that site. This means that 4Archive shows their content, archived. If you need information for a Poster - contact them.
If a post contains personal/copyrighted/illegal content, then use the post's [Report] link! If a post is not removed within 24h contact me at [email protected] with the post's information.