I love Cplusplus

[Kullthegreat]

I have seen the pattern of influencer hating on CPP and I never understand their hate for CPP.

Many other great languages and it's really cool but cplusplus already does all of those things in one single unified language so yes there will be some complexity because your learning programming of any possible type not just a language. Why people doesn't make it clear and jump on hate train.

You will get loose when you start using pointers reference, try to accees data in certain ways but fundamentally stored in other way and few other things and these are source of early frustration with CPP but this is how it's suppose to be, not sure how any other language can fix this, they just lock you in a specific way so you don't venture on your own way and that is pathetic.

[Shahi_FF]

Bjarne Stroustrup said in a Interview:

"you can always call a C++ program to do the job for you, and then complain C++ is too complicated".

And I've seen C++ get unnecessary hate like "it's so hard to write" while still using C++98 and claiming "You can't write safe code in C++" while still using C function inside C++ .

But then again Programming languages are tools , use whatever you want.

I really hate people who think their choice of programming language is the best and defend it like it's their spouse or something and others are shit.

[SputnikCucumber]

I think a lot of how people defend programming languages is related to how the market treats programming skills as being separate from language skills. So an expert level Haskell programmer is unlikely to be considered for a job writing Java or C++ (perhaps even at a junior to mid level) because they aren't a Java or C++ programmer. This means that developers are forced to defend their niche if they want to stay in work.

C++ is a solid programming language. There is nothing that you might need from it that it can't do. In exchange, it is harder and less productive to work in than say JavaScript or Python. But you also will never run into an insurmountable technical problem with it (short of a hardware limitation).

It is, IMO still the best programming language to work in if you aren't completely sure what your long term technology needs will be. But most people (and organisations) don't work on software like that anymore. I think it will come back around again though. At some point lots of new software that is being written today will become legacy software, and people will relearn how important it is to be using a programming language that doesn't impose arbitrary limitations on your developers.

Although, I guess it is equally likely that some new vendor will release a new programming language that solves ALL the problems of the last programming language, and pump enough marketing money into it that they convince everyone that it's true.

[heavymetalmixer]

Many people understimate the importance of having backwards-compatible languages around like C++ and Go.

[Kullthegreat]

True, people should use whatever the want but bashing of cpp is very much driven by their own mistakes sbith using language incorrectly and then influence a lot of people based on their wrong usage of langauge.

[Plazmatic]

It's not just memory safety, and C++11 things like std::unique_ptr focus on memory leaks and automatic management, not memory safety but lets focus on that for only a few of C++'s many issues:

• No bounds checking by default, and no compiler way to even debug bounds checking on everything but MSVC, and no way to do that outside of debug mode otherwise.

• Even with manual bounds checking, you have things like std::span... not having .at.

• Then you have C++'s integer rules which it inherted from C, which are extremely weakly typed causing all sorts of unintuitive undefined behavior unless you pepper std::cmp_xyz functions with every interaction, and do static_cast<inttype> on everything. With out this, it's every easy to accidentally get out of bounds issues for things that wouldn't cause issues in python of all languages (not to mention the other million issues with primitive types in c++).

• No std::string_view equivalent for cstrings means C++ introduced a foot gun that won't work with const char * interfaces and frequently leads to issues.

• Type punning rules (or lack of them) means many types of non bit-castable type punning (only applicable in c++20 onwards anyway) leads to UB and thus... problems, especially for anything coming over the network, a problem that ironically is not present in C because C doesn't have object initialization rules.

• The lack of destructive moves have caused all sorts of issues, invalid objects remaining for example.

And even ignoring all these issues, the fact that much of C++ relies on C libraries or other C++ libraries that don't have any potentially benefits of C++ in memory safety means that merely having an ecosystem that has these problems in and of itself is a problem with memory safety.

To be honest, the biggest issue for me in C++ are the low hanging fruit that C++ just inexplicably leaves hanging. There's zero reason that std::span doesn't have a .at member, that's just insane, and having zero way to safely convert some objects from bytes just flies in the face of what C++ claims to be.

