/tech/ - Technology★

No point in discussing, C++ devs gets ultra defensive and butthurt at any sort of criticism of this god forsaken language

>How you would fix it?

>Go!

You already described the solution in your post

/thread

>>931329

That's called C, bloat lover.

>>931330

>GC'd languages and manual memory languages are comparable

Gas yourself.

I think c++ is better than C because it is c + new stuff. You can compile c code in c++ compiler and get the same binary and most of the c++ stuff that makes programming easier doesn't have any overhead. For example class methods are exactly the same thing as normal function that takes a pointer to some struct object and does something with it (same mechanism). Constructors and destructors are also a very good feature, you don't have to call free () / destroy() type of functions manually, although you can if you want to and that's great, you have options to go low or high depending on your needs.

The standard library is also very good, people writing c only might scoff at it but it's rare that you can write faster implementation than what's in STL nowadays. Also c++ can do a lot more at compile time than C which of course is very good for your program. For example if you have some array that you update as you are writing your code (a table of functions for example) in C you often see that they make the last entry 0 and do a loop untill they hit that zero or they have to manually update the array size (some #define func_count 10 etc.) but in c++ you can take the size of that array at compile time.

C++ is strongly typed but you can still do C casts or just disable compiler warnings if you really need that.

I like C and when I have to just write something fast I usually start with c, but if I need some hash table or just expandable container I'll just use the c++ map or vector instead of writing my own.

There's couple of things I don't like in c++ though. Streams are for niggers, printf for life. shared pointer in single thread program is also a sign of mental retardation. Returning or passing by argument of large objects (you can do that in c but it's mostly c++ programmers that do that) is something I despise. I don't like references. They are basically pointers but look like the object when used which is just hiding the fact that something is a pointer. What's the point ?

>>931222 (OP)

>How you would fix it

Throw it in the trash, start over with C11 and add basic features like constructors/destructors, default values for structs, optional function arguments, and variadic arguments (no, C's stdarg.h macro bullshit isn't a good variadic arguments system). Also add dynamic arrays and improved string mechanics.

I could also complain about syntax but soon it'll just be better to just use a different language.

>>931346

GC issues are overrated. Especially considering you'll have to manually develop a system to manage memory that most likely will be only slightly more efficient than the GC.

>>931352

>dynamic arrays

you mean std::vector?

>>931355

This. I know everyone on /g... I mean /tech/ is an embedded chipset firmware developer, but in the real world GC is very much worth the extra 0,05% of performance you lose on your shit program anyway.

>>931350

>I don't like references. They are basically pointers but look like the object when used which is just hiding the fact that something is a pointer. What's the point ?

You cannot pass a null reference, so having a reference as a function argument protects you against segment violations. Of course, you can always do (*(void*)0) to get a reference to NULL, but that's dumb.

>>931375

No. I mean dynamic arrays. Take your """vector""" and shove it up your ass along with C++ itself. If we're fixing C++ then we're renaming the C++ "vector" into dynamic array.

>>931385

You know vectors are dynamic arrays, right?

>>931352

So you're saying you want D? Honestly, consider it. If you're okay with having a GC or are willing to work around it or turn it off, D has an incredible, cleaned up feature set that puts C++ to shame, in my experience.

You can't have a good discussion about C++ on /tech/ as it's too complex a language for anons and it's also too mainstream which makes it uncool.

But I'll just kill a few shit arguments while I'm here.

>C++ is more bloated than C

C++ is no more bloated than C as it's almost fully compatible with C. It gives you more tools, and they're dangerous tools that can lead to bad programmers easily creating bloat. A valid criticism of C++ here is that it makes doing the wrong thing easy, and that a "bad programmer" to C++ is a Godlike programmer to today's software landscape, so it's difficult to find anyone these days that can wield it effectively.

>(GCed language) is better than C++

GCed languages are incompatible with a lot of things people use C/C++ for. I use it in networking where the "GC only takes 10ms!" hype of Go sounds absurd when you consider how many packets would get lost on a 10GbE network during that 10ms. Brief blackouts like that do a lot more damage than you'd probably think as it causes rate control algorithms to panic since the RTT is nearly in nanoseconds on those networks. It can take a while for a network to recover and stabilize.

>D

D is a joke. I'm not sure why so much effort has been spent trying to make a dead horse race.

>>931429

>C++ is no more bloated than C

How can you say such bullshit and look yourself in the mirror?

du -h /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libstdc++.so.6.0.22 /lib/libc-2.26.so
13M     /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libstdc++.so.6.0.22
1.8M    /lib/libc-2.26.so

>>931429

>as it's almost fully compatible with C

I don't think you know what 'compatible' means. C++'s name mangling is everything but compatible.

>>931429

>D is a joke.

Why?

>>931222 (OP)

Let me contribute to this obvious datamining thread, lol.

>Are you for or agnist these:

>- Templates

For, when used for containers and certain helper functions (sparingly).

Against when abused for template metaprogramming.

>- Standard, C++ specific libraries

For. In fact I'd wish they'd go all the way and completely deprecate the C subset of the library. C++ is not C, never will be C, so let C++ not be C. Stop trying to embrace, extend and extinguish C by saying "here, C++ includes C stuff though they're incompatible with the C++ stuff." malloc vs new, stdio vs iostreams, rand() vs <random> and so on. Cut the bloat, clean up C++, and stop trying to kill C, Stroustrup you fucker.

>- How classes and everything related to them works

Against, mostly. I'm a brainlet and I can't think through multiple levels of inheritance. Inheritance is a sort of obfuscation. If you're stuck in a plain text editor, without doxygen docs that include a list of the inherited functions, or IntelliSense giving you hints, you're dead meat. You look at the class definition source code, and it's incomplete. The inherited code is effectively hidden. Go open another file, then another. That's redirection, and it's bad for the brain. If you're a brainlet like me at least.

>Generally, is(and why) C better than C++?

It's simpler and has the potential to be more elegant. No invisible exceptions that swim beneath every line of code, but never seen outside of try blocks. No invisible function calls (ctor, dtor, overloaded ops) behind your back. No overloaded functions and templates so that you never quite know for sure what gets called without checking the argument types first (which is a pain without IntelliSense hints).

>How you would fix it?

How to fix C to make it better? Well I'd make arrays and strings first class citizens (no more decay to pointer) and with automatic memory allocation and deallocation, but not necessarily by way of garbage collection though. Basically I'd look a way to make working with strings painless and take away memory allocation/deallocation control from the programmer so that he can focus on actual work not bookkeeping.

>>931449

>Garbage collected

>>931456

You're making yourself look silly by dismissing a language just because it's garbage collected. What other reasons do you have for not liking D? Yeah, yeah, now stop giggling like a schoolgirl, at the "D". I've used D for little exercises, its library is so much better than C++'s, by design. It's very practical minded. It even has a library for MD5 checksums.

>>931457

>dismissing a language just because it's garbage collected

as long as they don't shill it as a c/c++ / rust alternative thats fine. otherwise fuck off

>It even has a library for MD5 checksums.

oh shit nothing else has that!

>>931459

>D being shilled as alternative to Rust

Oh, so that's what your problem with it is. Rust shill attacking D because it's a competitor. OK, got it.

>oh shit nothing else has that!

Well C++ doesn't have that, and it's nice to have practical stuff in the library. Think how you'd go about implementing MD5 on your own, in pure C++, using the stuff from <algorithm>. It would be a huge PITA, don't you agree, which goes to show the library of C++ is maybe too minimalist for a supposedly high level language. C++ says "here, have some bricks, wood and glass, build yourself a house." At least C gets away with minimalism because instead of heavy bricks it only gives you a shovel to dig yourself a foxhole. Just be careful not to bury yourself.

Best standard template library coming through

https://github.com/electronicarts/EASTL

>>931222 (OP)

>How you would fix it?

The problem with C++ isn't the language itself but the majority of people who use it. So many times I have looked at "C++" code on github, sometimes from large companies such as Nvidia, and seen nothing but the most atrocious C code imaginable. It seems most people "use" C++ purely for the ability to say their project is written in C++ and not for the actual benefits it provides such as templates and classes (and by extension the absurdly powerful things they allow for).

>>931460

> Rust shill attacking D because it's a competitor. OK, got it.

>Think how you'd go about implementing MD5 on your own

You would never do that because its retarded. You would import the algo portion of same *SSL implementation and use that.

>>931477

snd line

*I hate rust

>>931350

>C++ is strongly typed

gfo

>>931380

the only way GC wouldn't be useful for embedded systems is if they have really low RAM. luckily today an embedded system is just windows 10 running on a rasberry pi with 4GB RAM and 2GHz CPU

>>931457

>It even has a library for MD5 checksums.

what the fuck is this some kind of b8? D is stupid for the same reason C++ is stupid. precisely because both languages could even have, nevermind a library, but an MD5 operator and MD5 syntax and the users would still take it seriously

>>931488

C++ is much more strongly typed than c

>>931329

For science and engineering, Julia looks VERY promising, but it's taking forever to reach 1.0.

>>931489

>luckily today an embedded system is just windows 10 running on a rasberry pi with 4GB RAM and 2GHz CPU

Pretty much tbh, I work in what is technically embedded, and most devices have 256 or 512 MiB of RAM and a relatively good ARM v7 processor, which runs a full version of Linux 2.6.x.

>>931538

Conveniently ignoring throughput. GCs can only balance between those two.

>>931329

Go

>>931350

>references

The alternative is ugly as fuck and unsafe unless you always put the referenced value on the heap. References solve that problem because they can't be null (except without horrible, deliberate abuse that a typical C++ noob would never think of doing), so you know it's valid.

>>931538

If you knew how generational GC worked you'd know you can produce all sorts of fake speed numbers for it by ensuring all your data isn't in the generation that needs swept. Real programs that grind a lot of data rather than just idle with a large heap by necessity require large sweeps and that takes a large amount of time. There's no way around that, it's like trying to go faster than the speed of light.

>>931434

You don't have to use libstdc++, newfriend. C++ is no more bloated than C.

>>931434

Rust wins again. How will sepplesfags ever recover?

du -h .rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-ddeed4efba8e9952.so
9.3M	.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-ddeed4efba8e9952.so

>>931843

C and C++ are not even related. Stroustrup just happens to allow certain C keywords to work, but the way C++ operates is in no way the same as C.

>>931843

Find me a compiler as simple as tcc or pcc for C++. You won't find it because the language is bullshit with an ambiguous grammar. And if you want a "clear" argument, look at the number of keywords:

http://en.cppreference.com/w/c/keyword

http://en.cppreference.com/w/cpp/keyword

Another one:

> archive-extract.sh -d . /usr/portage/distfiles/gcc-6.4.0.tar.xz
> du -hd0 gcc-6.4.0/gcc/{c,cp}
1.7M    gcc-6.4.0/gcc/c
9.7M    gcc-6.4.0/gcc/cp

>>931849

As much as I hate C++, Rust with its soyboy NodeJS style crate system is even worse.

http://esr.ibiblio.org/?p=7303

https://medium.com/@CBowdon/esr-is-right-about-discovery-cost-and-rusts-stdlib-c7a1839dca8e

For more. There's something between an empty stdlib and Python.

>>931854

Not everyone wants a bloated std.

>>931856

Better than three gay student projects fighting to do the same thing. I'm perfectly fine with something like the POSIX API, at least its reach and size.

>>931850

>C and C++ are not even related

Jesus fuck anon, there's stupid and then there's whatever that was.

>>931873

Genius, because I don't fall for that "C++ is C with classes" myth bullshit.

>>931851

All I hear are tears. Who fucking cares how complex the compiler is? It just has to run fast and produce good output. As a language, C++ is no worse than C and can be used as just a massively improved C at zero cost if desired. If you end up with bloated code, it's entirely your fault.

anon@anon:~/tmp$ cat foo.cc
#include <stdio.h>
int main() {
  printf("What's the matter anon, can't into C?\n");
}
anon@anon:~/tmp$ g++ -static-libstdc++ -O2 foo.cc && strip a.out && ls -alt a.out
-rwxr-xr-x 1 anon anon 6304 Jun 18 13:16 a.out
anon@anon:~/tmp$ gcc -O2 foo.c && strip a.out && ls -alt a.out
-rwxr-xr-x 1 anon anon 6304 Jun 18 13:17 a.out

>>931879

You're comparing apples and organges when comparing C and C++. Sure they are both fruits both programming languages and both are round similar syntax but that's about all the similarities you can get out of them. C++ is fundamentally different than C because it had a fundamentally different invention than C.

>>931879

>it's not bloated

>w-who cares about bloat, it's useful bloat!

When it's harder to find a thing your language can't do than one it can, you know it's time to stop. C++ is just an enterprise garbage where they can put what they want in the standard since they don't care about design, only about their own 20% of C++ they use. As >>931450 said, if you want some "high level zero cost" bullshit that will swarm with invisible stuff going on, C++ is for you.

You can read http://harmful.cat-v.org/software/c++/ for more (especially the Links part). To be really honest, what made me stay really far of it is the overly complex syntax and the horribly dense cruft of decades of piling up shit on C instead of creating a really new language; Rust seems like a cleaned up C++, even if it has a Perl style abortion of a syntax; still not a replacement for C.

>>931889

Probably why I pointed to the Links section, retarded tripfag.

>>931893

Thanks for C++99 related links. Sure does speak a lot about modern C++.

>>931889

>>931897

trip fell off

Why do people get so angry about C++? It's a good language.

>>931886

>whining about bloat

The post you're replying to showed it has no bloat. 'C++ is bloated' is a meme created by bad programmers who write bloated code and blame it on their tools. It is no more bloated than C.

>cat-v

wew. Who are you going to refer to next for sage advice, Terry?

>Rust

Rust is a meme. It was clear when they froze 1.0 in a useless state that the project would never go anywhere as they don't think it needs to. It's a NIH Ada that is only usable on toy projects.

>>931901

Because it's hard, and modern programmers bitch and moan at anything more difficult than jQuery rather than man up. Low T soyboys and transfaggots everywhere.

>>931901

It's a pain in the ass and I'll be old by the time any of the things to alleviate that pain clear the committee.

>>931916

It was fine after C++11.

>>931912

It's not hard. It's stupid and encourages bad practices.

>>931922

It's hard. Avoiding bad practices is hard.

>>931926

It's not even used in the military if it means additional costs for the program.

>>931923

Using a language full of bad practices is stupid.

>>931929

Yes anon power is dangerous. Most things should not be written in it. However when needed there is no alternative. For the most part no one should be managing their own memory directly. But when you are writing something like say a game engine or a simulator you need that.

>>931926

Because it was created as part of a contract for the military.

Probably the only language with a back-door in it.

>>931933

The only reason why you would consider doing that is 1) you trust whoever wrote your compiler and 2) you are incapable of understanding how the machine works.

