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 ):
>>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.
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
>>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
>>43569032test
>>43567271
>uppercase method names
disgusting
>>43568744
I'm guessing the issue is inptr = new int[i];instead ofptr = 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++.
>>43576011struct 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
>>43571095dank 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?
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.
>>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 theint *x, *y, *z;
You should be able to write itint* x,y,z;
As for thisint a[10] = {0};
It should beint[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
>>43583981int** 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 likeint 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 sayvoid foo(char *a, int l);orvoid 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 likevoid baz(int b[]);passed a hidden length parameter that could be accessed by the function body viasizeof(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. Usingchar* 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