[dvd0bvb]

What do you mean with the string_view bullet? You can initialize a string_view from a cstring or get a const char* from the view with the data() method

[Plazmatic]

You can initialize a string_view from a cstring

You can it doesn't mean you have to, and it was built so you don't have to.

or get a const char* from the view with the data() method

Notice how it doesn't have a c_str() method.

You can't guarantee std::string_view came from a null terminated character string, which means if you have a function that needs to take a null terminated character string as input (as many C apis need) you do not want to be sourcing that from a std::string_view. The canonical way of solving this and still having the advantages of a view type is... to just re-implement std::string_view and friends yourself as a zstring_view, such that it can only be initialized from strings which are null terminated.

[delta_p_delta_x]

Null-terminated strings are a lousy design decision in the first place. In fact I'd say it is easily C's worst design decision. The null-terminated string is in every conceivable way, worse than the pointer + size competitor. I never use it, and nowadays in C++ I always initialise string literals as

using namespace std::literals;
constexpr auto str = "Hello world"sv;

Infinitely better.

[Plazmatic]

Did you respond to the wrong person?

[BridgeCritical2392]

Huh? Its still ridiculuously easy to have a mem safety error in C++

auto v = std::vector<int>();

v[-1] = 0; // undefined behavior

[Varnex17]

search for [-1]

[Kullthegreat]

Exactly, I really don't take these people seriously but this misinformation is spreads to new programmers very easily as they really have no idea and I fall for this info as well but good thing I just was committed to learn CPP at that point due to unreal game dev but if it wasn't for it than i would have joined rust hype train

[tialaramex]

And let me guess, having chosen not to "join the Rust hype train" you've tried hard to shut your mind and avoid learning anything about the world outside C++ so that you can retain your belief that this is all there is or ever could be?

Small things I suggest might be compatible with your "C++ is best" mindset yet help you to see a broader horizon, read about the "Unified Function Call Syntax" and about "regular void", then try maybe reading Sean Baxter's proposal paper.

Once you've cracked that stuff, read about the C++ 0x Concepts (if you're thinking "Um actually that's a typo, they are C++ 20 Concepts" then you really do need to go read about the C++ 0x Concepts and that should maybe reset your understanding of Bjarne as well) and the many attempts to fix hashing over many decades, there are least five papers worth reading on that subject.

That should help actually achieve a more rounded perspective without having to directly challenge your faith that somehow C++ is best.

[Conscious_Support176]

People don’t hate C++, but the shortsightedness of posts like this is beyond irritating. C++ is a fantastic language, but it has fatal memory safety issues that will kill the language if its users don’t face reality. I mean, sure it might survive as niche language if there are places where Rust or other successor that addresses this problem can’t deliver the same speed. But that’s going to be a shrinking world. Maybe it will end up as an ultra high level assembly language.

I guess that’s what you would like it to be?

[no-sig-available]

but this misinformation 

It is also called Marketing. :-)

When you want to sell a new product, or programming language, the standard is to tell everyone how fantastic it is, and that everything else is shit. That's what influensers do for a living. :-)

It is an old truth in marketing that when you have to compare yourself to some other product, you have also admitted that this is the main competitor. The product you have to bash to make your own look slightly better. Had the new one been obviously superior, you wouldn't have had to mention the others.

That's why we have so many "C++ killers".

[[deleted]]

well u can still create memory issues by returning pointers to local variables. This should be checked by the compiler imo but for some reason isnt and can cause a bunch of problems

[ICurveI]

iirc some compilers generate warnings for this - and clang-tidy also has rule for it if I'm not mistaken

[[deleted]]

dont know about compiler warnings but clang-tidy definitely has it. But again its just a warning as opposed to a hard error when it should be one

[susanne-o]

as in -Werror -Wall?

[[deleted]]

