Does D's standard library contain some kind of pointer/smart pointer wrapper like not_null from the C++ core guidelines? Or maybe there is a well-known implementation?
As far as I know there is no such thing, perhaps because D developers decided that Nullable(T) is more useful. I am sure you can shift the not_null logic into Nullable(T) logic easily...
Not in the standard library, no. There's a Dub package for it, and it's been discussed numerous times on the forum.
Related
Recently, it's not impossible for boost serialization to refine with respect to stuff in C++11 standard library. Meanwhile I need a serialization as well as reflection library for my project. I searched around and didn't find any.
Therefore I'd like to know if there is existing one (hmm...it must be brand new to be C++11 compatible, not the aging MFC) or any basic, practical and explicit guidance about making my own. As far as I think, the rationale is to deduce on type with those helpers in STANDARD <type_traits>, which has already been adopted in boost serialization without std namespace.
This might be as insignificant to you as to pick pebble out of egg, but I just can't make myself happy with boost.
To actually answer this, albeit a little late: There now is cereal which is apparently exactly what you've asked for.
Well, if you want a complete serialization solution, maybe you can try ROOT reflection. But this is not a light library. On the other hand, it's a complete solution.
I'm still in the process of learning C++ concepts, but I'm fairly comfortable with pointers, references, Object Oriented Programming, and other programming basics. But I still need to learn more about templates, iterators, and regular expressions. Are there any other concepts I should have a firm grounding in to get the best use out of Boost libraries?
There is no such thing as "proper" use of Boost. You use that part of Boost that helps you with your problem. For Boost Test, for example, you don't have to know much about anything specific. For Boost Graph or Algorithm, you should have a good grasp of templates.
Hence, there's no good way to answer your question. Look at the documentation of the library you want to use (Boost or otherwise), and if you think you can handle it, use it. Otherwise, come back here and ask a more specific question. ;-)
You should know how templates and inheritancy works and read carefully the documentation of the module you are planning to use. It should be enough for most cases.
Hard to say since boost is really a collection of libraries. You should have knowledge of the problem domain before using a library. For example, what are threads and how to deal with them before using boost.thread.
As for C++ specific stuff:
You should know what the standard library already provides you.
Have a firm grasp on how to use templates
Edit: What I'm really thinking of is a C++ equivalent to the Contrib libraries other languages enjoy, like CPAN/PyPI/Ruby Gems
Suppose I want a collection type that isn't really supported by anything in the STL or by BOOST, like a spacial index or a fibonacci tree (if i think that might be useful on my really big dataset). Is there a good place to find these kinds of less common tools?
Sometimes Vault has useful things. maybe you can find something there.
As it is said, google is your friend :-)
It appears that here (http://resnet.uoregon.edu/~gurney_j/jmpc/fib.html) is an implementation of Fibonacci heap in C. Check it out, and if you like it, may be you can translate/modify/improve to a C++.
Well, I don't know if there are any actual 'collections of libraries', but i'll start a list of useful libraries. (C++ libs only, please)
There's Boost, obviously, but also Boost Vault, which appears to contain libraries that aren't quite ready for inclusion in Boost proper. (thanks aaa carp for pointing this out)
GMP, an arbitrary precision number library, has C++ bindings
Qt, which is about as old as the moon, but also modern enough to still be useful. This of course is a heavy handed application library, but there's no real reason not to use whatever parts could be useful. I'm not too sure how esoteric that really is, though. Outside of the GUI portions, most functionality would already be duplicated by boost.
libCurl has c++ bindings, for http access (and other things)
D easily interfaces with C.
D just as easily interfaces with C++, but (and it's a big but) the C++ needs to be extremely trivial. The code cannot use:
namespaces
templates
multiple inheritance
mix virtual with non-virtual methods
more?
I completely understand the inheritance restriction. The rest however, feel like artificial limitations. Now I don't want to be able to use std::vector<T> directly, but I would really like to be able to link with std::vector<int> as an externed template.
The C++ interfacing page has this particularly depressing comment.
D templates have little in common with
C++ templates, and it is very unlikely
that any sort of reasonable method
could be found to express C++
templates in a link-compatible way
with D.
This means that the C++ STL, and C++
Boost, likely will never be accessible
from D.
Admittedly I'll probably never need std::vector while coding in D, but I'd love to use QT or boost.
So what's the deal. Why is it so hard to express non-trivial C++ classes in D? Would it not be worth it to add some special annotations or something to express at least namespaces?
Update:
"D has namespace support in the works" from Walter Bright.
FWIW Qt has an actively developed binding for D: http://www.dsource.org/projects/qtd
I think many components in boost are too highly tied to C++ to be portable meaningfully to other languages.
Using e.g. std::vector is possible if you spend the time on writing regular (e.g. namespace-level) functions that forward to the appropriate member functions. Tedious, but affordable (for higher-level components; probably not for std::vector).
Also, I very recently checked in the standard library a sealed array and sealed binary heap implementation that use reference counting, malloc/free, and deterministic destruction instead of garbage collection (see http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/container.d). Other containers will follow. These containers use three specific techniques (described in my upcoming article "Sealed Containers") to achieve deterministic destruction without compromising program safety.
Hopefully sealed containers will obviate any need to link with STL containers, even for tight applications that can't afford garbage collection.
As Hans Passant mentions in a comment, the level of interoperability you want between D and C++ isn't even supported among different C++ compilers. There is a C++ ABI (Application Binary Interface) standard that seems to have some support, but I'm not sure exactly how extensive (Intel, GCC and ARM compilers seem to follow the ABIs). I haven't had a need to use it, and I'm not sure whether or not Microsoft adheres to it for their x86 or x64 compilers (I imagine it might for ia64, since that's where the ABI standard started).
See "Interoperability & C++ Compilers" by Joe Goodman for some details on the C++ ABI.
Maybe Walter Bright can be convinced to support D interoperability with C++ libraries/objects that follow the ABI standard (though I'm not sure where he might prioritize it).
Just for fun I've been interfacing to some C++ code.
That probably won't answer for your question, but I think you (and some folks among the D community) might be interested in some notes I've made then. Here it goes: TechNotes.
I mainly use C++ to do scientific computing, and lately I've been restricting myself to a very C-like subset of C++ features; namely, no classes/inheritance except complex and STL, templates only used for find/replace kinds of substitutions, and a few other things I can't put in words off the top of my head. I am wondering if there are any official or well-documented subsets of the C++ language that I could look at for reference (as well as rationale) when I go about picking and choosing which features to use.
There is Embedded C++. It sounds mostly similar to what you're looking for.
Google publishes its internal C++ style guide, which is often referred to as such a subset: https://google.github.io/styleguide/cppguide.html . Ben Maurer, whose company reCAPTCHA was acquired by Google, describes it as follows in this post on Quora:
You can basically think of Google's
C++ subset as C plus a bit of sugar:
The ability to add methods to structs
Basic single inheritance.
Collection and string classes
Scope based resource management.
They also publish a lint tool, cpplint.py.
Not long ago I listened to this SE-Radio podcast - Episode 152: MISRA with Johan Bezem, which introduces MISRA, standard guidelines for C and C++ to ensure better quality, try looking at it.
The GCC developers are about to allow some C++ features. I'm not aware of any official guidelines, yet, but I am pretty sure that they will define some. Have a look at initial report on the mailing list.
Well, latest developments (TR1, C++0x) in C++ made it very much generic, allowing you to do imperative, OOP or even (limited) functional programming in C++. Libraries like Boost also enable you to do very power declarative template-based meta-programming.
I think Boost is the first thing to try out in C++. It's a comprehensive library, which also includes several modules that enable you to program in functional style (Boost.Functional) or making compile-time declarative meta-programming (Boost MPL).
OpenCL has been using C for writing kernels, but they have recently added (or will soon add) C++ bindings and perhaps Java. OpenCL leaves out a number of performance robbing features of C. Excluded are things like function pointers and recursion. Smart pointers and polymorphism also create overhead.
Restrictions on C:
SIMD programming languages
Slightly off topic: Here is a good discussion comparing OpenCL with CUDA using C.
OpenCL or CUDA Which way to go?
The SEI CERT C++ Coding Standard gives a list of rules for writing safe, reliable, and secure systems in C++14. This is not a subset of C++ per se, but as a coding standard like the other answers is a subset in effect by avoiding unsafe, undefined, or easily-misused features (including some common to C).