>>931222 (OP)

>Templates

I do frequently use it. I do accept that if done way to much it might make the code look like a total cluster fuck that take more time to read. I also dislike the fact it has to be always declared in the .hpp file.

>STL

I've once heard a teacher that told us that for some performance issue, it is possible that we might ignore the STL and roll up our own data structure. Up to this date, this scenario never happenned to me.

>How classes and everything related to them works

shit is lit'

>Generally, is(and why) C better than C++?

I prefer C for the simplicity. Every programmer should be able to program in C.

>How you would fix it?

I'd appreciate if we could use an enum class has the key of a std::unordered_map.

>>931939

What the fuck are you on about.

>>931937

That's C. "Reflections on Trusting Trust" is not hypothetical.

>>931946

Just use tcc first to bootstrap your real compiler and its all solved

>>931945

I am saying that compilers are not written by (you) and that (you) cannot know how the machine works unless documentation is provided. It's not that difficult to write an optimizing compiler. The only difficulty in it is time.

>>931948

Look faggot the same thing applies to an assembler, it applies to the hardware itself, it applies to everything.

>>931952

No shit numbnuts. You aren't biding your case.

>>931955

What is your fucking point? You have not made one so far. Just repeating obvious shit.

>>931956

My point is that everything is suspect in this botnet world regardless of open source or free software or whatever gay ass label you want to give it. You won't audit several million lines of source because you don't want to or don't have the time. What do you think the probability of anyone wants to audit that code and has and is willing to give the information they learned out? Any software that parses information can inject malicious code into a machine, and the machine itself now has malicious processes designed within it. It's worthless to argue about which language is better or which architecture is better because it's all compromised since for at least a decade. If anyone cares about having a truly free and truly open platform with truly free and truly open hardware and software then there needs to be a fundamental push by the community with real backing to move it forward. If all anyone is willing to commit is to tweet this, share that, like these, then nothing will be accomplished.

