I also use C++ everyday, and find it quite powerful, but I also feel that it is ill designed. The other day I had to work with code that involved a public member function that returns a private type. You can only bind to the return value of this function with auto (because the type is private), but can otherwise do anything with the object. Why this is allowed is beyond me.

You're right that much of the software we use is written in C++, for good reasons, but asking people to "use a product of another language" just because they are critical (in a not so nice way, admitted) of it is going a bit too far. It's like asking someone to move to a different country because they think their system is "broken beyond repair".

Your design above with the private type being returned could possibly be useful. Perhaps outsiders to the class will be prevented from instantiating the nested-type without using the class itself to generate the nested type. This could be contextually useful and certain (interface) functionality could be grouped in a manner that is more convenient to use than by calling methods on the original class.

I like that C++ allows us to express this situation, even if it's a bit of an unusual design pattern.

You can prevent instantiation of the nested type already by using private ctors and friending the wrapper class from this type, while keeping the class itself public. That is a much cleaner expression of intent. I believe that if a class is usable via its interface, it is public any way (in that you will need to go and change all uses of this object should you decide to change the nested type's API, whether it is declared private or not).

And also note that binding to the object at all has been possible only after C++11, while this "feature" works with earlier standards. That rules out the possibility of this being designed into the language with the express goal of achieving what you say (it doesn't matter, but just pointing out).

Visibiliy has always been sabout naming thing. You were always able to bind private types to template arguments (otherwise you would never been able to create an std::vector<PrivateType> or pass MyPrivateContainer to an std algorithm. What's new in C++11 is the ability to also bind locals, but that no more powerful than what you could do before (via a CPS transform).

I use this case quite commonly for implementation encapsulation. You could think of it as a capability.

The type of a lambda is inexpressible so they can only be handled with auto or decltype. I think that’s reasonable.

I am curious how you achieve encapsulation this way, please elaborate (I tried to find uses for this pattern. Even the author of the code I'm talking about, and other much better C++ programmers than myself seemed to call this an oversight rather than intent).

Here's a simple example: I have a table of stageful actions (perhaps part of a UI) that is dynamically constructed and maintained. I could register token which looks up the necessary information in an internal hash table. Of course said internal table would have to stay in sync with the UI's table. Instead I can just return an opaque object (perhaps a virtual object if life is fancy) with all the necessary state; if the UI window is deleted then all the objects will be deleted too at just the right time, with no explicit coordination with the part of code that created them (their destructors could do some bookkeeping if appropriate).

Traditional callbacks can also be used in this case, but what is a callback lambda but private state? And a stateful object rather than a lambda function is easier to manipulate, say by inspecting in the debugger or perhaps by providing a generic function for things like printing the entry.

Another case is where you have some hairball third party or legacy library that you want to be able to use in your modern code; you can often simply make it an opaque private object rather than making a complex visitor for it.

I kind of understand what you describe, but I still don't understand why the type needs to be private. You can return opaque objects of a public type just as well for this job, can't you?

    class Token {
      virtual ~Token();
      protected:
        friend class MyClass;
        ...
        /* all your state */
    };

> what is a callback lambda but private state?

You can (and do) program to the callback's interface -- say you ask for an std::function<void()>, and the user gives you that. What is behind the function (private state or not) is not your concern, you simply perform an public operation (calling it) on a public interface (i.e., via std::function).

What is the difference to you if I pass a private object or a public object all of whose instance variables and methods are private? Either way the point is to say “this is not your object to manipulate”. But making it a type you cannot even express makes that far more explicit.

I see, I guess then that's where we disagree. It is very confusing for people from my limited experience, for little gain. Plus you make it harder to do things like put these tokens in e.g., a vector without resorting to decltype.

Going back to the original point i was making with this example, I still think this was probably not a capability consciously designed in the language.

I agree this is weird, but isn't it pretty similar to the old c pattern of returning an opaque handle? I'm assuming you can't do anything with the object, since you don't know its layout and its member functions would be inaccessible. it sounds like you just get to hold onto it and pass it to any accessible functions that take it as an argument. am I misunderstanding how this works? I can't find any resources that directly explain this situation.

You can do member access into the object! That breaks encapsulation or whatever was the reason to keep the type private. Passing it around usefully isn't possible except to friend or member functions of the same class (since you can't write a function taking a type T that is private to your scope). In fact the only reason I could think of for doing something like this is to prevent people from including this type in their APIs, while still allowing to work with the object. But there are better ways to do that, including just exposing what the little object would expose via direct method calls on the enclosing class.

This isn't similar to C handles. There is usually a public API around the kind of the handle (e.g., the file oriented syscalls that works with file descriptor integers). In such cases, C handles are more like "this" pointers with an associated API.

Also, it cannot be the intent of allowing this pattern to implement opaque handles, as you can bind to them only after C++11 (auto), while such malformed code still compiles (including member access into the returned temporary) with -std=c++98.

ah okay, looks like I was mistaken. it's pretty hard to see how this could possibly be useful.

With bricks you can build a useless house with no doors, but bricks are pretty great.

I mostly agree with you, but operating systems and web servers are generally written in C and not C++. For example Linux, (the vast majority of) GNU, Apache, and Nginx are all C.

(Though I expect your parent has similarly negative views on C?)

To balance with what you say:

Windows is mainly C for the kernel, and C++ for the rest https://en.wikipedia.org/wiki/Windows_NT#Programming_languag.... That's around 90% of the desktop/laptop market.

IIS, Microsoft's web server, is C++ https://en.wikipedia.org/wiki/Internet_Information_Services. I think it is still the 3rd most popular web server in the worldwide.

A significant portion of the C++ code in Windows uses very few C++ features or idioms and is basically C with classes or one or two useful features.

That's impossible. According to half of the comments in every c++ thread on HN, any usage of C++ will immediately converge to using all features!!

/s obviously.

Which is still C++.

It is, but I do wonder if a large part of the problem with regard to using C++ features on Windows is the poor support for it in the ancient COFF linker and binary format they support. Lots of stuff like template export is possible with ELF which is impossible or dangerous on Windows.

I can also attest that lots of “modern C++” code exists in Windows.

There is code in Windows that was written yesterday and code in Windows that was written over three decades ago.

COM/UWP is the proper way to use C++ features on Windows in a inter-language way.

While not ideal exporting templates has been possible since Windows 3.1 days, as long as one sticks to a specific compiler.

Absolutely, but that kind of code doesn’t really speak to complaints about modern C++ and all it’s become. I just wanted to chime in with that extra information. I don’t really have a dog in the fight, other than having a lot of love for C and good C code.

You are correct, thanks. My comment comes across as very irritated, but it's the same argument that will continue to the end of time I guess - "this tried, tested and widely used language is broken because it is not language $x and because it lacks this edge-case invented usage scenario even though it works adequately for 99.9% of all other scenarios as demonstrated by decades of use". It's wearying. Sure, C++ is complicated but so is English!

I thought nginx was C++?

I also thought large portions of Windows are C++? Everybody loves COM!

Nginx is C, and the authors really don't like C++.

(I used to work on ngx_pagespeed, which was a C++ server module that plugged into Nginx to rewrite pages so they would load faster.)

Thanks for the info!

Did they approve of your module?

They liked that we were building something cool for their server, but our approach was so different from theirs (in ways that went way beyond the language) that our module wasn't ever going to become officially part of Nginx or anything.

No my terrible grasp of English even as a native speaker is the cause of this confusion. What I meant was: “No I meant that from cppreference using coroutines means you can’t use the features I mentioned not that those features don’t exist in c++20“

There's no reason that any of those couldn't be written in c++ by good coders. It's just a historical thing.

My parent was arguing "C++ can't be as bad as you say, look at all these things written that use it". Things written in C are not evidence for this, anymore than things written in assembly.

it's obviously possible to make useful things with c++. I too do this every (week)day.

imo, the biggest issue with c++ is the lack of orthogonality. there is usually a "best" way to do something, but you have to read a lot to choose between the many other ways of doing it. the usual "best" way may not be applicable in your case because it is subtly incompatible with some older feature that's already being used.

as an aside, I always get a kick out of standard library functions like std::addressof. you have to use stuff like this in highly generic templated code because you can't be sure that some clown hasn't overridden the `&` operator for some type that will eventually be passed to your function.