Are you still using unsafe languages to code your codes?

A pretty nice intro for beginners
https://youtu.be/sv9fTlU7SCA

>2016
>not being a rustacean

Is this memelang better than C?

Rust is unsafe.
http://www.tedunangst.com/flak/post/heartbleed-in-rust

>>52942672
In some benchmarks it's actually faster, and it provides compile time memory safety and safe concurrency. In most benchmarks it's very close in performance.

>>52942646
>2016
>Being a "Rustacean" because being a "Rustafarian" in 2015 skirted to close to "cultural appropriation"

God I hope these people choke.

>>52942672
No.

>>52942687
Nice bait, but all that article says is that rust is by no means a magic recipe for safety
Thatd be dumb btw

>>52942732
>but all that article says is that rust is by no means a magic recipe for safety
In other words: Rust is unsafe.

>>52942672
Mozilla is makeing a browser in it so yeah

>>52942672
>>52942773
Samsung is also working on it, which gives me more confidence desu

>>52942672
IMO it is as capable as C, since it's relatively easy to communicate with existing libraries and you are not limited in terms of what you can do. It's also comparable in terms of performance, and is only bound to get better (perhaps with better compile-time optimizations, too).

It's also got a better range of options, better safety and doesn't have cancerous syntax like C.

>>52942687
It's impossible to make a language that does not let idiots make mistakes. Rust encourages better practices in safety, but the sheer fact there is a way to transfer this safety to runtime (RefCell) makes it possible to be unsafe.

Your argument is still fallacious though; it is akin to saying railings are unsafe because one can still climb over them and throw themselves off.

>>52942804
>it is akin to saying railings are unsafe because one can still climb over them and throw themselves off.
That's a true statement, and it would not be fallacious to say "railing are unsafe".

You (and the other guy) seem to be confusing being safe with being saf-er.
No language is safe (or: all languages are unsafe), but some languages can be safer (or unsafer) than others.

the syntax is ugly, pass

>>52942745
"Safe" in the context of the marketing around Rust describes memory safety. The implementation of heartbleed in the article stems from reuse of a buffer. The logic error at play in his code is outside of the claims boasted by the developers about the language.

>>52942840
OP here
What you're doing is baiting by relying on semantics alone, so you can fuck off already. It is impossible, by definition, to have a turing-complete language be 100% safe.

Rust enforces safe practises, which is not to say you can't actively write unsafe code (which is the default on C for instance).

>>52942860
>muh syntax

Literally a 3 year-old could have made this post and his opinion would have been as valid and technically insightful.

>>52942840
You are contorting the meaning of safe.

Safe, in colloquial speech, refers to an accept level of safety. What you are reffering to is generally "completely safe". In the end we are just arguing semantics.

I understand your point, though (there are perhaps people out there who think rust is completely safe).

Also >>52942865 has it right, it refers more to memory safety; it's pretty hard to fuck up with pointers and write unallocated memory (which is something I have struggled with in C/C++, ended up writing over standard library functions... not nice.

>>52942860
Unlike C/C++, the holy grails of syntax beauty /s

>no TCO

File: Mozilla_Servo_showing_homepage.png (71KB, 600x454px) Image search: [Google]

71KB, 600x454px

Has anybody actually MADE something with this language?
Any work in progress anons that want to show their shit?

>>52942893
>Unlike C/C++, the holy grails of syntax beauty

imagine the surprise after discovering a new language that is even worse

>>52942881
>OP here
>What you're doing is baiting by relying on semantics alone
Irony: the post?

>>52942881
>It is impossible, by definition, to have a turing-complete language be 100% safe.
Why not?

>>52942928
I guess so

>>52942865
>Safe" in the context of the marketing around Rust describes memory safety.
Allocate a single array in C which covers the entire address space and store all your data there, now it's 'physically' impossible to go out of bounds.
Wow! Memory safety!

>>52942586
Oh god couldn't you find a shittier video you motherfucker?

>>52942966
>where's the point?

>>52942937
Well-formed programs that past even the most sophisticated type-checking can still have logic errors, and a compiler won't be able to just programmatically tell you when you're being a dipshit or working against your own intent until hard AI is solved.

>>52942966
two words
>virtual
>memory

>>52942381
>are you still using unsafe languages to code your codes?
Nope. I use Ada.

>>52942992
>muh robot waifu

It'll never happen, and if it does, it will probably be written in Rust, by a Rustacean. Because it's a safe language, and you wouln't want an unsafe robot now.

>>52942921
Interested in this too. Most projects seem to be WIP and I feel like it's going towards a meme language.
Love to be proven wrong tho.

>>52942966
Pre-allocating memory doesn't stop you from stomping all over it with raw pointers and is sidestepping the thrust of what they're actually trying to do overall with the language.