>>931968

And what the fuck does this have to do with c++ discussion that does not apply to literally everything that exists?

>>931926

Entry-level cliff.

People program in C and C++ because there are free C and C++ compilers.

Any idiot can shit out a slow, buggy, inefficient C or C++ compiler and it can grow to be a more efficient, less buggy compiler. Ada has a test suite that has to pass. You can't fake it till you make it. It is perceived that Ada is a more complex language, because the compiler has to actually work, whereas a C or C++ compiler can leave out any feature of the language the writer doesn't care about. That's why there are ton's of free, shitty, C and C++ compilers, and only one free Ada compiler (which the Air Force paid for).

>>931977

>whereas a C or C++ compiler can leave out any feature of the language the writer doesn't care about

Bullshit they won't be able to compile any real existing code base.

>>931968

>What do you think the probability of anyone wants to audit that code and has and is willing to give the information they learned out?

This happens regularly, it is not an isolated practice. Just because you don't know about doesn't mean it doesn't happen.

>>931980

> Bullshit they won't be able to compile any real existing code base.

You would be surprised at how many features of C andC++ aren't used by many real existing code bases.

>>931986

>That's why there are ton's of free, shitty, C and C++ compilers, and only one free Ada compile

There are 4 major compilers that all support the features of c++ 11. ICC, GCC, Clang, MVC++. These are fast and feature complete systems.