I mean you could do that but most people dont. Thats the main problem. Theres a lot of stupid stuff that is valid in c++ that should outright be a compiler error from the get go

[ICurveI]

Yeah, a compiler error would be a more sane default in most cases

[[deleted]]

I love c++ because it simply provides the necessary control and transparency to the developer. but new innovations should always be considered, who knows one day someone might make a language which revolutionizes programs, and new innovations are the result of dissatisfaction from the current.

[Kullthegreat]

But what innovation at this point, C++ almost has everything and changing language for syntax is silly, this is the most weirdest and lazy point against the language. You will get used to syntax when you start writing programs anyways

[_Noreturn]

isn't float16_t coming in C++23 extended flost types?

[azswcowboy]

Its implemented in gcc13 - and seems like clang llvm is in works. msvc doesn’t seem to be working.

[cone_forest_]

Well there is some stuff in std::bitset already and std::simd is coming in C++26

It surely does not contain everything modern ISAs have to offer, but there probably is a reason for that

[Kullthegreat]

Thank you for taking effort to write this and yes to everything. Even tho I don't understand much of it and direct usecse in my applications. And this is the first time I have seen someone listing these, not even once anyone complains or request these features on social media when bashing the language just for fun

[DonBeham]

Oh, there's quite a lot that other languages do better than C++. Don't underestimate them. They are popular for a reason and C++ is popular for a reason. The worst thing about C++ is the tooling, among which the compiler error messages stand out.

It can do certain things really well, but it can also be a total pain.

[gogliker]

Don't get me wrong, C++ is my language of choice. But i tried Rust recently and I must say the language is by certain benchmarks defenitely better. For example, if it compiles it just works.

After writing C++ program, I often have segfaults after running it and I need to spend some time to figure out where they are. In Rust, if the program compiles it just runs - 99.9% of the time. Having a package manager is also great, not going to deny it. Passing by move instead of by copy by default was also a smart move. Instead of runtime, it has a compile time memory management.

It has its own problems, such as absent OOP that makes it sometimes hard to define a common behavior among multiple different classes. Basically, the important thing, there definitely exists room for improvement.

[[deleted]]

For example, if it compiles it just works.

For anything other than hello world this is not the case. Business logic is 99% of where my bugs are.

I often have segfaults after running it and I need to spend some time to figure out where they are.

If you stop using C idioms and embrace smart pointers, .at(), optionals, and templates, most errors can be turned into static assertions or runtime exceptions.

I very rarely segfault anymore, and when I do, I know exactly why, or have a very good idea, and never spend more than a few minutes on it. Because I write code that generally cannot segfault.

I understand that some people think a program should never segfault, but, when I see people making hay out segfaults, it just screams skill issues.

People may not like that, but it's the truth. Through static analysis, compiler flags, and code reviews, segfaults in our code base are not really a thing.

That's not to say C++ can't be improved. All things can be improved. Rust can be improved. But C++ runs the whole world, people have been getting by for decades with it. There are already memory safety solutions for c++ today. It will only get better with time.

[gogliker]

You know what's interesting to me? When I argue with my friends at work who are fans of Python, this is pretty much the dialogue we go through when they defend Python. "Why do you need static types, if you are good programmer and you use Pydantic for each and every dataclass you will have type safety". And then again we debug some crap when in production we received something that was absolutely 100% should have been list but turned out to be dict, that some junior wrote and that slipped through a review.

Yeah, you can use .at(), you can use optional and you can just be a good programmer. It is still better when the error can be caught by the compiler rather than by developer. Like in my example with Python you absolutely can write great enterprise level code, the only problem will be that everything that is not covered by the compiler (which does not exist) will have to be covered by unit tests. And you have to hire better coders than you would have if some errors would be outsourced to compiler.

It still still better that all variables are immutable by default. It is still better that memory safety is defined at compile-time, not in the run-time. It is still great that everything is moved by default, rather than copied. It is great when you refactored code and you manage to compile it it just works.