You sound like you're being dumb on purpose now so I'll stop there.

>>52942992
Logic errors don't mean unsafe code.

And it's not like "sophisticated" compilers are really clever and tell you when you're wrong -- they follow very simple rules (based on type theory, which is what all the safe languages are dipping into) and force the programmer to prove their own code correct.

>implying that wrapping unsafe operations inside an unsafe keyword makes your programs magically safe

>>52943071
No, but it means that you can track down a bug very quickly (i.e. you only need to check unsafe portions).

You could even have different annotations for different "types" of unsafe code to narrow it down even more.

>>52943058
Probably because the language is pretty new and changing.

I think it's a fine language, and the fact that it compiles directly and is geared towards systems programming is good news. C/C++ is showing its age.

>>52943093
Yea, very true, should probably gain momentum when Servo is stable.

Isn't C++17 improving a shitton? Even with the aging it has a massive following and awesome documentation

>>52943071
If you're using unsafe, you should already be having alarm bells going off in your head. It's the first thing you would be refactoring, and first place to be looking for a bug.

>>52943058
Most projects are WIP, but the community is really responsive and hard working. Just recently we've started having a pure rust port of FreeType, which is great. And things are pretty stable too, which is also nice.

>C++14
>Unsafe
Pick one. The language changed so much we don't even use raw pointers anymore (except to interface with legacy C code)

>>52943059
>Pre-allocating memory doesn't stop you from stomping all over it with raw pointers and is sidestepping the thrust of what they're actually trying to do overall with the language.
Exactly, see >>52942687

If we take heartbleed as an example the conceptual problem is information leakage, which can take many forms, don't need to go out of bounds to accidentatly expose information you shouldn't to a user.
If we take something like remote code execution and injecting code, it too can be done in so called 'memory safe' languages by exploiting regular unintended logic flow in the program.

>>52943179
Or to implement fast allocators and data structures. This is where Rust excels, although it's plenty unsafe in every other way.

>>52943060
The person you originally replied to was responding to someone using a non-technical and unconstrained dictionary definition of "safe". By that defintion compilers can't stop anyone from writing unsafe code. Dependent typing isn't going to stop someone from writing a program to dump their credit card database to port 80 if the typing is sound.

>>52943152
Well of course. It's the most used language in the world so that's no surprise.

I don't know about c++17, but c++11 feels like there's a lot of baggage stacked and new features are sometimes forced into awkward forms of syntax because of all its legacy.

Rust on the other hand is designed in its current, modern state. That's an important difference to me. It's not forced to respect decades of change.

>>52942381
> Are you still using unsafe languages to code your codes?

No, I use Haskell.

>>52943219
That anon also said
>Rust enforces safe practises
and we're on a technology forum, so I understandably assumed that they were using the word correctly.

>>52943179
Except C++ was not designed like this, and the performance hit is real.

>>52943058
funny shit, there are lots of programs using Go, and Go is only at version 1.5. meanwhile, Rust doesn't seem to have anything to show...

>>52943202
That's something entirely true, and has been conceded by the developers, and once again is also something entirely outside the claims they've made on behalf of the language.

>>52943231
Slow and autistic then?

>>52943214
Rust is pretty neat, and it's certainly more safe than C++.
But I get tired of fighting the compiler real quick in Rust, although maybe that's because I'm still relatively new to it (does it get better?).

The advantage in C++ is that all the complexity is pushed on the library developpers. In your libraries it's fine to use raw pointers to implement efficient data structures, and it's fine to use an inscrutable template incantation to the gods, because that gives you the power to create whatever clean abstraction you want on top of that.
All the end user sees is stack-allocated magic with zero-overhead and automatic memory management.

>>52943231
Haskell is not very safe. Even the standard library is full of partial functions for what should be returning Maybes (at least they recently added "readMaybe"). It just makes it easier to do auxiliary proofs of correctness, compared to something like C.

>>52943009
I did mean the virtual address space, but to be more precise: allocate an array big enough such that adding any size_t, ptrdiff_t or any pointer arithmetic always falls within the bounds of the array (which in practice does mean all of the virtual address space, and which is actually feasible for a 32 bit application running on a 64 bit OS).

>>52943234
Should've said "safer" practices?
This is a technology forum, not a linguistics one. Sophism much?

>>52943248
That's a misconception, there is no performance hit from using modern C++.
In fact just recompiling your old C++ codebase as C++11 will give you a free performance boost, just thanks to move semantics kicking in.

C++ has and will always follow Zero Overhead. If a core feature was bloated, it'd never get past the comitee.

>>52943291
No, the point is that Rust also can't protect Java Joe from messing up a credit card transaction, at least not in a way that's different from how it's already done (design by contract, unit testing).