>>931986

>You would be surprised at how many features of C andC++ aren't used

like what

>>931987

And how many iterations did it take for these to become fully C++ 11 compilers? They picked a handful of features of the language to implement and did so. GCC isn't feature complete: it lists "Minimal support for garbage collection and reachability-based leak detection" as not done. And it is that pick and choose attitude that exists for C and C++ that is why there are so many more compilers.

Every feature that was in C++98 and was deprecated or removed in C++11. No one ever implemented export. std::auto_ptr was garbage and few used it.

There are code bases that don't throw exceptions. I wouldn't miss std::complex. I watched a video that implied the Ubisoft insisted on writing its own version of the STL for "Sanic Speed!!11"

>>931996

>GCC isn't feature complete: it lists "

You do realize garbage collection is not a feature of c++ and that is an ultra fancy add on that they are playing around with?

>>931996

>>931996

>Every feature that was in C++98 and was deprecated or removed in C++1

<Features that are deprecated are not supported

well no shit

>There are code bases that don't throw exceptions.

<If it exists anywhere its standard

>I watched a video that implied the Ubisoft insisted on writing its own version of the STL for "Sanic Speed!!11"

This is pretty common

>>932005

That GC thing is actually in the C++11 standard. It's just a couple basic things so that someone could implement a GC within the C++ memory model (or something like that). Nobody cares about it. Calling GCC not feature complete because of that shows >>931996 doesn't know shit.

