Aggregated exceptions. I think I came up with a neat and complete proposal, but it's too ambitious for an existing language, given the changes it proposes and its relatively niche concern. We've migrated to VS 2015, so I've begrudgingly accepted
noexcept destructors. And since C++11, lambdas provide a practical way to solve problems where one might previously want to use complex destructors.So I guess we can live without multi-exceptions. Okay.
I then tried to float an
is_relocatable property. A shortcoming of C++ right now is that it allows object content to be moved; but it doesn't allow movement of objects themselves. Even though anywhere from 50% to 100% of the objects we store in containers can be moved with memcpy — formally, this is undefined behavior. This is a problem for container resizing, and requires inefficient deep copying when noexcept move construction or destruction aren't available — even though the objects could be moved with a trivial memcpy. Various libraries work around this by implementing their own "is relocatable" concept: Qt has Q_MOVABLE_TYPE, EASTL has has_trivial_relocate, BSL has IsBitwiseMovable, Folly has IsRelocatable. I also saw this need, and rolled my version of this concept in EST (not yet published), and in a previous version of Atomic/Integral (to be published — hopefully, soon).The need for a standardized concept is apparent. What I would most like to see is fairly simple:
- In
type_traits, a standardis_relocatableproperty. - A way to declare a type relocatable without exceedingly ugly syntax. My favorite:
class A relocatable { ... - To avoid unnecessary declarations leading to developer mistakes, a way for the compiler to infer that an obviously relocatable type is in fact relocatable. For instance, if type
Stris relocatable, then the following should be also:struct A { Str x; };
It is possible to infer this in a safe way by limiting this inference to types where (1) the compiler declares an implicit move constructor, and (2) all direct bases and non-static members are relocatable.
There were people who staunchly opposed even adding a property — even though this one is needed, and current
type_traits is littered with them (and those are also useful).In fact — there had been an attempt to propose this as
is_trivially_destructive_movable. This was shot down by the C++ committee because it would require conceptualizing the idea that object lifetime is "ended" at one address, and "begun" again at another address. This is too much of a conceptual problem. (Even though object lifetime doesn't end — it just continues...)Not to mention the wall of opposition to any kind of compiler inference of a
relocatable property. Notwithstanding that this would be purely an improvement; wouldn't break anything; and would allow this optimization to fit in with every day use.Exasperated with this failure to find support for what seemed like a modest and innocuous improvement, I tried the least contentious possible idea. Can we just have a version of
realloc — we could call this version try_realloc — that tries to expand the memory in place, and fails if it's unable? In the absence of a relocatable property, containers could at least use try_realloc to try to expand existing memory in place, before committing to a potentially deep copy.Everyone agrees this is a good idea, and it turns out something similar had been proposed.
But it didn't go anywhere. Why not?
Well, the person who wrote that proposal couldn't afford to take a week off to travel to a C++ working group meeting to champion and defend the proposal. And so, it died that way.
Open standards — if you attend our meeting in Hawaii
Nominally, the C++ standardization process is open. In practice, it's gated by who can justify sending representatives to week-long meetings in far-off places. These meetings take place two or three times a year, and the next one takes place in Kona, Hawaii.It goes without saying that, if you're not present on at least one of the full WG meetings, your chances of making an impact on the C++ language are slim, at the least. As the preceding anecdote shows — if you don't attend, forget about even something as trivial as a
realloc improvement.This wastes resources on travel; excludes people who could contribute; and silences worthwhile ideas that don't happen to have a champion with disposable time and money.
About a decade ago, I participated in SSH standardization. Some members of that group did travel, but this had no impact on a person's ability to affect the direction of the standard, or allow their voice to be heard. The Internet Engineering Task Force, which supervised standardization of SSH, does organize regular meetings; but this is no way required to publish RFCs, or contribute to them.
Holding face to face meetings is an inefficient and exclusionary process that became unnecessary around the year 2000. Yet it continues to persist. I wonder if this is because most people who would vote to change it enjoy being sponsored by their companies to travel. After all, it's necessary if people do it...
When I voiced this concern, members of the group were of course up in arms. It really is to get work done!
But the next WG21 meeting is being held this October at the absurd location of Kona, Hawaii. This is 5000 miles from New York, 7,400 miles from Berlin, and 2400 miles from San Francisco.
It would be too rushed to arrange this as a fly-in and fly-out 2-3 day event. If that were the case, it might as well be held in Bentonville, AR, in a non-descript Walmart office building. To allow work to get done, it has to be a leisurely occasion of 5 nights and 6 days. This allows for convenient weekend arrival or departure, which I'm sure no one will use to treat themselves to a volcano trip — or a leisurely day at the beach.
The average fuel economy of long-distance travel is >3L of jet fuel per 100 miles per passenger seat. With 90 - 100 attendees traveling an average of 5,000 miles each, return trip, this is going to involve the burning of 27,000 liters of jet fuel, and the release of 68 metric tons of CO2 into the atmosphere.
All of this must happen 2-3 times per year, because otherwise it's impossible to advance the language.
Some members of the group said they've tried to attend remotely, but that it just doesn't work as well. Well, of course it doesn't work, when the event is being set up so that you're a second class participant.
With meetings held in places like Hawaii, they're spending at least $2,000 per person per event. Annual cost is $400,000 - $600,000, just in what each participant pays. You could get absolutely amazing teleconferencing if your budget for it was $500,000 per year. And that's just one ISO working group. How many other active groups are there? What tech could you get for a $2 or $10 million annual budget?
But of course — that would make sense if you wanted open standards, where anyone could contribute.
As opposed to a week in Hawaii, each year...
Showing 13 out of 13 comments, oldest first:
Comment on Aug 3, 2015 at 16:13 by Nicol Bolas
However, my problem was not so much that meetings were important, but that they were too important. Getting meaningful feedback on a proposal is impossible without going to a meeting. This caused a number of important proposals to wither on the vine.
That being said, I think your post is wrong on a number of points.
First, you discount the efficacy of face-to-face meetings, saying that teleconferencing is sufficient. Teleconferencing between over a hundred people, across 24 time zones, for 12+ hours each day... that's not reasonable. I don't know what your SSH standardization process is, but it is almost certainly far less exacting than C++ standardization. C++ standardization requires participation from lots more people.
Second, C++ is an ISO Standard. This means that it must advance in accord with ISO's rules and procedures. These procedures exist to make sure that international standards come to pass in a reasonable and fair way for all nations involved. Among these rules is the requirement of having face-to-face meetings. They require national body members to vote on them, in person. There needs to be a record of the meeting, and minutes need to be handed out. And so forth.
C++ is not just a programming language; it's an international treaty. Sure, that creates bureaucracy, but it's important for it not to go awry.
Third, the ISO committee is already taking steps to improve participation. Take SG14 (game developers/low latency); they get to have their own meetings at important places and locations for them (GDC, for example). This is true of all Study Groups. Also, there's the recent financial assistance program, who's primary purpose is to get users to attend who would otherwise not be able to do so.
I freely admit that the committee's process does neglect little proposals in favor of big ones that have lots of support. There is a problem here, but it's not like they're unaware of it or are doing nothing to try to improve things.
Fourth, the location of C++ meetings is essentially irrelevant. C++ is global, so no matter what, someone is going to have to fly. Lots of someone's. So the fact that getting to Hawaii costs air-fare is really no different from the fact that getting to Bristol or Lexana costs air-fare.
Not to mention the fact that the two scheduled meetings after Kona will take place in Jacksonville, FL, USA and Oulu, Finland. Prior meetings have been held in such disparate locations as Bristol, England (a prime vacation spot, I'm sure); Lexana, Kansas, USA (well known to be a hub of tourism); Urbana-Champaign, IL, USA; Rapperswil, Switzerland; and Issaquah, WA, USA.
I could keep going, but I hope my point is clear: they're not picking vacation spots.
Fifth, you show a profound disrespect for the work the ISO C++ committee members actually do by claiming that they're basically taking a week of vacation. I agree that the committee could do better as far as getting proposals through the process, but there's a big difference between saying that the process could be improved and saying that the process is being actively abused. I have never been to a C++ meeting, but I am well aware that they do actual, real work in them, not goof off and go to the beach.
And quite frankly, if I were going to have to work 12+ hour days for 6 days a week on a standard that people on the Internet are just going to take a dump on constantly, I'd at least want to wake up and enjoy the scenery for the 5-10 minute trip to the building I'll be in for the entire day. Don't you think they're owed at least that much?
Comment on Aug 4, 2015 at 01:25 by denisbider
Nicol: Teleconferencing between over a hundred people, across 24 time zones, for 12+ hours each day... that's not reasonable
I would like to call attention again that it costs on the order of USD 200,000, in the participants' own costs alone, to hold just one ISO group meeting.
I understand that ISO may currently be lacking the infrastructure to hold these meetings equally effectively online. However, a single ISO working group — and there are many — burns through USD 500,000 of participants money alone per year to hold these meetings.
Do you not think that an amazing online collaboration system could be developed; to serve the needs of one or all of ISO working groups; for a fraction of the cost currently spent on travel by all of the ISO working groups?
Participants in just the C++ working group alone are spending upwards of USD 500,000 per year to come to the meetings. Meanwhile, what is the group using for online collaboration? It uses Google Groups!
It uses Google Groups!
I cannot over-emphasize this. A permanent working group involved with standardization of information technology is being so cheap that it coordinates through a free general purpose online tool, while the members spend USD 500,000 per year on travel.
Nicol: Fifth, you show a profound disrespect for the work the ISO C++ committee members actually do by claiming that they're basically taking a week of vacation
You're probably right; without having attended the meetings, it has been unfair for me to do so.
Certainly, the language is much better off with this type of guardianship, than no type of guardianship at all — or many other types that would be inferior. The work being done is highly valuable. I benefit from it; millions of other developers do; the entire world does, in our use of the resulting software and services. The working group is at the center of these invaluable efforts.
So yes; it is unfair that I poke fun at your meeting at the Royal Kona. ;) However, I believe that there is room for great improvement. I think an online system of collaboration would allow both for greater participation, and for a more comprehensive addressing of the needs of users; especially minor improvements and tweaks.
An agile online collaboration system would facilitate small-scale improvement much better than a waterfall meet-for-a-week system. Or perhaps, the two could be combined. If those who are the most dedicated to the standardization process prefer to meet for a week, that's okay; that is their prerogative.
But the mechanisms for taking small proposals into account must also be improved; and there should be some system for this other than... Google Groups.
Comment on Aug 4, 2015 at 09:35 by Bengt Gustafsson
Gien that such a system could be used by any ISO committe it seems logical that the ISO itself should work on these issues, and maybe they do.
Comment on Aug 4, 2015 at 11:10 by denisbider
I agree also it can be easier to justify the same amount of money being spent in one way, than another. If ISO were to charge $1,000 per participant in a working group; or $100 per proposal submitted to a group; or whatever other reasonable structure there might be - this could be seen as outrageous. Whereas if you actually need to take a holiday, and shell out $3,000 to attend a meeting - that is a hidden expense.
I think charging for proposals actually sounds like a really good idea. Why should I be able to litter a working group mailing list with whatever weird proposal I might fancy, that no one else likes, or is going to accept?
But on the other hand, if I could pay to submit a proposal - whether it's $100, or $200, or perhaps even more - maybe that would provide me with higher quality feedback? That way I could fix the proposal and submit it again; and perhaps, the funds gathered this way could be used for the purposes of the working group - e.g. to help cover expenses of meetings?
Comment on Aug 5, 2015 at 08:53 by David Rodríguez
You did propose aggregated exceptions to be added to the language. A discussion arose and you were pointed to the shortcomings of the approach, including a CppCon talk about exception safe code.
Later on you floated the idea of a relocating objects in memory (at the time you called it *movable*) and further discussion on that line followed. You were pointed to the libraries you mention in the post, you were explained in different ways how your approach to compiler deduction is broken, you might or might not understand what was been discussed as you went back to the same points.
The blog post claims that the proposal was shot down by the committee, which is a gross misunderstanding of what is going on. Not only it was not shot down, but rather there are two proposed alternatives being discussed (the first of which was started by Pablo Halpern over a year ago --he was one of the developers in BSL years back and is quite familiar with the IsBitwiseMovable trait).
You later tried to settle on try_realloc, which was not new either and something like that had already been proposed to the **C** standard, you were pointed at the proposal and explained that it was killed by the C standard committee --Note: try realloc is not that useful in C, in that language it feels like adding more memory management functions with little to no value.
Whether try_realloc (or the exact proposal that was given to the C committee) could or should be presented to the C++ standard committee is a different question, it might be a good idea and other people think so, but the work on having a relocatable trait and making use of it is in my opinion a better path, and contrary to your blog post it is a path that has not been cut short.
On your rant about having to defend the proposal to the committee in person, you are carefully forgetting to mention that at one point one of the persons in the list offered to write a proposal for the 'is_relocatable' trait (at the point in the discussion it was named 'is_destructively_move_constructible'), but that was before we realized that such a proposal had already been written, defended and was currently being worked by the committee.
Of course, it makes better headlines to claim that people ignored your genius and blocked your ideas. In "A Confederacy of Dunces", John Kennedy Toole starts with a quote from Swift: "When a true genius appears in the world you may know him by this sign, that the dunces are all in confederacy against him." At the end of the book the reader gets to decide whether the main character is indeed a genius or the uttermost dunce.
The blog post, by trumping over parts of the truth does make you look good, maybe a genius against whom the committee members are in confederacy. Good job, but make no mistake: the committee members are no dunces and have an understanding of complexity of the language that you lack. They are also far more invested in improving the language that you and me, enough to spend personal time daily and then sometimes vacation time in Hawaii locked in conference rooms working 12 hours a day.
Comment on Aug 5, 2015 at 11:18 by denisbider
I do not believe that my understanding of compiler deduction is broken.
You are making the claim that I'm too stupid to understand why compiler deduction of a relocatable property cannot work. I am countering with the opposite claim; that you are failing to understand how it does work. Neither you, nor anyone else, has pointed out a direct flaw in the rules I have proposed. All criticism of this has boiled down to "no thanks" and vague hand waving.
If you think you can do better than vague hand waving, the rules I'm proposing are described in the post above, and you are welcome to point out any direct flaws.
The rest of what you wrote is - true! It is a matter of perspective; it's whether we want to focus on the glass being half-empty, or half-full.
When we're talking about the standardization process, we're obviously talking about competent people; good people; with good intentions. I find it personally difficult to express the criticisms I've expressed, because I know that, in a big way, they are fundamentally unfair. It feels awful to be criticizing people who have invested this much effort into advancing the language, and have in fact done so to everyone's benefit.
So, yes – I feel like I'm expressing these criticisms to a surgeon who has just saved 100 people, and I'm standing here saying: "Well, if you did this, and if you did that, you could have saved 150, or 200!" This comes across as harsh and ungrateful.
Yet, it seems to me that there are major improvements to be made. I feel that, just because a lot has been done in the past, doesn't mean that there are major improvements that could be done to the process, so that the future could be better still.
Make no mistake - I value highly that the progress is conservative. It is a great value of C++ that it's stable, and that it doesn't introduce incompatibilities like a major version upgrade in Python.
But on the other hand, I do believe that the C++ standardization process remains too aloof; too inflexible; and frequently out of touch with what's needed by developers, and is not provided due to, honestly, pure pedantry issues. Things aren't making it into the standard that should be; and to a large extent, this is because the walls to contribution are too high.
I'm not unique in observing this. This is recognized, but there's complacency that prevents this from changing.
I don't see a way to cajole people out of this complacency without offending some egos, and unleashing criticism that may seem harsh. This cannot be done by an insider who wants to maintain good working relationships with people. It has to be done by someone who can afford to walk into your place, and call things the way he sees them.
So yes. The way you phrased your point of view could be perceived as perfectly reasonable - iff you don't mind remaining complacent.
But my whole idea here is to try to awaken people out of complacency - even if it means making criticisms that may seem unfair. Even if it means hurting some egos.
If I didn't have at least some point - why is anyone taking me seriously?
Comment on Aug 5, 2015 at 11:58 by denisbider
to the extent that I've done anything good at all; to the extent that my feedback may or may not plant a seed for some change in the future; I think this has been done, and my continuing involvement at this point would be counterproductive.
I have a volume of work to do right now that involves using the language, more so than improving it. In order to be able to focus on what is my actual work; and to provide group members a respite from unnecessary drama; I'm currently no longer following the group. Anything sent to me that contains "[std-" currently goes into a folder that I'm not currently reading.
I will of course remain available here, if anyone still wants to reach me. For the most part, though, I consider myself now not part of the group.
Comment on Aug 5, 2015 at 15:23 by Nicol Bolas
No, it has been very clearly pointed out to you what the flaw of your proposal is. You simply don't think it's a flaw.
The foundation of your primary idea, its very goal, is this: to make an object continue its lifetime in another piece of memory.
The "direct flaw" of this is quite simple, something that would be immediately obvious to anyone with a passing familiarity with the C++ standard. Namely, it is this line from the C++ standard (section 1.8, p1):
-> An object is a region of storage.
That is how the C++ specification defines an object. Whether you agree with that definition or not, like it or not, the entirely of C++ is based on that notion.
By this definition, an object cannot "continue its life" in another piece of storage, because the object is defined as being that region of storage. Your idea contradicts this language definition.
There's your "direct flaw"; your idea is fundamentally contradictory towards the C++ standard.
Comment on Aug 6, 2015 at 03:55 by denisbider
Your response is pure, unadulterated, pedantry. It does not have a practical orientation of any shape or form.
Yes, that's how the current C++ specification defines an object.
Guess what.
That definition is impractical, and wrong.
It is furthermore not a definition actually followed by any compiler. It is a fiction that exists in the language. If you actually interact with the language in practice, and pretty much all of its implementations, you will find that you can relocate objects in memory just fine, and nothing goes wrong.
You're saying I don't understand. No, you don't understand.
Your pedantry is pointless! You're defending an empty principle!
You're defending a principle that has to change, and is in fact trivial to change, because no practical implementation actually relies on that principle!
It's just stupid language fiction being defended by out of touch language lawyers.
Don't be an out of touch language lawyer.
Comment on Aug 6, 2015 at 04:12 by denisbider
An object is a concept that instantiates a relationship between data stored in memory, and code that operates on it.
There. Now the object is a concept, and can be moved.
Before you poke obvious holes in this, consider that I've spent exactly 5 minutes thinking about how to phrase it.
Consider what we could come up with in a day, if we didn't have absolutely pointless and stubborn opposition - of the type that seems to exist solely for opposition's sake.
Comment on Aug 6, 2015 at 04:13 by denisbider
Which is why no implementation actually relies on such a definition in practice.
The current standard may be stupid, but compiler implementors aren't.
Comment on Aug 6, 2015 at 04:30 by denisbider
Defining an object as a "region of storage" is a confusion of concepts. An object is an instance of a type contract. It's a relationship between data and code. This relationship is independent of where the data is stored.
If you're defining an object instead as a region of storage, you are doing two dumb things at the same time:
- Marrying the concept of object to a location in memory, completely unnecessarily.
- Forgetting to mention that an object is actually a relationship between data and code.
It's an amateur definition. It's a mistake committed by someone who was confused about what they were trying to express.
It's a mistake that needs to be fixed, that's all. And it can be fixed free of cost, without fundamental change to the language, because no sane person actually implements an object that way.
I'll stop spamming now. It just really pisses me off that you guys don't see this.
Comment on Aug 7, 2015 at 08:11 by denisbider
for the record, I love the idea of move destructors.
By far the best idea so far!
I think if it makes it into the language; with some polishing; it could be absolutely awesome.