File: trump_disgusted.jpg (75KB, 600x450px) Image search: [Google]

75KB, 600x450px

meme language created by a communist jew with a name and logo that only /v/ could love

>>52943304
Any kind of automatic poimter management has to add runtime overhead. There's no magical way to avoid this (except compile-time).

>>52943272
>All the end user sees is stack-allocated magic with zero-overhead and automatic memory management.

I just started using it for the first time in forever and I love this about it the most.

I spent a decade avoiding C++ because I thought it was C-style memory management
Then I heard about how the memory model is all RAII hides that from you and got interested again.
Now I'm using it and the STL containers hide all the RAII details from me.

I still trip over dangling references once in a while, but this is miles simpler than what I had always thought it was.

>>52943377
>except compile-time

Guess how unique_ptr works.

>sjw language

>>52943377
unique_ptr is zero overhead.

shared_ptr is not free, but it should only really be used in cases where a system like it would already have to be in place (like if it was to be used in an asynchronous operation).

>>52943058
Rust OS when?

Joke's aside, you can take any project you'd normally do in C++ and write it in Rust. Big projects meed time to get traction and visibility though, plus most base off libraries that are written in C or C++, making them more natural choices.

There need to be Rust implementations of library code first. crates.io is growing

>>52943377
I'll say it again, there is zero-overhead. Not one cycle, not one bit.
Since this is C++, you're right that all the magic happens at compile-time.

>>52943433
This.
shared_ptr is a refcounted pointer, it's basically a weak form of garbage collection, only to be used for certain complicated problems.

>>52943434
>Rust OS when?
https://github.com/redox-os/redox

>>52943421
>SJW boogeyman

>>52943421
>/pol/ hivemind

>>52943020
i found that ada was closed source - and that it was not statically typed

flushed down the toilet

all those planes are going to crash because a NPE sooner or later

>>52943433
>>52943441
Nice. As someone who learnt C before anything else, I find Rust's syntax for owned references of this kind more comfy, but I'm glad this tool exists in C++

>>52943250
Go's stable release is about four years older than Rust's.

>>52943485
>literal retardation: the post

>>52943554
Go is a language for retards. I'm not saying that as an insult, Rob Pike literally wants it to be as simple as possible so that even the cheapest H1B won't risk misusing it.

I'm not exactly surprised it sees more usage than the very square, precise and performant Rust.

>>52943563
>no counter
>just spergs memes

>>52943501
I find unique_ptr is largely useless.
How often do you actually want to dynamically allocate a single thing with a lifetime bound to scope?
Not only is it really inefficient, but it's also just plan bad design - abstract allocation away into some context manager, organize memory into arenas that are allocate and released in big chunks, files and network should be streamed in background threads, etc.

The only thing I like RAII for is locks and 'defer' type actions. For memory I find it to not be a big deal since I use the above mentioned abstractions.

File: lisbon-rust-lang-meetup1-3-638.jpg (43KB, 638x452px) Image search: [Google]

43KB, 638x452px

People are mistaken in thinking Rust is a succesor to C or C++. C is perfect for for what it does and there's no point in replacing it.

Where Rust fits perfectly is everywhere else. It offers almost-c performance and control with a good level of abstraction and safety. Plus it doesn't need the awkward optimizations and runtimes that plague high-level languages.

>>52942921
I've made a JPEG decoder

https://github.com/kaksmet/jpeg-decoder

>>52943606
There's nothing to counter. That anon just spewed out some really obvious outright lies and hoped nobody would notice.

>>52943585
Rob Pike wrote Go for himself because he hates C++ and Java. It's 90% the same as all of his other pet languages no one ever used outside Bell Labs.

Smart people don't drift to the most complicated or self-defeating tool possible just to prove their intellect on the Internet like /g/ does.

>>52943645
Nice.

I might port some of my SDL2 projects in order to learn

>>52943638
>C is perfect for what it does
HAHAHAHAHAHAHAHAHAHAHA

>>52943683
I think Rust has the potential to bring real performance to the high level arena

>>52943619
>I find unique_ptr is largely useless.
It's a different way of thinking, but when you get it it's so much more productive.
There's so much less crap you need to handle when everything has a clear owner that automatically takes care of lifetime.

>How often do you actually want to dynamically allocate a single thing with a lifetime bound to scope?
Always, really. Memory is a resource, if you allocate it you generally need it to hold an object or perform a computation.
Well whatever owns that object is responsible for deleting it in its destructor, and that means you can use a member unique_ptr instead of a raw pointer.
The idea is to have a clean owner for everything you allocate, that forces you to organize your code for the better.