>>932011

>That GC thing is actually in the C++11 standard

Point out exactly what you mean in the standard. You don't have to cite the standard document itself, a site that says its in the standard is fine. I am again calling bullshit.

What c++11 DOES have is custom allocators that you can plug into numerous parts of the STL and that IS well supported.

>>932011

Okay so I went and found an actual gcc site referencing your thing.

https://gcc.gnu.org/projects/cxx-status.html

There is a total of ONE thing, and thats it that is not supported. That ONE thing is not supported by ANY of the compilers, and was strictly declared as an optional extension.

>>932011

>Calling GCC not feature complete because of that

Thank you. That was my original point. People writing C / C++ compilers can ignore whatever they want in the standard and call the compiler feature complete. They can leave out the entire standard library and call the compiler feature complete. You can't do that with the US Government's Ada Standard: you either support the language as confirmed by a test suite or you do not. And because of that, and because most software developers are lazy, they say "fuck that, I'll write a C compiler".

>>932005

>You do realize garbage collection is not a feature of c++

What do you think unique / shared pointers are?

>>932015

Not garbage collection. Shared pointers have strict dealloction, cannot support cycles, are created explicitly, etc.

>>932014

>People writing C / C++ compilers can ignore whatever they want in the standard and call the compiler feature complete.

Bullshit a SINGLE FEATURE, universally not implemented by the core 4 compilers, that is an OPTIONAL EXTENSION, does not make your point. If it was say 10 different things mixed between the compilers you might have a point but you dont.

>>932015

I hope you're only pretending to be retarded as that's pretty embarrassing otherwise.

>>932014

It's the weakest example you could have used and you act like it proves that GCC is made by lazy people who are leaving out half the standard. I even agree with you that it's better to have standards for your standards. But your point about compiler writers being lazy is just weird. The big 4 are massive pieces of work and C++ compilers are notoriously hard to write.

>waaah these languages aren't feature complete because they've removed incredibly bad ideas like gets()

>>931856

But the C++ STD lacks features, anon. There still isn't a DateTime class, still no standard networking...

>>932193

Not literally everything has to go in the std

>>932016

Yes, it's a simple refcount based garbage collector.

>>932079

Nope, and if you can't see smart pointers as being a form of garbage collection maybe you should learn how the language works.

>>932308

>Yes, it's a simple refcount based garbage collector.

Wrong. A garbage collector implemented with ref counted smart pointers is not the same thing as a smart pointer.

>>932315

When your smart pointer goes out of scope it literally calls delete on the object inside. How is that not garbage collection?

>>932319

Sometimes terms have meanings that are more than their literal words. When people talk about GC, they mean automatic GC systems that search for unused objects. Deterministic destruction like C++ has not the same thing.

>>932319

oh shit I did not realize that rust was garbage collected

>>932319

>visting /tech/ for the first time since a year because nobody had any idea about computers work

>see this

Bye guys.

>>932338

oh no not blogposting sagefag. Xe will be missed.

>>932328

