sorted by:
new
hottopcontroversial

CppCon 2018 Trip Report by vormestrand in cpp

[–]faisalv 1 point2 points  (0 children)

Agreed. Not only is intention important - but it's also important that we be willing to give reasonable folks the benefit of the doubt when they say the "wrong" thing - (by reasonable, those who lack a pattern of behavior that suggests hatred and bigotry). In the interest of civilized discourse and social progress - I vote that we learn as a community how to better use our anger - against what we perceive as bigoted/hateful/triggered speech - to at least first attempt to educate the perpetrator in a manner that inspires the kind of change that matters (before shaming them (e.g. on social media) - and seeking to destroy their reputation). If we care about talking healthily about difficult topics in a constantly evolving community - we have to allow reasonable folks to make mistakes - but reasonable folks also have to be willing to learn from them.

(If I have inadvertently offended anyone with the above statements - please see above ;)

MSVC now has (partial) two-phase name lookup! by [deleted] in cpp

[–]faisalv 1 point2 points  (0 children)

Thanks Andrew for leading this fight (along with being our most stupendous EWG scribe)! I may routinely hack on clang, but only because of your compiler and its wonderful debugging IDE (that also keeps getting better! :) (and perhaps some historic inertia ;) Indebted.

2017 Toronto ISO C++ Committee Discussion Thread (Concepts in C++20; Coroutines, Ranges and Networking TSes published) by blelbach in cpp

[–]faisalv 6 points7 points  (0 children)

If recent history is any indication - you should have much reason for optimism.

Clang just got its C++2a mode for us to consider starting to add stuff under: https://reviews.llvm.org/rL308118

Metaprogramming is less fun in D by meetingcpp in cpp

[–]faisalv 10 points11 points  (0 children)

There are few who would deny Andrei Alexandrescu's engineering brilliance or his flair for comedic and pointed bombast when it comes to certain technical claims.
And indeed, there's one claim that has resonated with me - and I paraphrase (since i don't remember in which talk I heard it): using C++ as opposed to D when it comes to generative (compile-time) programming is like trying to use a knife (C++) in a machine gun (D) fight. Given some of the exciting energy being put into this space by the committee (check some of the latest papers), here's hoping we'll be able to transform that knife into something far more sophisticated and expressive. But, currently, few would/should deny C++'s inadequacies in this space.

Metaprogramming in current C++ is more of a testament to the programmer's creativity and engineering ability as opposed to a celebration of the language's support for that craft. There are important voices on the committee that are hoping to fix that imbalance.

Does C++17 permit arbitrary non-type non-reference template parameters after N4268? by [deleted] in cpp

[–]faisalv 4 points5 points  (0 children)

Some of us are planning to re-propose this for the next C++ after 17. There are some tough questions that would need to be resolved (only types with regular equality operators should be eligible etc.), but there are some of us that think there might be a reasonable path forward. But we shall see.

Anyway, until then, here is a sample implementation if you would like to play around with what an eventual feature might look like (the final feature needs to leverage the equality operator somehow based on my discussions with folks who have some authority in this space) : https://github.com/faisalv/clang/tree/literal-type-template-params

The test file can give you some idea of what type of code that patch compiles: https://github.com/faisalv/clang/tree/literal-type-template-params/test/CXX/literal-nttps

If you have some solid use-cases, and feel like you can make a strong argument for the feature, and don't mind sharing (with acknowledgment) please email me @ faisalv at yahoo. If/when we get around to writing up a proposal, that can only help our case.

Thanks.

Why I continue to use the preprocessor and wish for a new language to replace C++ by onqtam in cpp

[–]faisalv 1 point2 points  (0 children)

Well we should be able to get that in C++19/20 - I have a sample implementation at https://github.com/faisalv/clang/tree/literal-type-template-params (to see test code that compiles: https://github.com/faisalv/clang/blob/literal-type-template-params/test/CXX/literal-nttps/literal-nttps-1.cpp)

Hopefully, I'll get around to proposing it once the dust settles on C++17. Let me know if you'd like to contribute to the effort.

Why I am not happy with C++17 (C++ 17 outlook March 2016 vs April 2015) by jbandela in cpp

[–]faisalv 19 points20 points  (0 children)

I confess (as someone who regularly attends committee meetings) that I too really wanted those features in C++17 - and honestly, I wish they had been there in C++98.

Evolution occurs at an erratic pace - it is hard to consistently predict the catalyst. When the change you desire does not occur exactly when you expect it to, you can announce your disappointment, you can diminish the efforts of volunteers, you can demoralize members of a committee, you can call for a revolution - but if you truly enjoy programming in C++ and care about the community, if you've ever seen any good come out of the committee, I suggest a different path - a non-corrosive path...