>Not only is it really inefficient, but it's also just plan bad design - abstract allocation away into some context manager, organize memory into arenas that are allocate and released in big chunks, files and network should be streamed in background threads, etc.
This shows a deep misunderstanding. unique_ptr is exactly as efficient as a manuel malloc/free or new/delete, there is *literally* no difference. And you can still use custom allocators if you want to.
And you should still use abstractions, that's great. But those abstractions can actually use smart pointers themselves in their implementation most of the time, and especially in the interface, where it matters.

>The only thing I like RAII for is locks and 'defer' type actions. For memory I find it to not be a big deal since I use the above mentioned abstractions.
Your way works and the world won't end if you keep going, but We Have Better™.

>>52943683
don't pop his bubble anon
remember kids, maximum type safety, full purity, following a single paradigm to the extreme and generally only following a very singular solution is good engineering
just ignore all the other factors that matter

>>52943683
>Smart people don't drift to the most complicated or self-defeating tool possible just to prove their intellect on the Internet like /g/ does.
I absolutely agree, but "smart people" use the best tool for the job, not the simplest.
Using a simple tool doesn't allow you to build complex things without making a mess, using complex tools make simple things harder than they should be.
It's an obvious tradeoff that I shouldn't even have to mention, and not at all a good reason to use Go.

Why is Go vs Rust even a thing?
They are two very different languages intended for very different areas of use.

>>52943263
> gets rustled about a programming language
> calls others autistic

>>52943678


> Notable features of Ada include: strong typing, modularity mechanisms (packages), run-time checking,

strongly type - but run time checks

> http://libre.adacore.com/tools/gnat-gpl-edition/faq/

it has a half arse open source version - that does not have any of the tools that adacore builds

so no it's not a lie

>>52943808
I was just being cheeky. I actually love Haskell myself.

If I only had a reason to git gud at it though

>>52943871
*if only I

>>52943807
They were both announced at around the same time by rival browser vendors (ostensibly) targeting the same problem domain of native compiling GC'd system programming languages. The media played this up. Over time Rust dropped the GC and went more low-level, while the Go authors gradually revealed they were using a dated 70s unix notion of "system programming" that basically encompasses everything that's not a shell script.

>>52943933
>Go authors gradually revealed they were using a dated 70s unix notion of "system programming"
Did they ever advertise it as a systems language?

>>52943933
I think Go stopped marketing itself as a systems programming language some time ago.
I'm not sure what niche they fill up now, but I hear it's nice server side and they definitely have users.

>>52943933
Well, the GC is getting pretty close to being useful for many applications you'd usually consider "systems programming languages" for.

>>52943764
>There's so much less crap you need to handle when everything has a clear owner that automatically takes care of lifetime.
It's even better when you minimize the amount of owners in the first place.

>Always, really.
No, basically never.
The ideal situation is allocate all memory you'll ever need at startup, deallocate at the end (or let OS do it implicitly on process exit), although if memory usage can wary wildly (i.e sometimes hardly nothing is needed, sometimes several GB) you would need to free or risk claiming all ram for the duration of the program.
But a more realistic and very good compromise is memory arenas, divide things up into some reasonable chunks, possibly by the subsystems in the program.
>The idea is to have a clean owner for everything you allocate, that forces you to organize your code for the better.
Yes, but that owner should very rarely be some leaf function, it should be higher up in the call chain, by a dedicated manager.
>This shows a deep misunderstanding. unique_ptr is exactly as efficient as a manuel malloc/free or new/delete
You misunderstood me.
I'm saying malloc/free are inefficient - and they are, really, really inefficient comparatively speaking, allocating memory is one of the slowest operations a process can do (sans accessing harddrive, peripherals or network of course), so you absolutely want to minimize them.
>But those abstractions can actually use smart pointers themselves in their implementation most of the time
You could, but then they are not that big of a deal, the mental overhead of manually allocating freeing memory arenas is minimal because they just don't happen that often - since that is the point of them!

>>52943819
Ah, so it *is* literal retardation.

Ada is statically typed. Runtime checks are things like ensuring that you don't access a dynamically allocated array out of bounds. You can turn them off, although you really shouldn't unless you've proven your code to be good. Rust does the same thing.

GNAT GPL is a full open source Ada compiler, identical to GNAT Pro. Calling it half arsed is like calling GCC or Clang half arsed. Although what you probably want is GNAT FSF (the version distributed in most linux distro repos) because it has the LGPL library exception.

>>52943953
I remember seeing that phrase a lot but I'm too lazy to dig stuff up. Their FAQ answers explaining the rationale for the language still has plenty of oblique references to "systems languages" and "systems programming" and how they created go to improve over existing languages in that area.

https://golang.org/doc/faq