Yes, smart pointers are a poor GC which can't handle circular references nor compacting the heap to avoid fragmentation. It also frees objects as soon as they go out of scope instead of waiting for an appropriate time to do so (depending on your application this matters a lot). It's so bad that people are afraid to call it a GC.

>>932338

Oh great UNIX master, do elaborate on how pointing out how I was incorrect on how it works. Is it that you can supply your own deleter instead of the regular delete, or are you to embarrassed that it's such a poor GC that you don't want to call it that so it doesn't get made fun of?

>>932343

Take the L, dude.

>>932205

C++ is garbage before C++11. I maintain a lot of code written before C++11 that abuses boost shared_ptr so we could use STL containers without it deleting everything due to the lack of move semantics. It's disgusting runtime bloat to patch a bad language.

>>932362

Feel free to tell me where I'm wrong. To me it looks like you are just insulting me since you can't find a reason.

>>931438

ABIs that are sensitive to mangled names are dead artifacts anon. time to let go and move on.

>>931438

>what is extern "C"

>>932361

>shared_ptr is runtime bloat

top lel

>>932527

Maybe you should step through some code that uses a vector of shared_ptr with a debugger, tripfag.

>>932527

No shared pointers are a runtime cost, simply because the owning objects have to be reference-counted before pointer deletion.

Unique pointers OTOH, are not a significant runtime cost (in essence no more than regular C pointers) because no reference-counts need be monitored.

The premiere benefit of C++ of C is it's low to no-cost abstractions. Performance in terms of speed is often quite similar.

>>932539

>of C++ over C*

>>932539

Prior to C++11, anything like a unique_ptr wasn't usable at all in STL containers and shared_ptr's non-trivial semantics required STL containers to juggle references constantly and emit the full versions of methods. After C++11, shared_ptr can be used without all that extra cost as STL containers will use the move constructor (and unique_ptr can be used instead). If you've got a project on C++03 or C++98, you still have to deal with the bullshit.

Kiddos learning C++ today have no idea how shit and unfinished the language felt before C++11, and what a massive improvement it was.

>>932545

No debates from me on your points. I programmed in the language prior to C++0xb, and it definitely feels like a new language today. Now if they will only give us Modules, Concepts and a full Ranges standard it will be much better still. At the least it's clear this language isn't going the way of the dinosaurs anytime soon.

>>932535

Yea there's ONE increment of ONE integer per copy. BLOAT!!1!!1!!

I agree that shared_ptr is abused a lot when unique_ptr would suffice, but stop sperging out on overhead that's utterly irrelevant.

>>932539

The overhead of shared pointers is so irrelevant it doesn't even make sense to complain about it IMO.

>>932553

I'm certainly not complaining about it anon. I'm merely explaining to anon he misunderstands what's going on if he believes it to be cost-free. It isn't, and if you're in a hot-loop where it matters then it can be a significant overhead.

But the fundamental point of using them in the first place is that if you actually need shared pointer like functionality, you very likely can't possibly do better than C++ Standard Library std::shared_ptr -- in any language.

>>932553

It has to be updated synchronously is the problem. That reminds me of a story from a guy who was optimizing Facebook's code. It turned out that their pajeets had been passing shared_ptr by copy all over the place and ruining performance.

>>932559

>pajeets fuck up

>ITS THE FAULT OF THE LANGUAGE

lol retard

>I'm too retarded to understand memory management so I need magic safety pointers

>>932567

>I am a nodev and have never done any real world programming

>>932568

>if you don't want automatic memory management then you're not a real programmer!

>>932564

>brainlet inferring

You have to be aware of the overhead, that's all I'm saying.

>>932569

Well, pretty much, yeah.

>>932553

You really should run a debugger on the code, tripfag. Or not. It's not like you program anyway, you don't need to know.

>>932580

>STILL not knowing shit about smart pointers

>>931329

>Still no better language around than C++ tho

Literally anything is better than the latest C++ spec, except Javascript.

>>933443

Which part specifically do you have problems with.

Fucking niggers in this thread complaining about which type of pointers are more bloat than others.

ALL POINTERS ARE BLOAT

All indirection is bloat, fuck your pointers.

Fucking niggers.

>>933747

>I'm too retarded to use pointers so I need the language to handhold me and pretend they don't exist

>>933749

>I use a pleb language with "hidden pointers"

Of course I don't. That's even worse!!

>>933750

You think copying memory is less than bloat?

>>933740

There's always betterC mode.

https://dlang.org/blog/2017/08/23/d-as-a-better-c

>>934233

>Simple means better

You know whats simple? The lambda calculus. You know whats simple? Brainfuck.