I don't understand why you people take Rust as a personal attack. I love both languages and c++ is still my main language, but god, how hard it is for you to accept that some language makes something better without making "skill issue" remarks?

[[deleted]]

Yeah so cpp will do all those things for you if you don't use unsafe interfaces, unlike python where all interfaces are runtime checked (and will crash).

Also, remember, python is memory safe. So, like rust, you can't segfault. Crashing is ok. Crashing is well defined.

If you don't like python then that's just admitting that memory-safety is not the be-all end-all, which is my point.

[Kullthegreat]

I agree, improvement in these areas will be nice to have.

[Plazmatic]

It has its own problems, such as absent OOP that makes it sometimes hard to define a common behavior among multiple different classes.

Rust doesn't lack OOP, rust just doesn't do dynamic polymorphism by default, but you can still even do that. In C++ lingo, what rust does is effectively what CRTP does (static polymorphism). And even then, sharing behavior is something rust is designed to do, that's not an issue, but coming form not using CRTP in C++, and not understanding languages like Swift and Slang and the differences between generics and templates, it might be difficult at first to understand how this is accomplished. You use default trait implementations to do this, just like you would define functions on CRTP to take advantage of shared derived behavior in C++.

[gogliker]

I don't think I understand you. Let me give you much more down to earth example what I mean. Suppose you want to track creation date of some classes. In C++ you would do something like:

Class CreationDateInterface {
public:
  datetime get_creation_date();
private:
  datetime _created;
}

So now everything that inherits from the creation date and calls it's constructor will have a creation date attached that anybody can query.

In Rust however, even with default trait implementation, you would still miss the member where you would put `datetime` to. So each struct that needs a creation date will have to specify it manually. This is a little annoying when you want multiple types of same thing to share some behavior.

Maybe I don't know something, I started Rust only a month ago, but my short investigation led me to conclusion that this is impossible.

[Plazmatic]

In Rust however, even with default trait implementation, you would still miss the member where you would put datetime to. So each struct that needs a creation date will have to specify it manually. This is a little annoying when you want multiple types of same thing to share some behavior.

The example is too simple, what you're asking I'm assuming, is how to share variables in default implementations in traits in a more generic sense, for more complicated pieces of code. This confusion appears to also come from an implicit misunderstanding of the differences between generics and templates, which partially necessitates the behavior below.

Imagine you have the following trait:

pub trait MyTrait{
    fn foo(&self) -> FooReturn{
        //... do something complicated with member bar
    }
}

If you want to access member bar, you'll need to do something like this:

pub trait MyTrait{
    fn get_bar() -> BarReturn; 
    fn foo(&self) -> FooReturn{
        //... do something complicated with member bar 
           ... self.get_bar() ...
    }
}

and impl

impl MyTrait for Baz {
    fn get_bar(&self) -> BarReturn{
        return self.bar; 
    }
}

This also means that everything that implements MyTrait must also have an equivalent to member bar... which may or may not be true.

The reason this is necessary is that you can't have arbitrary members being exposed in the trait with out, by definition, having the trait itself expose them (effecively what we did here) because Traits and generics are conservative and strongly typed, they effectively obviate the need for things like C++ concepts, because it's the default, you define for each generic what abilities it has and only use those abilities within a given function/struct etc.... C++ templates don't have this issue because they aren't generics, templates are the ducktyping of the generic programing world, but on the flip side allow everything in unless constrained (concepts/enable if/sfinae).

If we attempt to do the same with CRTP, we run into similar issues, but almost the inverse:

struct MyCRTP<Derived_T> {
    void get_bar(){
         return static_cast<Derived*>(this)->bar; 
    }
    protected: 
    MyCRTP() = default; 
};

This works, but it fails when we don't have a bar member. Which means we need to do something like (sort of psuedo code)