>>52943272
>But I get tired of fighting the compiler real quick in Rust, although maybe that's because I'm still relatively new to it (does it get better?).
Once you get into the lifetime thinking, you really miss rust's borrowchecker when getting bit in the ass by data races in other languages.

File: IMG_20160204_213657.jpg (3MB, 4224x3168px) Image search: [Google]

3MB, 4224x3168px

Does anyone know any good, comprehensive Rust video tutorials?
The book is very well written, but I'd like something I can watch for ours on end and I'd rather it be a video.
Thanks

>>52944002
>It's even better when you minimize the amount of owners in the first place.
I'm not sure what you mean by that. By definition there is only one owner for everything unless 1) the constraints impose sharing 2) you coded yourself into a corner.
That's no matter what kind of resource managment style you use.

>The ideal situation is allocate all memory you'll ever need at startup, deallocate at the end (or let OS do it implicitly on process exit)
That's completely unrealistic except for embedded development which is very different (because you shouldn't use dynamic memory AT ALL in these kind of very constrained embedded scenarios);
First because for most applications you can't statically know how much memory you'll need at runtime, and second because if every application were doing this it would be a comically braindead waste. Do you have any idea what you're writing?

>But a more realistic and very good compromise is memory arenas, divide things up into some reasonable chunks, possibly by the subsystems in the program.
This is the allocator's job, and has ABSOLUTELY NOTHING to do with the memory management style you use. Again, this shows a deep misunderstanding.

>Yes, but that owner should very rarely be some leaf function, it should be higher up in the call chain, by a dedicated manager.
As a rule of thumb, you should allocate as close to the use point as you can, and free as soon as you can.

>You misunderstood me.
I hope, because you're not making any sense.

>I'm saying malloc/free are inefficient - and they are, really, ... network of course), so you absolutely want to minimize them.
Sure they are. But this HAS NOTHING TO DO with smart pointers and RAII, you can use custom allocators just fine either way.

>You could, but then they are not that big of a deal, the mental ... since that is the point of them!
It's not just for you, but it's for the people that will maintain your code. I can't remember my last memory corruption, but I work with people.

>>52943719

Due to the community being infested by SJWs I think Rust has the potential to bring real performance to the high level drama.

>>52944149
All right kid
>>>/pol/
You can go back to your friends now. The adults are having a grown up conversation.

File: screenshot.png (103KB, 1242x744px) Image search: [Google]

103KB, 1242x744px

SolidOak is an IDE for Rust.
It's basically NeoVim with an optional "simple mode" and Rust-specific features.

>>52944238
> le kid response
Dont kid yourself, out of all the languages Rust comes pretty close to Ruby in terms of shitty userbase.

No matter how good a language is if in the long term it will turn to shit.

>>52944140
i feel like u just write for environments that have different constraints than the other guy.

>>Yes, but that owner should very rarely be some leaf function, it should be higher up in the call chain, by a dedicated manager.

this was the main point of his argument because memory allocation in general is slow, not that malloc/free specifically are slow - and u disagree as a rule of thumb.

>>52944335
>i feel like u just write for environments that have different constraints than the other guy.
I write for a wide range of environments actually, so that anon is really out of luck.
I'm currently working on some desktop programs that can afford to allocate 1GB without raising eyebrows, and at the same time embedded code for a 3U cubesat that'll spend a few months at 600km.

>this was the main point of his argument because memory allocation in general is slow, not that malloc/free specifically are slow - and u disagree as a rule of thumb.
I'm arguing for RAII, which means putting everything you can on the stack and letting the closing scope } clean up for you.
This means no dynamic allocation at all whenever possible, and unique_ptr the rest of the time (and shared_ptr if really you need it).

As for allocators being slow, it sure is, but then there two cases. Either 1) you can use the stack and why the fuck are you not? 2) You need a fast dynamic allocator, and whether or not you use smart pointers and RAII has nothing to do with that.
You can use an arena based allocator, you can use a freelist, you can use a SLAB allocator, you can use whatever you want, it's completely unrelated to what I'm saying.

>>52943638
>everywhere else
>le ebin sjw coc meme

>>52944140
>I'm not sure what you mean by that.
You consolidate as much ownership as possible into larger groups.
>That's completely unrealistic except for embedded development which is very different
It's quite realistic in more situations then you think, especially these days with 64 bit address spaces.
All little utility programs like media converters, info programs, compression tools, search tools, video player, basically most 'one-off' apps where you open some resource at startup and have it open until the end.
The programs which truly need dynamic allocation are actually comparatively few, and when they do they often want a kind of streaming data flow anyway (because they work with large data sets, and/or have stringent performance requirements) in which case you do use the abstractions I'm talking about.
>and second because if every application were doing this it would be a comically braindead waste.
In the end it would probably be less of a waste because you don't end up with any heap fragmentation.

