Novox

• Alexandrescu, Meyers, Sutter: On Static If, C++11 in 2012, Modern Libraries, and Metaprogramming

  Aug 22, 2012 at 5:58 AM

  10 hours ago, Charles wrote

  @Novox: Is there some other form of metaprogramming in C++?
  C

  That's the point: No, there isn't (well, if you ignore C macros, which are metaprograms). Herb is certainly right that currently the use of metaprogramming in C++ is limited to an Elite Priesthood™, but I do not believe that the sole reason is metaprogramming per se or its limited usefulness, but the fact that C++ does not yet have proper support for metaprogramming. And that's why a language extension like "static if" might be a valuable addition to the language: It could make metaprogramming in C++ more accessible, maybe even user-friendly.

• Alexandrescu, Meyers, Sutter: On Static If, C++11 in 2012, Modern Libraries, and Metaprogramming

  Aug 21, 2012 at 4:49 PM

  2 hours ago, Matt_PD wrote

  Hence, Herb's and Scott's points (as in the worries about repelled-not-attracted or run-screaming reactions ;]) are fully and well taken (it's also true TMP is indeed just one area of C++ and not in quite as widespread use as the others). At the same time, simplifying the syntax / removing the awkwardness are directly meant to address this exact point
  
  

  Exactly. I'd say people run screaming not because they fear metaprogramming, but because of the unbearable awkwardness of advanced C++ template metaprogramming.

• Bart De Smet: Inside Rx 2.0 Beta

  Mar 16, 2012 at 8:20 AM

  Wow, looks like a great amount of work...

  Just tried it via NuGet and I got one question:

  What's the purpose of the namespace System.Reactive.Linq.Observαble (note the 'alpha' instead of an 'a')? It contains internal classes that seem to correspond to the operators defined in the static class System.Reactive.Linq.Observable (with a Latin a).

• LINQ - Composability Guaranteed

  Mar 08, 2012 at 6:52 PM

  Nice. Haven't watched the video yet, but the rainbow/lense figure reminds of a certain article/paper on/in ACM Queue... (http://queue.acm.org/detail.cfm?id=2141937)

• SPLASH 2011: Gilad Bracha - Dart, Newspeak, and More

  Nov 24, 2011 at 10:19 AM

  @Charles: Hibernation? Well, he did attend Strange Loop 2011: https://thestrangeloop.com/sessions/category-theory-monads-and-duality-in-big-data

• SPLASH 2011: William Cook - Objects, Orc, Hybrid Partial Evaluation, and More

  Nov 19, 2011 at 2:28 PM

  Great Interview, I love the partial evaluation stuff.

• Checking In: Stephan T. Lavavej - Inside STL (the person, not the library)

  Oct 14, 2011 at 6:26 AM

  3 hours ago

  Now I dream of Andrei(Charles can correct me but I think that Andrei said many times that he thinks that D is the only language that gets immutability right) vs STL E2E.

  Now this would be certainly an amazing E2E, indeed!

• Future directions for C# and Visual Basic

  Sep 23, 2011 at 6:27 AM

  5 hours ago

  If you want to make a high-performance numeric library, you'll often need to use the basic characteristics of the data type. [...] For performance, you need to use type-specific algorithms anyway.

  True. For solving large problems you would always want to use low level high-performance implementations of BLAS/LAPACK like the MKL that is tuned to individual CPUs and cache sizes. But what generic programming should enable you to do is to built easy-to-use interfaces on top of these low level libraries, something you can do with template meta-programming in C++ (e.g. uBLAS, FLENS) -- though it won't be a particular pleasant experience.
  
  A more typical use case for "generic numerics" on .NET would be something like "implement a generic class for small vector types". On .NET you can't really express the required type constraints (like "T is supposed to define a zero and to have a binary operator"), nor do .NET generics support the flexible typing behavior of C++ templates (structural typing) or the flexibility of Haskell's type classes. Yes, there are a few ways to still achieve the goal, but all of those workarounds either require interface dispatch or run-time code generation, both of which prevent inlining with the current generation CLR JITer.

  I bet it’s not gonna happen. C# doesn’t have macros by design. It has several advantages that weren’t an issue 30 years ago when C++ was designed, but much clearer to see today. Ever noticed how much better VS intellisense is working with C# code compared to Visual C++? Huge part of the reason is macros.

  It needn't (and shouldn't) be C macros, i.e. untyped text replacement. There are many languages out there that provide a sane way of meta-programming. Have a look at Scheme, Nemerle, Boo or D, for instance. Still, I also do not expect C# to gain such abilitiesas a built-in language feature in the foreseeable future.

  
  Nope, C++ doesn’t have support for numeric generics neither, those are templates. Different breed.

  C++ does have support for true generic programming (by accident, admittedly) and that's what bcooley is probably referring to; it's not about what "generics" mean in the context of .NET.

  Generics are type-safe and support robust programming very well.

  Templates are type-safe as well, they just don't use nominal typing. If concepts would have made it into C++11, this would have brought templates much closer to Haskell's type classes (see Bernardy et al., 2008).

  The compiler optimizes the code a lot.

  I don't know, whether you're talking about the C# compiler or the JITer. The latter one is the component that is critical for performance and lacks quite a bit behind Sun's/Oracle's HotSpot JIT compiler when it comes to inlining virtual method calls, not to mention optimizing C++ compilers (of course, C++ compilers don't need to compile on the fly, so that's not really a fair comparison).

  Mono runs applications with severely lower performance than the .NET Framework on Windows. Really no need to comment more on this.

  Until recently, yes. I don't have up-to-date measurements, but I suspect that their new GC and the LLVM backend might change this in the not too distant future. Well, hopefully...

• F# 3.0: data, services, Web, cloud, at your fingertips

  Sep 17, 2011 at 4:10 PM

  @MauricioScheffer: Nice! +1

• Future directions for C# and Visual Basic

  Sep 17, 2011 at 2:50 PM

  7 minutes ago,bcooley wrote

  This matters because .NET is the primary development platform for mobile devices, and these devices are underpowered relative to the desktop.

  And I suspect, that's one of the reasons why they chose to base WinRT on an updated version of COM with CLI-like meta-data and a poor man's CTS instead of directly taking the fully managed path.

See more comments…