>>934733

>You know whats simple? Brainfuck

Minimal =/= simple

>>933740

I don't get it, are you a masochist? Why would you want to spend hours of your life in Valgrind for a speed benefit that may not even exist?

>>934933

Which is the trap c falls into

>>934933

what the fuck yes it does

>>935433

Properly written C++ doesn't need valgrind for leaks.

>>935512

Properly written anything never needs anything.

>>935513

No, there's a big difference between C-like C++ and RAII C++. 'Properly written' C++ is where almost all of your destructors are empty as you're forcing the compiler to write them for you. Your code either runs or crashes, but doesn't leak.

>>935521

>if you don't use malloc you will never have space leaks

LOL even java / javascript / python / ruby / etc have leaks and they use garbage collectors

>>935521

>>935525

>>935512

You can use C++ with just smart pointers and will only leak when having circular shared_ptr references which are pretty easy to figure out and debug.

>>934227

Thats interesting, the only issue is that the benefit probably isn‘t large enough to warrant a widespread switch. Also, C++ compilers and the general ecosystem is much more mature, im sure C++ beats D in performance when it comes to standard containers and so on, unless D directly transpiles to C++.

>>935433

>why is a large industry delibaretly avoiding GC at the cost of development speed

<non-determinism

<speed overhead

<memory overhead

Of course this is irrelevant in many applications, but in some it is not.

>embedded

>anything security critical

>hard real time systems

>most soft real time systems

>quant finance

>video game engines

>>935525

You're confusing memory leaks with memory capture.

>python

You're really confused. It has its own unique problem.

>>935528

>You're confusing memory leaks with memory capture.

lol no "memory capture" is not an industry term. Even managed memory environments can have space leaks.

>nd will only leak when having circular shared_ptr references which are pretty easy to figure out and debug.

anon space leaks can happen without circular references

>>935530

Didnt‘t know that, how?

>>935531

By not having the reference ever go out of scope.

>>935532

Well, then its a question of the definition of leaking. I‘d say a leak is a part of occupied memory that can not be (deliberately) accessed by the application. If the pointer is still in scope, it is still relevant to the application even if the programmer does not think of it as relevant.

>>935535

>then its a question of the definition of leaking

I am using the standard industry definition of memory leak

>>935536

That is?

>In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations[1] in such a way that memory which is no longer needed is not released. In object-oriented programming, a memory leak may happen when an object is stored in memory but cannot be accessed by the running code.

https://en.m.wikipedia.org/wiki/Memory_leak

>>935529

Hello from industry. No one calls what you're referring to "leaks". If the program could still free it, it hasn't leaked.

>>935536

Are you an FP guy?

>>935539

Literally everyone calls them memory leaks:

- https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

- https://plumbr.io/blog/memory-leaks/what-is-a-memory-leak

- https://blog.fugue.co/2017-03-06-diagnosing-and-fixing-memory-leaks-in-python.html

>>935540

no

>>935539

>If the program could still free it, it hasn't leaked.

This is just wrong.

>>935541

Literally only webdevs confuse this issue.

==1672== LEAK SUMMARY:
==1672==    definitely lost: 0 bytes in 0 blocks
==1672==    indirectly lost: 0 bytes in 0 blocks
==1672==      possibly lost: 0 bytes in 0 blocks
==1672==    still reachable (but totally a leak because some webdev born after this tool was written said so on his blog): 19,764 bytes in 23 blocks

>>935541

>listicle

>javascript

>.io

Refer to wikipedia for the proper definition >>935538

By this completely vague definition the discussion becomes completely moot as anything and everything would risk „leaks“.

>>935544

>>935543

I gave java, python, and node code as examples. I don't even use any of that shit.

>s anything and everything would risk „leaks“.

Everything does risk leaks except for shit that has been mathematically proven not to

>Refer to wikipedia for the proper definition

Well lets see what wikipedia says "in such a way that memory which is no longer needed is not released". So wikipedia said the same thing I said lol.

>>935545

>mathematically proven not to

Such a proof does not exist. By your definition a stack variable in a 20 line function that is no longer used after line 10 is a leak. Stop embarrassing yourself.

>>935527

>You can use C++ with just smart pointers and will only leak when having circular shared_ptr references which are pretty easy to figure out and debug.

< mfw I work with people retarded enough to fuck this up

Hey /tech/, I have a geometry question for you:

Our code base has a function that takes a (latitude, longitude) point, an azimuth in degrees east of north, and a distance in kilometers.

It is supposed to determine the (latitude, longitude) point distance away from the given point in the given direction.