>This is the allocator's job, and has ABSOLUTELY NOTHING to do with the memory management style you use. Again, this shows a deep misunderstanding.
No, this shows a deep misunderstanding on *your* part.
Memory allocation strategy is fundamentally ingrained with the overall design of your program, you need to plan for these things ahead of time, and you need to write your functions slightly differently.
And if you employ a particularly nice ownership design it even opens up new features like hot reloading of code and easier insertions of debugging and diagnostics code.

>As a rule of thumb, you should allocate as close to the use point as you can, and free as soon as you can.
No, the exact opposite is true.
Abstract away allocation as much as possible. Leads to both more efficient and easier to maintain code (and easier to test, since you can inject test data more easily).

>>52944140
>But this HAS NOTHING TO DO with smart pointers and RAII
It has everything to do with RAII - Resource Acquisition Is _INITIALIZATION_.
When you decouple allocation from initialization you are no longer using RAII - that should be obvious since your destructors are now be no-ops.
>you can use custom allocators just fine either way.
Custom allocators only makes sense for containers (i.e the larger abstraction I'm talking about), not for something like unique_ptr.

>It's not just for you, but it's for the people that will maintain your code.
And they will be glad over not having to think about owners so much.

> I can't remember my last memory corruption
Same here.

>>52944573
>>I'm not sure what you mean by that.
>You consolidate as much ownership as possible into larger groups.
Then sure, I agree.
To take an extreme example, of course you don't want to malloc/free in a tight loop.
But there's a tradeof here, chances are your performance bottleneck will not be the allocator unless your program is long lived, or you're doing something terribly wrong (like new/delete in a loop).

>It's quite realistic in more situations then you think, especially these days with 64 bit address spaces.It's quite realistic in more situations then you think, especially these days with 64 bit address spaces.
A 64bit address space doesn't change the fact that I have a limited amount of RAM and zero intention of going to SWAP.
If you're going to be wasteful in the name of simplicity, you might as well use Python.

>All little utility....open until the end.
>The programs... data flow anyway (because they work with large data sets, and/or have stringent performance requirements) in which case you do use the abstractions I'm talking about.
I think you understand that applications such as a video player or a compression tool don't know their memory requirement at startup, but can only estimate an upper bound after openning a file. But even then this is unrealistic. A compression tool for example theoritically has a huge upper-bound in memory usage, it's completely crazy to allocate all of that early and absolutely not a gain of performance.

>In the end it ...any heap fragmentation.
You vastly overestimate the cost of allocations in most desktop programs. In your examples of video players, compression tools or media converter it's not even close to 1%.

>Memory allocation...slightly differently.
I think we agree quite violently here, because what I'm advocating doesn't preclude using a different allocation strategy. The fact that I disagree with your extreme opinion is a different problem.

>No, the exact opposite is true.
Agree to disagree.

>>52944648
>It has everything to do with RAII - Resource Acquisition Is _INITIALIZATION_.
RAII absolutely doesn't preclude using allocation in a larger pattern than the exact point of use (although I would recommend that as a rule of thumb).
I think we can obviously agree that any program can be converted between a RAII and C style without any observable difference, it's simply a matter of choosing a judicious logical owner.

>Custom allocators only makes sense for containers (i.e the larger abstraction I'm talking about), not for something like unique_ptr.
We were talking about grouping allocations in a larger context, using allocators would make sense in that context, not for a single unique_ptr.
If you only have one or a couple allocation, then this is not an interesting problem, there is nothing to talk about.

>And they will be glad over not having to think about owners so much.
I would rather than they think about owners and have the compiler catch their errors than think about raw pointers and have Valgrind hopefully catch them.

>Same here.
I can, howether, remember fixing other people's bugs that I evidently wasn't careful enough in reviewing before merging. I did notice that my modern C++ projects have a lower memory error rate, which is wonderful empirical data.

>>52944765
>But there's a tradeof here, chances are your performance bottleneck will not be the allocator unless your program is long lived
Allocation is very often the bottleneck these days.
Most of my optimization work through the years dash been optimization string handling, and in the majority of cases it was extraneous allocations being the culprit, using static char arrays or string pools was the best solution many times.

>If you're going to be wasteful in the name of simplicity, you might as well use Python.
Put a low limit then, just a few MB and force your program to fit it - gonna be way better for your ram usage in the end.
And as a user I actually appreciate programs with constant memory usage because it means I know when I'm likely to need swapping or not.

>I think you understand that applications such as a video player or a compression tool don't know their memory requirement at startup
>but can only estimate an upper bound after openning a file
"at startup" = "some init function"
Point is global lifetime, i.e no need to delete anything.

>A compression tool for example theoritically has a huge upper-bound in memory usage
You always have a maximum bound for the bitstream block you process, you definitely don't wanna allocate anything in the middle of a decompress loop, that would definitely impact performance severely.

>You vastly overestimate the cost of allocations in most desktop programs.
No, they are actually the things that show up most often as hotspots in my experience.
Most programs are not number crunchers.

>because what I'm advocating doesn't preclude using a different allocation strategy.
But RAII is completely useless for those patterns.
I practically never use unique_ptr, in fact I almost have it as a litmus test - if I find myself reaching for a unique_ptr I have failed in designing my chain of ownership, why doesn't this function already have a context with all the data it needs already (or a manager to dole out a new reference)?

>>52942672
Let's be honest, this isn't the most compelling comparison. Most things are better than C, even CS students first C dialect.

>>52942773
>>52942796
I'm not sure Mozilla taking it hostage and Samsung shitting it up like Kies give me confidence.

>>52943231
Too bad there are effectively memory leaks when using lazy evaluation.
Uriel didn't die so that you faggot can have monad lifts.

>using a cuck language

>>52942381
I code le code with Kotlin (Java code coder) and it's garbage.
Complicated, too many ways to reach the same code and you can't do this
a = b = 2
or kek? k : ayy

>>52944860
>RAII absolutely doesn't preclude using allocation in a larger pattern than the exact point of use
Well obviously you can RAII the memory pool handle - but that is basically inconsequential, it's gonna have a long enough lifespan that it's not a big deal to manually free.
And of course I do write my containers that way, but I would have no problem using or maintaining code which uses manual alloc/free for them because I want to know where the 'seams' of the allocation boundaries are anyway (for performance and diagnostics reasons).

>If you only have one or a couple allocation, then this is not an interesting problem
Well I did start off by saying I find unique_ptr largely useless, which sparked your rejection of that claim.
unique_ptr IS for single allocations with unique ownership bound to scope - and I have very few of those in my programs, so few that it would have zero impact on reliability or maintenance burden if they were in the language or not.

RAII is wonderful for locks, synchronizations one-off file reads and things like calculating data around blocks like timing diagnostics, but I rarely use it for memory.

>>52945231
>Allocation is very often the bottleneck these days.
Memory access is very often the bottleneck, allocation, I have rarely seen that.
In any sane application the bottleneck is in the loops, where you obviously don't want to call the allocator.

>Most of my optimization work through the years dash been optimization string handling, and in the majority of cases it was extraneous allocations being the culprit, using static char arrays or string pools was the best solution many times.
If string handling is your performance bottleneck, either you have only worked on large tangled business logic that performs no expensive computation, you're working on a parser, or your codebase is so hopelessly inneficient you're 10x away from even seeing what optimized C++ can do for you.

>Put a low...the end.
>And as a user I actually appreciate programs with constant memory usage because it means I know when I'm likely to need swapping or not.
As a user I have enough memory to not worry about this, but still want my free memory used as a disk cache, not wasted by applications.

>Point is global lifetime, i.e no need to delete anything.
This seems like an extreme overreaction to me. Memory management is not the root of all evil that must be avoided at all cost.
It has a price, but there's a reason everyone under the sun is happy to pay it.

>No, they are actually ... in my experience.
>Most programs are not number crunchers.
I would love to see your profile numbers because this is unbelievable to me. I can only imagine that you work on abysmally unoptimized codebases.
I'll be happy to take a look at your VTune or prof samples or real-world applications.

>But RAII is completely useless for those patterns.
It seems to me that you stick to one pattern you know and refuse anything else.
This is extremism and suboptimal, use the best tool for the job. Often, it's RAII. Sometimes RAII is no more practical, but will still help prevent errors and help static analyzers.

>>52943219
>Dependent typing isn't going to stop someone from writing a program to dump their credit card database to port 80 if the typing is sound.

Ok, so just to clarify for the retards in the audience, that's not what "safe" means, but it is a logic error.

"Safe" means it won't segfault. Not that it's "dangerous, spooky code"

>>52945434
>Well obviously you can RAII the memory pool handle - but that is basically inconsequential, it's gonna have a long enough lifespan that it's not a big deal to manually free.
Yes, in this scenario RAII is not particularly helpful. But what I find remarkable is that it's not worse.
Whereas where you have to do close-up manual memory management with short to medium lived objects, automatic memory management is wonderful.

>And of course I do write my containers that way, but I would have no problem using or maintaining code which uses manual alloc/free for them because I want to know where the 'seams' of the allocation boundaries are anyway (for performance and diagnostics reasons).
I'm personally fine with using raw pointers or other low level ""dangerous"" techniques to build abstractions. Although I still prefer smart pointers simply for the sake of enabling code analysis, and consistency.

>Well I did start off by saying I find unique_ptr largely useless, which sparked your rejection of that claim.
I claim that RAII in genera is useful and often better, unique_ptr being just a form of that.

>unique_ptr IS for single allocations with unique ownership bound to scope - and I have very few of those in my programs, so few that it would have zero impact on reliability or maintenance burden if they were in the language or not.
I will remark that unique_ptr is for allocation of a single object of a type, but also for an array of objects of that type.
Just like new is for the allocation of a single object and new[] the counterpart for arrays.
There is an equivalence here, what you can build with new you can build with unique_ptr, including abstractions and containers.
Saying that you have few of these is silly, everything you build on malloc/free has a direct equivalence.

>RAII is wonderful ..., but I rarely use it for memory.
That's a valid style, and I know it can work well. I argue that we have better.

File: apple_swift_2_thumb800.jpg (13KB, 800x450px) Image search: [Google]

13KB, 800x450px

Too bad rust was BTFO already

>>52945581
Swift literally loses to Python in benchmarks, you have to try pretty hard to sink that low.
Even Apple didn't build anything meaningful in Swift...

>>52943219
>Dependent typing isn't going to stop someone from writing a program to dump their credit card database to port 80 if the typing is sound.

who knows - someday we might have this.

the _only_ reason we don't have this today is no one has figured out how to express independent systems at a type level.

For example, this is what I'm thinking about

type Port80[A <: AnythingButCreditCard]

I don't know if that even makes sense today - but it would be cool to have that.

>>52945593
>Swift literally loses to Python in benchmarks,
untrue since 2014

Swift 2.0 fixed the array sorting implementation. Swift code is compiled on LLVM too, so there's that. Given that swift uses ARC instead of compile time reference de/allocation i don't know if it could ever be truly as fast as Rust on paper.

>>52945442
>Memory access is very often the bottleneck, allocation, I have rarely seen that.
Memory access is coupled with allocation.
RAII is not suited for SoA at all for example (you typically would not allocate the arrays in any individual objects constructor, and you often want precise control over where the arrays are allocated).
And for hardcore memory shuffling we're talking dma and allocating stuff on accelerators/gpus which requires manual allocation and manual memory barriers even.
>or your codebase is so hopelessly inneficient you're 10x away from even seeing what optimized C++ can do for you.
Unfortunately too may codebases are hopefully inefficient, and they are inefficient at the stupidest fucking things like reading in configuration files which slows down program startup by a noticeable amount to the point of annoyance when trying to optimize the actual meat of the program.

>but still want my free memory
Yeah, the eternal trade offs.

>I would love to see your profile numbers because this is unbelievable to me.
Maybe because I hate doing it I'm biased in my recollection, but I do spend why too much time optimizing stupid shit.
The biggest wins in absolute numbers are rarely in the allocation sure, but they take way too much time to fix because they have wide code impact (often need big restructures), and they often impact startup/shutdown or things like loading spots which has a high 'annoyance factor' compared to say getting N tflops to 2N tflops in some loop.

>It seems to me that you stick to one pattern you know and refuse anything else.
I do use RAII (see >>52945434) just not for memory.

>>52945763
>Memory access is coupled with allocation.
It really shouldn't in many cases, it's a sign that you load things in memory that you aren't really using.
If you have a short to medium lived object, it should probably go on the stack if at all possible. If you need a longer lived object, chances are you will do multiple pass over it, completely overshadowing the cost of the allocation with the price of the memory access. If you actually use the memory you're allocating, the allocation cost is negligible.

If the cost you're seeing is from allocating a lot of rarely used objects dynamically, consider a custom access inneficient but very fast allocator or even lazy loading, because the bottleneck really shouldn't be here.

>RAII is not suited for SoA at all for example (you typically would not allocate the arrays in any individual objects constructor, and you often want precise control over where the arrays are allocated).
Yes, SoA is an annoying situation and sadly compilers are not even close from being able to transform AoS -> SoA.
Howether often SoA means the struct will simply free its arrays in its destructor - textbook RAII - or long lived arrays that are allocated along with some resource being loaded, such as a level of a game or perhaps an image file, so it would be natural to deallocate in these resources' dtors.

>And for hardcore memory... and manual memory barriers even.
At this point building meaningful abstractions is a little more tricky, when you need that level of sophistication, you'll necessarily be exposed to the low level details. memory-barriers.txt is not fun.

>Unfortunately too may... actual meat of the program.
I'm very glad to be shielded from that in the teams I work with.

>Maybe because... stupid shit.
>The biggest wins in absolute numbers ...in some loop.
Yes, that's a different problem.

>I do use RAII (see >>52945434) just not for memory.
Yes, I exagerated somewhat, sorry for that.