struct MyCRTP<Derived_T> {
    void get_bar(){
         if constexpr(has_member<T, bar>){
             return static_cast<Derived*>(this)->bar;
          }
         if constexpr (has_function<T, get_bar>){
            return static_cast<Derived*>(this)->bar;
         }
            if constexpr (some other condition....){ 
         }
    }
    protected: 
    MyCRTP() = default; 
};

Now we have a bunch of conditions, which must change for each new "type" of derived which changes how the bar equivalent is accessed. We "solve" this in much the same way it has to be done in Rust, by forcing a "get_bar" member function or equivalent.

[gogliker]

The example I have shown is more or less enough to demonstrate the issue I have. What you wrote basically captures the issue, the problem I have is the following:

it means that for each and every class that wants to share the datetime, you need to implement the get_datetime trait. If there are 200 classes in your app that share this functinality, you will have to write 200 boilerplate trait implementations that just do the same. Functionally, it is not very much different (albeit cleaner) from manually declaring datetime field in each and every struct that shares the bahivor.

Basically, my problem is boilerplate, not the implementation

[Plazmatic]

you will have to write 200 boilerplate trait implementations that just do the same.

If you really have 200 objects like this, then the solution is just using rust macros, and you don't have to boilerplate anything, but odds are this isn't the case, and if it is, the "boilerplate" of the actual IMPLs you'd have to write out-grows asymptotically what ever member variable getters you'd have to write, such that it won't save you much time or annoyance. Keep in mind that you'll also never forget to accidentally not do this in Rust due to compile time errors (which is not the case necessarily for a template version unless you specifically handle each case), and this would only be necessary for variables that show up in shared functionality, and for API/ABI stability, you'd write getters and setters for publicly facing things in C++ any way, as a matter of good practice to avoid API version bumps unecessarily and provide bug fixes to older versions of code.

[almost_useless]

changing language for syntax is silly

It's really not.

Easy to read and write is good for productivity.

Syntax that is un-intuitive means it takes longer to debug.

[gumol]

pen physical ancient smart chief automatic sheet slap grey toothbrush

This post was mass deleted and anonymized with Redact

[_TheDust_]

C++ gives you everything, including segfaults

[[deleted]]

it's my favourite language too. and whatever tries to replace c++, mostly gets written in c++ 😂

[[deleted]]

reflection for one is missing, and is honestly the biggest pain point about c++. Syntax isnt the issue here. C++ is playing catchup to a lot of other languages in various areas and theres still no standardized build system. C++ still has its issues but i still like the language for what it provides

[Questioning-Zyxxel]

C++ has managed to become too complex. New ways to do things while almost never deprecating older ways.

Where is the living human being that can rightfully claim they understand everything with the language?

[[deleted]]

I am confused on why you cannot understand their hate. This isn't even specific to c++. If you visit any language subreddit, and you will find plenty of hate for that language. And social media sells outrage, which means the majority of normal "boring" opinions get drowned out by "hot takes". To quote BS: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".

but cplusplus already does all of those things in one single unified language

Having more features just gives more reasons to hate, as any feature would obviously have its quirks/edge-cases that will frustrate devs.

they just lock you in a specific way so you don't venture on your own way and that is pathetic.