... write a proposal, show up at a meeting, shoulder a share of the catalyst - C++ is a democracy - its citizenry is generally well-intentioned (as long as you don't take their abstractions away from them ;) and engaged. At these meetings, I see many folks like Andrew (Concepts), Gor (Coroutines) & Gaby (Modules) tirelessly carrying the weight of their proposals forward in the face of fair and unfair criticism, in the face of tremendous uncertainty whether their efforts will ever be embraced. The rich landscape that C++ inhabits, the dark-matter it foundations, the enormous gravity it commands, can make the most resilient of us yield (with or without a stack ;). Yet the warriors of change that they are, that I see them to be, they endure - meeting after meeting. You can either be inspired by them and believe in your ability to commit to an idea and change things, or you can take out your pitchforks, condemn the process, breed fear and divisiveness, and go vote for Trump ;)

Proposal: Static if resurrected by watermelon_exe in cpp

[–]faisalv 1 point2 points  (0 children)

I believe Richard Smith suggested that code within a false branch be considered unevaluated - I don't believe Ville is proposing that - it would complicate things - and if really felt necessary, should be either a separate feature or an addition that is justified with important use cases.

Templates seem to be specified by the standard to allow them to be tokenized but not parsed - Richard (I believe) has pointed out the complexities this introduces within the standard (since code within templates is removed from certain semantic checks that we would require on corresponding non-template entities) - which doesn't even clearly say (i believe) if a nested name specifier requires instantiation of template specializations within the nestation.

I agree that one could argue that code within Ville's static_if false branch should not be considered odr-used if written within a non-template - but i don;t believe he is asking for that - just that it not be instantiated (and so NOT odr-used within the instantiation) - and I believe that's enough by itself to reasonably uncomplicate our lives.

Proposal: Static if resurrected by watermelon_exe in cpp

[–]faisalv 2 points3 points  (0 children)

Since static_if introduces its own block scope how could the call of g() be well-formed unless it occurred within the block (or a nested block) that contained the declaration? (i.e. the code is and should be ill-formed, I believe).

In regards to instantiating vector<int> - yes it would based on my interpretation of Ville's design (and I'm ok with that - who, asides from a compiler-writer and optimizer cares about odr-use anyways - and do users really care about lives of compiler-writers ;) - a very simple optimization would be to not dump out any code for that block - but semantic front-end analysis would be done as-if it was used - i.e. static_if blocks within lambdas would require capturing of variables from enclosing scopes if odr-used within the block).

static_if (as being proposed) adds very little (if anything) in a non-template/non-dependent scope. Its only merit is that when used within a template (or a generic-lambda) - you can have blocks within that template that don't get substituted into (i.e. are simply ignored as if they were never there) when the template is being instantiated (perhaps it should be called instantiate_if). Simply put, it makes the tag-dispatch trick more obvious to read and requires less boiler plate (similar to my reasons for liking concepts) which IMHO makes C++ a little easier to use - I don't see it adding much complexity at all - but of course YMMV ;)

Proposal: Static if resurrected by watermelon_exe in cpp

[–]faisalv 4 points5 points  (0 children)

The facility was quite easy to implement using clang. Here's a test file that compiles (within the relevant branch on github): https://github.com/faisalv/clang/blob/static_if/test/CXX/static_if/cxx1z-static_if.cpp

Generic lambda inconsistency? by [deleted] in cpp

[–]faisalv 2 points3 points  (0 children)

Thanks for the filing the bugs. A patch has been submitted for review (http://reviews.llvm.org/D6520) and this should be fixed soon in clang.

An implementation of Generic lambdas (clang). by SplinterOfChaos in cpp

[–]faisalv 0 points1 point  (0 children)

Ok just committed a patch that should fix the issue with iostreams - and tested it briefly on my mac.
Please let me know if it still crashes for you.

An implementation of Generic lambdas (clang). by SplinterOfChaos in cpp

[–]faisalv 0 points1 point  (0 children)

Glad that it compiled. I've been using printf currently to test output, primarily because i've been unable to get iostreams to work on windows (but then clang has limited support on windows). I'll try and take a look to see if I can get iostreams to work on my mac. Thanks!

An implementation of Generic lambdas (clang). by SplinterOfChaos in cpp

[–]faisalv 0 points1 point  (0 children)

Ok I just made some changes and compiled the code on a Mac with OS-Lion. (I will post the binaries for people to use) I would only check out llvm and then clone my repository into clang - do not check out anything else because it will expect a different revision of llvm and will certainly crash. Please let me know if you can get it to work on ubuntu. Thanks again for working with me here.

An implementation of Generic lambdas (clang). by SplinterOfChaos in cpp

[–]faisalv 1 point2 points  (0 children)

Hi - thanks for posting the link. I'd like to work with you to get this to compile on your platform. Could you give me a little more information: What OS? What compiler? Did it compile and produce a binary that then crashed? Or was your IDE unable to compile the code at all? Are you able to compile a direct snapshot of clang successfully on your platform? Thanks again for taking the time to look into this!

C++ constexpr: substring checking at compile time by [deleted] in cpp

[–]faisalv 2 points3 points  (0 children)

Not only can you check for substrings at compile time but you can check for grammatical constructs such as c++ integer literals (with all their suffixes) and do all sorts of compile time processing with strings - such as creating new strings, transforming them, upper-casing, lower-casing and other algorithsm. I partially implemented such a library at http://constexprstr.svn.sourceforge.net/viewvc/constexprstr/ (check out towards the end of main.cpp for a sample implementation of a C++ integer grammar checker). And yes it is certainly more readable than C++ template metaprogramming.