Re: C++ Standards Committee meeting next week
some things that I've seen that we'd probably like to see end up in the language include. ... - ability to say classes should only be used on stack / heap or not used in one of those There's a proposal in the pre-Urbana mailing for something related: the ability to say that a class should only be used as an lvalue, or only as a temporary [1]. Cheers, Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4149.pdf ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
There is a Reflection Study Group (a sub-group of the Committee which focuses on a particular area) which is tasked with investigating language and library extensions for compile-time and runtime reflection. The majority of the interest so far has been for compile-time reflection, but I believe some of the infrastructure for compile-time reflection will enable runtime reflection as well. The Reflection Study Group met in Chicago last week, and talked about a rough outline of the sorts of things C++ programmers would like to be able to do with reflection, from straightforward things like iterating over the members of a class at compile-time for purposes such as serialization and equality comparison, to more sophisticated things like synthesizing new types by transforming existing types. I believe the plan is to issue a call for proposals, with some guidance about the general direction that is desired, derived from that outline. The Study Group will then look at the proposals at future meetings and provide feedback, with the aim of converging towards a cohesive set of proposals to present to the Committee at large. Since this is a very broad area to explore, I believe the Study Group is initially interested particularly in proposals that provide infrastructure that compile-time reflection features can be built on top of. This should become more clear when the call for proposals is issued. The call for proposals has now been posted. It can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html It states that all reflection-related proposals will be considered, but the focus is on compile-time reflection, and gives a list of focus areas and representative use cases. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 10/02/2013 06:06 PM, Botond Ballo wrote:
Having to repeat 'expr' is rather unfortunate, and C++14
fixes that. You can now write:
auto function(A a, B b)
{
return expr;
}
The only restriction is
that if there are multiple return expressions, they
must all have the same type.
Same type as in the std::is_same sense? Or same type in the a?b:c sense, where
b/c can be different types, and one expression must convert to the other's
type? I assume you mean the former, but I can imagine cases (think pointers
and nullptr) where the latter would definitely be nice.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 2013-10-02 12:06 PM, Botond Ballo wrote: * Digit separators: int x = 1'000'000; // don't ask Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which doesn't? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
* Digit separators: int x = 1'000'000; // don't ask Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which doesn't? Because _ followed by any number of digits is a valid identifier, so that would have created an ambiguity with C++11 user-defined literals. For example, 1_000 would be ambiguous between the number 1000, and the number 1 suffixed with a user-defined literal named _000. As for pp-numbers, the proposal extends the preprocessor grammar to handle the separator. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 10/1/2013 4:51 PM, Botond Ballo wrote: I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. For networking, there are three proposals in the works: URIs [5], IP addresses [6], and byte order [7]. I believe URIs and IP addresses are headed towards one Technical Specification, and byte order towards another. Presumably more will follow that build on these (e.g. TCP socket communication). It's a shame that sockets come so much later, but nonetheless totally understandable. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. Interesting. How is this static analysis implemented - a clang plugin? Does it cause compiler errors or warnings when the annotations aren't obeyed? I haven't heard any discussion of such annotations in Chicago. One attribute, [[deprecated]], was standardized, but that's it. I'll keep my eyes open and let you know if I come across any talk of them. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). I'm not aware of other compilers actively working on it at the moment. It sounded like they were waiting for clang to implement it to see if the idea is viable at all. An EDG developer present at the meeting pointed out that many of the difficulties in implementing modules are the same difficulties that are involved in implementing 'export'. EDG was the only compiler that implemented 'export', so that's not a very encouraging sign, but I also think the level of demand is much higher for modules (which most people agree will be very useful) than it was for export (which most people agreed was useless). One thing that was brought up is that clang was able to leverage its PCH (pre-compiled header) implementation, which is basically just a serialized AST, for its implementation of modules, but GCC's PCH implementation, which is just a compiler memory dump, is less suitable for this purpose. This suggests that it will require more effort for GCC to implement modules than clang. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. I'll post a follow-up email about the various Technical Specifications that are in the works, and what's likely to be in them. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 2013-10-02 11:38 AM, Botond Ballo wrote: I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? http://dxr.mozilla.org/mozilla-central/source/mfbt/Attributes.h#l384 is the list of analyses we currently do in Mozilla. I know must_override has been mentioned once or twice with respect to C++ standardization, but I can't recall where. Interesting. How is this static analysis implemented - a clang plugin? Does it cause compiler errors or warnings when the annotations aren't obeyed? It is implemented as a clang plugin here: http://mxr.mozilla.org/mozilla-central/source/build/clang-plugin/clang-plugin.cpp. The compiler will emit an error if it detects a violation of the annotations. Cheers, Ehsan I haven't heard any discussion of such annotations in Chicago. One attribute, [[deprecated]], was standardized, but that's it. I'll keep my eyes open and let you know if I come across any talk of them. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. What is the feedback from non-Clang developers about prototyping in their compilers? Are we likely to see this implemented as soon as stable wording is finalized, or are compiler vendors likely to drag their feet and implement it in the last tranche of updates (basically, is the uptake going to be like auto or rvalue references, or will it be like generalized attributes or alignof). I'm not aware of other compilers actively working on it at the moment. It sounded like they were waiting for clang to implement it to see if the idea is viable at all. An EDG developer present at the meeting pointed out that many of the difficulties in implementing modules are the same difficulties that are involved in implementing 'export'. EDG was the only compiler that implemented 'export', so that's not a very encouraging sign, but I also think the level of demand is much higher for modules (which most people agree will be very useful) than it was for export (which most people agreed was useless). One thing that was brought up is that clang was able to leverage its PCH (pre-compiled header) implementation, which is basically just a serialized AST, for its implementation of modules, but GCC's PCH implementation, which is just a compiler memory dump, is less suitable for this purpose. This suggests that it will require more effort for GCC to implement modules than clang. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Huh. I'll post a follow-up email about the various Technical Specifications that are in the works, and what's likely to be in them. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
So, after writing about a bunch of things that _won't_ be in C++14,
let me summarize what _will_ be. Here are the highlights:
* Return type deduction
In C++11, we have decltype() and late-specified return types
(return types written after the argument list so they can
mention arguments). These were often combined to write code
like this:
auto function(A a, B b) - decltype(expr)
{
return expr;
}
Having to repeat 'expr' is rather unfortunate, and C++14
fixes that. You can now write:
auto function(A a, B b)
{
return expr;
}
It works even if the function body contains multiple
statements, control flow, etc. The only restriction is
that if there are multiple return expressions, they
must all have the same type.
* Improved lambdas
* Generic lambdas
These are lambdas with 'auto' arguments which acts as
template parameters rather than concrete types:
// This lambda can be called with arguments of any type.
[](auto a, auto b){ return a b; }
Implementation-wise, they are just local structures with
a templated call operator (while ordinary lambdas are
local structures with a non-templated call operator).
* Init-captures
These allow you to declare new variables in the capture-list
rather than just capture existing variables from the outer
scope. The new variables can be initialized in any way,
including by move, something that wasn't possible before.
std::unique_ptrFoo p = ...;
...
// No way to capture 'p' in C++11. Can't capture it by
// value because it's not copyable; don't want to capture
// it by reference because the reference could become
// dangling if the lambda is passed out of the function.
// In C++14 we can do this:
[newp = move(p)](...){...}
* Variable templates
Up until now, only functions and classes/structures could be
templates. Now, variables can be too.
* More powerful constexpr
Up until now, constexpr functions were limited to containing
a single return expression. Now they can contain multiple
statements, loops, and so on. Basically, they can now be
written in an imperative style rather than a functional
style. They still can't modify non-local state.
* Improved literals
* Binary literals: 0b00101010101
* Digit separators: int x = 1'000'000; // don't ask
* Standard user-defined literals
C++11 introduced user-defined literals. C++14 intoduces
some standard ones:
foos // std::string literal
30s // std::chrono::seconds literal
Yes, they are both 's'. C++ knows when to use which.
Other durations have them too, so you can write things
like
1h + 10min + 30s
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
In addition to the C++14 standard, the Committee is working on a number of follow-up documents called Technical Specifications (TS), which carry less weight than the standard, but indicate an intention to standardize a new library or language feature in a future standard: * Concepts Lite TS (my favourite) Concepts are a mechanism for constraining template parameters. Today we often write code like this: template typename Container void sort(Container c); Our intention is that the type used as a template argument for 'Container' be a container type, but the compiler doesn't enforce this - it will accept any type there, and then give cryptic errors from deep within the template's implementation when it tries to use the argument as a container. Concepts allows us to define a concept called 'Container' which expresses what we mean by a 'container type', and then write the template like this instead: template typename C requires ContainerC void sort(C c); Or as a short form: template Container C void sort(C c); When calling this function, the compiler checks at the call site whether the template argument satisfies the Container concept, and give a much friendlier error if it doesn't. It's also possible to check the definition of a template to make sure it doesn't do anything with the template arguments that's not specified by the concepts to which they conform. A 'full' concepts feature would include both directions of checking (checking the call sites and the definitions). The committee tried standardizing full concepts for C++11, but ran into a lot of complexity. It is now resurrecting the feature in a 'lite' form that only includes checking of the call sites. The details of Concepts Lite can be found here [1]. * Array Extensions TS Support for arrays whose size isn't known at compile time. C calls these Variable-Lengths Arrays (VLAs). C++ stubbornly refuses to call them VLAs, and calls them Arrays of Runtime Bound (ARBs) instead (there are some minor differences between the two flavours, for example you can call sizeof() on a VLA (and it will be evaluated at runtime), but not on an ARB). The TS will also include a library that wraps ARBs into a nicer interface, much like how std::array wraps regular arrays into a nicer interface. These were originally going to be in C++14, but were moved into a TS because the library interface isn't fully fleshed out yet. * Library Fundamentals TS This will contain the new optional library (originally headed for C++14 but the committee felt it was safer to put it into a TS instead) and possibly some other utilities. * Networking TS There will actually be a series of Networking TS's. The first will specify URIs and IP addresses. The second will specify byte-order conversions. Future ones may deal with higher-level functionality like sockets. * Filesystem TS [2] There may also be a follow-up TS to this that provides additional features e.g. for enterprise filesystems. * Transactional Memory TS A synchronization primitive built into the language. The proposal can be found here [3]. * Parallelism Extensions TS Parallel versions of standard library algorithms. This is in a relatively early stage, but it will possibly be based on [4]. * Concurrency Extensions TS Language features that make it easier to write asynchronous/concurrent code. Also in an early stage, proposals being considered include [5] and [6]. I believe that most of these are planned for publication in 2014, though probably not the last two, nor the follow-ups to the Networking and Filesystem TS's. Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf [2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3718.pdf [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3724.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3731.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3721.pdf ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
Finally, let me describe the process for submitting proposals to the committee for new libraries or language features. First, let me briefly describe the internal organization of the committee. The committee is subdivided into four Working Groups: Core, Evolution, Library, and Library Evolution. Evolution looks at proposals for new language features at a high-level: how well do they fit into the design of the language. Core looks at them at a lower-level: is the specific wording consistent with the wording of the rest of the standard. Library Evolution and Library are analogous to Evolution and Core, but for the standard libraries rather than for language features. In addition, some feature areas have a Study Group which looks at proposals before sending them to Evolution or Library Evolution. So, a language proposal progresses through the following stages to become standardized: * the relevant Study Group (if there is one) * Evolution * Core * vote by the full committee A library proposal progresses in a similar way but goes through Library Evolution and Library instead. (This is illustrated very nicely here [1].) If someone is interested in writing a proposal, here's what to do: * Bring up the idea on the std-proposals discussion group [2] to gauge the community's level of interest. * Write up an initial draft of the proposal, get some more feedback on it at std-proposals. This initial draft does not need to contain standard wording yet. * Formally submit the proposal. I believe this is done by emailing the committee's project editor, but I can check up on this. The proposal will get an Nxxx number and show up in committee mailing like this one [3]. * Present the proposal to the appropriate Study Group if one exists, or else to the Evolution Working Group, at a committee meeting. The committee meets 2-3 times a year, and the meetings are open for anyone to attend. If you can't attend in person, you can find someone to champion the proposal for you. * It's rare for a Study Group or Evolution to accept a proposal right away. Most often they will give you feedback on the proposal and encourage you to write an updated proposal and come back. Several iterations of this can happen before Evolution accepts the proposal. * At some point in this process, standard wording for the proposal needs to be written. Once Evolution has approved the proposal, Core will look at the wording. Sometimes they find problems and send the proposal back to Evolution. If not, the proposal is ready to be voted on in full committee. Most proposals pass in full committee after being approved by Core and Evolution. (If proposing a library feature rather than a language feature, replace 'Evolution' with 'Library Evolution' and 'Core' with 'Library' in the above). OK, that was my last long email :) Feel free to ask me any questions. Botond [1] http://isocpp.org/std/the-committee [2] https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/#mailing2013-09 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
what i've really been wondering about for a while is whether there are any considerations of static / compile-time introspection, and if not, why. It's nothing pressing, i'm just really curious and i haven't found anything on it (besides the rare musings of other C++ users on this). Basically static introspection would allow meta-programming to take it a step further; e.g. to use template-meta-programming to iterate at compile-time through information about members of namespaces and classes. You would be able to get their signatures/addresses/names/attributes/... and generate code for them. Use-cases would e.g. be: * generation of bridging code (C++ ↔ script) * various wrapper scenarios (forward/filter/... interfaces) * runtime reflection for select code subsets … for which currently separate pre-build steps (e.g. Qts moc), pre-processor markup (say Boost Reflect), repetitive code etc. are necessary - so it's either crude or requires specific toolchains. This is definitely an active area of investigation in the Committee. There is a Reflection Study Group (a sub-group of the Committee which focuses on a particular area) which is tasked with investigating language and library extensions for compile-time and runtime reflection. The majority of the interest so far has been for compile-time reflection, but I believe some of the infrastructure for compile-time reflection will enable runtime reflection as well. The Reflection Study Group met in Chicago last week, and talked about a rough outline of the sorts of things we'd like to be able to do with reflection, from straightforward things like iterating over the members of a class at compile-time for purposes such as serialization and equality comparison, to more sophisticated things like synthesizing new types by transforming existing types. I believe the plan is to issue a call for proposals, with some guidance about the general direction that is desired, derived from that outline. The Study Group will then look at the proposals at future meetings and provide feedback, with the aim of converging towards a cohesive set of proposals to present to the Committee at large. Since this is a very large area of explore, I believe the Study Group is initially interested particularly in proposals that provide infrastructure that compile-time reflection features can be built on top of. This should become more clear when the call for proposals is issued. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
OK, here is something that I would really like: http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf Basically, this is a language extension that asks the compiler to store type information for each object in memory, so that one can query at runtime the type of what's stored at a given address. That would be useful e.g. for refgraph ( https://github.com/bjacob/mozilla-central/wiki/Refgraph ) and, I suppose, that also wouldn't hurt to know more about heap-unclassified in about:memory. Basically, everything would be 'classified' at least by c++ type name. And that would also be a nice tool to have around during long debugging sessions. So, I would appreciate if you could figure if there is any intention to add something like this in the standard. I believe this falls under the purview of runtime reflection, which is being looked at by the Reflection Study Group. See my previous email about the progress of the Reflection Study Group. I've come across one paper in particular that seems to address this use case, called Rich Pointers with Dynamic and Static Introspection [1]. I believe the Study Group looked at this paper briefly last week and identified some serious problems with it, and the paper's author decided to withdraw it. I'm not sure what the issues were as I wasn't in that meeting (there were several groups meeting in parallel and only one of me :-) ). However, I believe that the objectives that the paper was aiming to achieve, such as determining what is the type of an object at a given memory location, are still desirable, and alternative proposals for achieving these objectives will probably be made. Botond [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3410.pdf ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
There is a Reflection Study Group (a sub-group of the Committee which focuses on a particular area) which is tasked with investigating language and library extensions for compile-time and runtime reflection. By the way, the Reflection Study Group has just opened a public mailing list [1]. Botond [1] https://groups.google.com/a/isocpp.org/forum/#!forum/reflection ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On Tue, Oct 01, 2013 at 01:13:37PM -0700, Botond Ballo wrote:
- final on data / non virtual member functions
- virtual constants (maybe ability to get at vtable pointer too?)
- ability to say classes should only be used on stack / heap or not used
in one of those
It would be nice to know if we can interest people in supporting any
of those.
I'm not sure what final on data means, can you elaborate on that?
something like this
class Foo : public nsISomething
{
nsrefcount mRfcnt final;
};
class SpecialFoo : public Foo
{
nsrefcount mRfcnt; // Should not compile, is not ok, is footgun!
};
For the other things, I'm not aware of any active proposals for these
things. I will post a follow-up email that describes the Committee's
procedure for making proposals for new language features, in case
anyone is interested in proposing these.
maybe someone should look into doing that
I should mention that forcing a class to be allocated on the stack
or heap can already be accomplished to some extent. (To force a
class to be allocated on the heap, declare its destructor private,
allocate it using new, and delete it by calling a member function
that calls delete this. To force a class to be allocated on the
stack, give it private operator new and delete members.) Of course
these techniques are not perfect and a built-in language feature
for doing this would be nicer.
yeah, those are pretty poor substitutes, for example the operator new /
delte thing doesn't prevent globals of the type afaik.
Trev
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
what i've really been wondering about for a while is whether there are any considerations of static / compile-time introspection, and if not, why. It's nothing pressing, i'm just really curious and i haven't found anything on it (besides the rare musings of other C++ users on this). Basically static introspection would allow meta-programming to take it a step further; e.g. to use template-meta-programming to iterate at compile-time through information about members of namespaces and classes. You would be able to get their signatures/addresses/names/attributes/... and generate code for them. Use-cases would e.g. be: * generation of bridging code (C++ ↔ script) * various wrapper scenarios (forward/filter/... interfaces) * runtime reflection for select code subsets … for which currently separate pre-build steps (e.g. Qts moc), pre-processor markup (say Boost Reflect), repetitive code etc. are necessary - so it's either crude or requires specific toolchains. This is definitely an active area of investigation in the Committee. There is a Reflection Study Group (a sub-group of the Committee which focuses on a particular area) which is tasked with investigating language and library extensions for compile-time and runtime reflection. The majority of the interest so far has been for compile-time reflection, but I believe some of the infrastructure for compile-time reflection will enable runtime reflection as well. The Reflection Study Group met in Chicago last week, and talked about a rough outline of the sorts of things C++ programmers would like to be able to do with reflection, from straightforward things like iterating over the members of a class at compile-time for purposes such as serialization and equality comparison, to more sophisticated things like synthesizing new types by transforming existing types. I believe the plan is to issue a call for proposals, with some guidance about the general direction that is desired, derived from that outline. The Study Group will then look at the proposals at future meetings and provide feedback, with the aim of converging towards a cohesive set of proposals to present to the Committee at large. Since this is a very broad area to explore, I believe the Study Group is initially interested particularly in proposals that provide infrastructure that compile-time reflection features can be built on top of. This should become more clear when the call for proposals is issued. Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
I have a laundry list of stuff that I want a fly-on-the-wall perspective. First is the discussion of the standardization support macros (so we don't have to maintain crummy stuff like mfbt/Compiler.h), although that meeting may have already passed. The latest proposal for these macros can be found here [1]. The Evolution Working Group (the subgroup of the committee that deals with new language features) accepted the recommendations in that proposal as-is. A minor procedural blemish arose, which is that some C++14 features for which the proposal contained macros have since been removed from C++14, making the proposal technically out of date. As a result, the committee decided that this proposal will not be put into the standard document itself but into a separate document with its own update cadence. I don't believe this should affect whether/how compilers implement these macros. I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. I'm not familiar with these annotations (other than 'override') - can I find more information about them somewhere? The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. See my previous post about modules. In a nutshell, C++17 at the earliest. The new threading paradigms (MS is proposing an async/await framework that basically plays out like the |yield| keyword in JS or python) could also prove useful for Mozilla. The latest proposal for async/await can be found here [2]. There was also a proposal to standardize the Boost.Coroutines library [3] which provides similar capabilities. Both proposals were presented and discussed in Chicago. I wasn't there for the discussion of [2], but I believe the authors were given feedback and encouraged to prepare an updated proposal. I was there for the discussion of [3], where the primary feedback was that two aspects of the proposal, the proposed communication mechanism between two execution contexts, and the proposed mechanism for launching an independently executing context and for switching contexts, be cleanly separated. Neither of these proposals are on track for C++14. I *believe* they're not on track for the Concurrency Technical Specification that will follow, either, though I don't think the contents of that have been finalized yet. Finally, I'm interested in seeing what APIs are going to come out of the networking and filesystem TS groups, particularly because trying to track down progress on them is maddening. The latest version of the filesystem proposal can be found here [4]. I believe this is on track to be released as a Technical Specification in the 2014 timeframe. For networking, there are three proposals in the works: URIs [5], IP addresses [6], and byte order [7]. I believe URIs and IP addresses are headed towards one Technical Specification, and byte order towards another. Presumably more will follow that build on these (e.g. TCP socket communication). Botond [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745.htm#recs [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3722.pdf [3] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3708.pdf [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3693.html [5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3720.html [6] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3603.html [7] http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3646.pdf ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
Hi, some things that I've seen that we'd probably like to see end up in the language include. - final on data / non virtual member functions - virtual constants (maybe ability to get at vtable pointer too?) - ability to say classes should only be used on stack / heap or not used in one of those It would be nice to know if we can interest people in supporting any of those. Trev On Fri, Sep 20, 2013 at 02:50:48PM -0700, Botond Ballo wrote: Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17. I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week). I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out. If anyone's interested in the C++ standardization process, you can find more information here [2]. Thanks, Botond [1] http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s [2] http://isocpp.org/std ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On Tue, Sep 24, 2013 at 5:18 AM, Trevor Saunders trev.saund...@gmail.comwrote: - virtual constants Yeah baby! - ability to say classes should only be used on stack / heap or not used in one of those That's another good idea! Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 9/20/13 2:50 PM, Botond Ballo wrote: Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17. I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week). I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out. If anyone's interested in the C++ standardization process, you can find more information here [2]. Thanks, Botond [1] http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s [2] http://isocpp.org/std Fixing the include hell problem would be at the top of my list of wants as someone who cares about the performance of a large scale build system. I believe there was a C++ modules proposal on the standards track at one point. Not sure what it's status is beyond being an experimental feature in clang [1]. Of course, by the time all the major compilers support this and we're in a position to make use of it, large parts of m-c's C++ might be rewritten in Rust, so who knows. [1] http://clang.llvm.org/docs/Modules.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 9/20/2013 4:50 PM, Botond Ballo wrote: Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17. I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week). I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out. I have a laundry list of stuff that I want a fly-on-the-wall perspective. First is the discussion of the standardization support macros (so we don't have to maintain crummy stuff like mfbt/Compiler.h), although that meeting may have already passed. I'm also interested in seeing proposals for standardization of more complex attributes that we have static analysis results for--in particular, the stack class/heap class/etc. annotations, the must_override analysis, and expanding override/must_override to refer to nonvirtual as well as virtual methods. The implementation timeframe of modules is also interesting, since it appears to be the best-proposed solution to solving various #include problems. The new threading paradigms (MS is proposing an async/await framework that basically plays out like the |yield| keyword in JS or python) could also prove useful for Mozilla. Finally, I'm interested in seeing what APIs are going to come out of the networking and filesystem TS groups, particularly because trying to track down progress on them is maddening. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
OK, here is something that I would really like: http://llvm.org/devmtg/2012-11/Weber_TypeAwareMemoryProfiling.pdf Basically, this is a language extension that asks the compiler to store type information for each object in memory, so that one can query at runtime the type of what's stored at a given address. That would be useful e.g. for refgraph ( https://github.com/bjacob/mozilla-central/wiki/Refgraph ) and, I suppose, that also wouldn't hurt to know more about heap-unclassified in about:memory. Basically, everything would be 'classified' at least by c++ type name. And that would also be a nice tool to have around during long debugging sessions. So, I would appreciate if you could figure if there is any intention to add something like this in the standard. (Thanks to Rafael for bringing this to my attention) Benoit 2013/9/20 Botond Ballo bot...@mozilla.com Hi everyone, The C++ Standards Committee is meeting in Chicago next week. Their focus will be on C++14, the upcoming version of the C++ standard, as well as some Technical Specifications (specifications for features intended to be standardized but not fully-baked enough to be standardized now) that are also planned for publication in 2014. Presumably there will also be some discussion of the following version of the standard, C++17. I will attend this meeting as an observer. I intend to follow the progress of the Concepts Lite proposal [1] which I'm particularly interested in, but I will try to keep up with other goings-on as well (the committee splits up into several sub-groups that meet in parallel over the course of the week). I wanted to ask if there's anything anyone would like to know about the upcoming standards that I could find out at the meeting - if so, please let me know and I will do my best to find it out. If anyone's interested in the C++ standardization process, you can find more information here [2]. Thanks, Botond [1] http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s [2] http://isocpp.org/std ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