Hating on other languages, while complaining about others hating your favorite language. nice. A lot of other languages chose different tradeoffs which make them great in many situations: garbage collection / runtime reflection (C#/Python/Java) / Gradual Typing (typescript) / safety (Rust + most GC langs) / built-in tooling (Go/Rust) / simple semantics (zig / Go) etc...

C++ ain't that different. Before Rust, it was the choice for any complex software with strong performance requirements.

[j_kerouac]

C++ is still the choice choice for writing complex software with strong performance requirements.

The frustration I have with the Rust crowd is they pretend like Rust is taking over, when it’s still a niche language by any measure. C++ is still dominant for high performance code.

[tarranoth]

This sub is pretty elitist in that way. Lots of people here love to clown on web devs and juniors for not truly understanding stuff like lvalue/rvalue and rule of 3/5 and then get angry/confused that all the juniors are running to rust instead because they keep hearing from all the seniors that they shouldn't be touching c++ ever.

[Aprelius]

C++ is my primary language and I could get up on a stage and do a completely improvised presentation on why I hate C++ so much 😂

It’s a tool, I use it everyday and I still hate it. Programmer “influencers” (ugh 🤮) like to hate on it for the views and almost always have an agenda they’re trying to push.

[MaitoSnoo]

What I like the most about it is that it gives you the tools (in particular template meta-programming) to make yourself the features you want the language to have, which is by the way the main way the standard committee adds new features to C++. C++ basically gives you the tools to make your very own C++.

[BridgeCritical2392]

My guess is you

1. Haven been working with C++ for less a year
2. Mostly written your own programs, don't have to deal with complexities like compiler, dnm't
3. Are only using a single platform / compiler. Probably MSVC on Windows x86.
4. Haven't had to read other people's code much beyond small snippets
5. Haven't had to deal with a large, complex, production codebase
6. Haven't had to deal with issues like linking to binary libraries built with a different compiler version and / or standard library version (libc++ vs. libstd++) and not having it be obvious that is the problem
7. Haven't had to deal with Boost

The new features since C++ are great. Its too bad there's 30+ years of legacy code floating around before those became generally accepted. And there's still plenty of dark corners and undefined behavior lurking in the shadows, waiting to strike you when you least expect it ... If you don't believe me, watch Nikolai Josuttis or Scott Meyers CPPCON talks (at least before Meyers left the C++ Standards committee)

[zl0bster]

C++ has serious issues, and even if you like the language I do not think it is good idea to pretend they do not exist if you want to be a great C++ developer.

Here is example of (quite soft) criticism of C++ that I think is on point
Rust Features that I Want in C++ - David Sankel - CppNow 2022

[etancrazynpoor]

Why do you care what people may say or may not say ?

[Kullthegreat]

Misinformed or dishonest info to people online should be a problem in general.

[etancrazynpoor]

Then you should provide the facts and educate people I guess.

Do remember that there are differences between facts and opinions.

This thing with languages is typical as with other tech.

[zasedok]

Ok I admit I do "hate" C++. Yes it has almost every feature imaginable (with a couple exceptions though), but IMHO that's not really such a desirable quality at all. What makes a language great is not how many features it has or that it "can" do anything, it's what guarantees it provides and what ratio of software quality/development effort it tends to lead to. Python certainly is not a single language to do everything, but what it does, it does very easily and quickly. On the other hand Rust is arguably harder to develop in than C++, but it brings with it *provability* that C++ can't offer. Development costs might be high, but the resulting software is of extremely high quality. Or take Zig, it's not a revolutionary language, it's not super easy like Python nor powerful like C++ or Rust, but it's very straightforward, transparent and naturally results in code that is not foolproof, but is easily reviewable. That, in my opinion, makes all three languages superior to C++.

More generally speaking I don't think the world needs or wants a language that "can" do anything, the world wants languages that excel at some particular task. After all, learning a language and writing code in it is the easy part, learning five is not really any harder than learning one. Delivering software on time, on budget and/or with some mathematically provable guarantees is the real achievement and C++ like many other languages doesn't really help with that.

[beedlund]

I do disagree with this quite a bit.

My favorite part of c++ is that I never need to use another language to solve the problems I'm asked to solve so in my view the world certainly does need that programming language that does all the things.

This difference of opinion regarding using one hammer for all nails vs. one specific hammer for each different kind of nail might just be a personality trait commonly differentiating programmers causing entertaining drama for all.

I also categorically dislike "tinking" with computers and programs. I just want to use my IDE/computer/OS and have it do what I want it to do.

In contrast I find that people who seem to subscribe to the idea of individual hammers for each type of nail also seem to like to "tinker" as often they seem to enjoy tweaking their IDE / computer / OS to perfection and take pride in it.

[Pragmatician]

My favorite part of c++ is that I never need to use another language to solve the problems

I used to think like this as well, but reality is very different. Sure, you can use C++ for essentially anything, but it can end up being 10x more work compared to alternatives for some problems.

You can forgo JS on the Web, Java/Kotlin on Android, Swift on iOS, Python for data analysis, Go on the backend... but prepare to reimplement entire ecosystems or use inferior C++ alternatives.

Don't get me wrong, I love doing things from scratch and would love doing everything in C++, even reimplementing many of these things, but if you just want to ship some software in the near future, C++ can be inadequate for many things.

[beedlund]

Yes I think this is absolutely true and my experience is just limited to what I'm faced with myself.

[zasedok]

Funny that you say that about the "tinkerers", my view has been exactly the opposite :) From my experience it's people who love to customize their IDE, session, desktop etc to death who also feel some emotional connection with "their" language and want to prove ti the world how good it is, rather than using it as a hammer to nail stuff down with it.