There was one unit test for this function that got disabled at some point, then the code of the function changed, then someone took it upon themselves to re-enable the test.

> The sign of the resulting longitude changed.

Given the inputs, can you determine the correct sign?

< starting at (0N, 0E)

< 25000 km distance

< 45 degrees east of north

Also:

< Result is ~145ish degrees

< positive longitude is east, negative longitude is west

>>935560

>25000 km

wat

>>935557

>its called formal verification

Im proud of your basic knowledge of computer science, i didn‘t say hoare logic does not exist, i said nothing could be proven to not „leak“[1] as you can construe any existing memory as not considered relevant by the program author. There is no hard, technical definition, thus there is no proof, which would require a hard, technical definition. There is nothing wrong with the sentence „Stop embarrassing yourself“ by the way, but you criticizing it as improper english is pretty ironic.

>>935560

Tbh it happens easily in large codebases, especially if shared_ptr is used where really you should be using a custom reference counted handle. At my job we‘re working with a large, messy entity component system that communicates with an asset manager, and shared_ptrs are stored all the time for the wrong reasons in chaotic places. At this point it would require much more work to rework things instead of debugging a leak once in a while.

>>935564

> i said nothing could be proven to not „leak

Except you literally can. Do you not know what formal verification is? Lol.

>as you can construe any existing memory as not considered relevant by the program author.

Its easy, you just say, will this memory ever be used again by x point in the program, and if the answer is no then its a leak.

>There is no hard, technical definition,

I just gave you one

>There is nothing wrong with the sentence

No there is nothing wrong with that sentence. Perhaps if you understood context better you would have fewer English problems.

>>935569

>will this memory ever be used again by x point

>hard definition

>contains a variable that varies per case on an arbitrary basis

>definition breaks completely if x is set to a point before an additional usage of the memory

wew, ill just stop talking to you anon

>>935572

>>definition breaks completely if x is set to a point before an additional usage of the memory

lol no

>wew, ill just stop talking to you anon

please leave

>>935539

I come from the Java side of things and yes we call it a memory leak. When we notice that some of our servers (we have hundreds of them) are continously using more and more memory overtime and stuff is not getting freed like it should we call it a memory leak. It doesn't matter if technically that stuff could still be freed somehow. If there is garbage which is not being cleaned like it should, we call it a memory leak.

>There is no hard, technical definition

In the context of an application there can be. For example when a user disconnects from one of the servers mentioned above all of the data related to them should be turned into garbage and be collected.

>>935581

How do you say 'memory leak' in punjabi?

>>935581

Sure, perfectly valid. Its just that this is a different class of leak, i’d call it a semantic leak or something along those lines. It doesn‘t make sense to discuss GC in terms of these leaks like a certain incessant retard ITT is trying to.

It's like the oppression olympics with the webdevs and pajeets trying to claim they suffer from big boy problems, too.

>>935583

I don't speak punjabi, nor do I know what it is. Is it referencing pop culture or something? If so, I wouldn't get it.

>>935587

>Its just that this is a different class of leak

No its called a memory leak because it leaks memory.

> It doesn‘t make sense to discuss GC in terms of these leaks

Look retard its a memory leak because it leaks memory. Every person calls it this, from academics, to industry. Would you say Java cannot leak file handles because the user is not directly using the system call? Retarded.

>>935591

This

>>935581

That makes more sense with a GC'd language. In C++ if you're accumulating more and more memory it's probably either a real leak or a problem where calling it a leak is unsatisfying, like when you have data structure reserved memory that grows but never shrinks, or you're straight up not erasing data from a structure that you should be, which would affect behavior too.

>>935613

>not erasing data from a structure that you should be

Yeah this is a big problem with the stuff I'm working on. If an inexperienced developer accidently stores an object instead of the id related to it and forgets to remove it from the list, that one object in the list can cause that object and everything it holds to be retained in memory as opposed to just a simple id for it being leaked honestly if we leak something small like that it doesn't matter too much. Of course we want to have it correct but since or servers restart semifrequently as long as we don't leak too much too fast we are usually all fine.

>>935613

> it's probably either a real leak

The probability of it being a leak where the reference was NOT lost is not magically decreased with c++. Its just that the chance of leaks where the handle was lost are so common in c++.

>>936505

A whole class of leaks in Java become dangling references in C++.

>>936547

Same thing

>>936551

But in C++'s case the memory is freed.

>>936553

Java cannot have dangling references because it is garbage collected. C++ is just as vulnerable to standard memory leaks as a garbage collected language, and vulnerable to EVEN worse leaks where the program loses the handle.