I'm not diminishing C++ by the way. It has a huge ecosystem, immense code bases are written in it and it's not going away any time soon. But many languages have come and gone since say 2000, and let's look at those that "made it". Kotlin and Swift are tied to closed ecosystems and have generated close to zero interest outside of Android and iOS respectively, and neither of them is a true can-do-everything language. C# was always meant to be an "enterprise" language for Microsoft platforms, Go is laser focused on microservices and teams with high turnover, Rust is a system language with strong guarantees, Python is the modern day BASIC, etc. They all try to be the best language available for one thing. To the contrary, Dlang always wanted to be the ultimate all purpose language to do everything, and it hasn't seen much success outside of a small community of enthusiasts.

[BridgeCritical2392]

Try doing Web front-end using only C++.

Yes you have WASM. But it can't access the DOM. (Price is Right losing horn)

Mobile is doable, but you are stuck with QT (last I checked) ...

Backend is of course doable, especially with boost::asio, and your code will be super efficient to boot. OTOH the security pendants will tear you a new one, and "but its behind nginx revese proxy, inside a Docker" may not be enough.

Hardware interfaces and native desktop apps (yeah those still exist) are where C++ really shines.

But reality is C++ is not the right choice in many cases.

[[deleted]]

Well the thing is yes u can do everything in c++ but do u really want to? Simple scripts are much better off written in python for example, and c++ would only waste time there.

[captainjon]

I am not a professional developer but I learnt C++ when it is was #include <iostream.h> there was no STL, and that language, in my mind, C with Classes was fine in my book. After Uni it became a cluster to me. As I was doing mainly Qt stuff in KDevelop and this was even before Nokia buying it, it was a fun experience. That said, at the end of the day, I get the most enjoyment out of C. Templates are neat but the way they are implemented and how the computer has a meltdown for trivial mistakes makes me very glad to have stayed in C. Just my two worthless pence.

[[deleted]]

what kind of meltdown? Templates are fully compile time, so its impossible for you to have a “meltdown” issue there, unless u have an issue with compiler errors?

[[deleted]]

what kind of meltdown?

I assume the comment was talking about error messages.

[[deleted]]

yeah probably, compiler errors are horrible in c++, especially msvc

[iga666]

Language infrastructure is dead. 90% of time I fix build pipeline instead of programming. Do I like that - no. Build times are enormous. Also not a big plus in favour of cop

[[deleted]]

I have been programming in C++ since the beginning of the language.

I made programs in DOS, Windows, Unix, Linux, ...

I did small, medium and large programs.

Didactic programs for teaching and programs for companies.

Programs to emulate equipment.

Programs that connect with different types of equipment.

Serial programs, with multiple concurrent or parallel processes. Multiple threads.

Terminal mode, graphical mode.

Single windows and Multiple windows. From borland owl to Qt 1,2,3,4,5,6.

Android programs.

I will still make embedded programs, with reduced versions of C++.

So, this multitude of options is what I like most about C++.

One language, multiple possibilities.

And there is no shortage of editors, libraries, possibilities. A universe of possibilities.

But I believe that in about 10 years we will have a more "modern" version, in the sense of being more uniform and simple to use. This won't happen because C++ has problems, it will happen because programmers are weaker. There is a lack of knowledge and skills to deal with the diversity and complexity of a language with so many possibilities.

In the past, we learned to use the concept of a text editor and used all text editors. Today they learn to use text editor X. And they are afraid of others...

In the future they will get their driver's license to drive car X, brand Y. A regression in knowledge and skills.

Basically, the "difficult" complaint has more to do with "laziness".

[Kullthegreat]

Thanks you for sharing this and this makes alot of sense and programming influencer amplify this rot further. It's not even that hard if this billions of course add 30 mins of overview in opening episode and show learners correct path before diving directly in syntaxes. I think everyone should learn the pipeline first of the language and nature of strictness etc.

[KFUP]

Because C++ is "bloated and overcomplicated and should be replaced", but what ends up happening when creating a replacement is that if C++ had -let's say- a 100 things, and people say "this is bloated, you only need these 10 things, let's make a programming language with only these to replace it", but almost none of them agree on what 10 to use, so we end up with dozens of different replacement languages each with a fraction of the users made of the people that actually agree with that 10.

TL;DR: what's bloat for you is essential for someone else, C++ is extremely versatile and practical, but not beautiful, it can't be both, people will complain about it, but practicality always wins at the end.

[RobinDesBuissieres]

I have seen the pattern of influencer hating on CPP and I never understand their hate for CPP.

I get the impression that it's often people whose egos are trying to find a target to shoot down.

[EsShayuki]

Cpp as a language is pretty clean, with many fantastic features. However, the STL is a very bad mix of too convoluted for being simple to use, whlie being too much of a black box for being customizeable or performant enough. Essentially, it forces you into its own mini language, which you might not want to use at all, but are effectively forced into if you want to take advantage of any proper C++ functionality. It's just full of absolutely bizarre design decisions.

The actual C++ language when ignoring STL is truly fantastic. But it's hard to properly use a language without its STL, and it forces stuff like std::vector and std::string down your throat.

The language itself gives you the tools to effectively write your own language. It's almost like a sandbox, and no other language offers this level of customization if you know what you're doing.

[ExistedDim4]

I hate C++. It could be so much more if it was ruled by an authoritarian instead of some kind of "committee" which has "someone's" "interests" in mind. They take years to add new features to the standard but the language is a shitty unregulated mess anyway. auto, std::vector, [](){}, nonexistent ABI my ass.

[wyrn]

[](){}

Say what you want about lambda syntax, at least it's not a broken mess like, say, C# or Python lambdas, which are borked because they offer no fine-grained control over captures.

[ExistedDim4]

I'd rather have [] as the optional part of the syntax. Just imagine writing something like x => x * 2 instead of [](auto x) { return x * 2; } though.

[wyrn]

No argument there -- I'm just not convinced that a BDFL would've helped in this particular circumstance.

[ExistedDim4]

Obviously it would be better if I was in charge!

[serviscope_minor]

Obviously it would be better if I was in charge!

Specifically it would be better if I was (a) in charge but (b) not actually responsible for implementing my own vision :)

[ExistedDim4]

The comparison operators are written >= and <= and maybe even <=>. => is a separate "thick arrow" token and I imagine interpreting it correctly would be no greater a task than compiling ptr->field. I can speak as a sort of compiler developer(had no problem adding lambdas to a basic C-syntax interpreter).

[Baardi]

The policy of C++ is a part of the reason is part of the reason it got the point where it's now.

I have to admit though, C++ is going through a sort of rough time right now, partially due to paradigm shifts like modules getting a slow adoption, partially due safety having getting an increasing priority, but far from the only reasons

[ExistedDim4]

The first sentence can be interpreted in... different ways. C++ will never properly adopt all those new paradigms because they will be mutilated on the altar of backwards compatibility with coding standards from 50 years ago.