In the cuRAND documentation, both types curandState_t and curandState are used. Are there any difference between them?
http://docs.nvidia.com/cuda/curand/device-api-overview.html#device-api-overview
They are the same. In curand_kernel.h you will find this:
typedef struct curandStateXORWOW curandState_t;
typedef struct curandStateXORWOW curandState;
i.e. both types are aliases of the state for the default XORWOW generator state type.
Related
I have a recursive datastructure I want to store in shared memory. Thus far I have got this (simplified):
using namespace boost::interprocess;
typedef allocator<wchar_t,
managed_shared_memory::segment_manager>TCharAllocator;
typedef basic_string<wchar_t, std::char_traits<wchar_t>, TCharAllocator> MyShmString;
class Node;
template<>
struct sizeof_value<Node>
{
static const std::size_t value = *NodeSize*; <---??
};
typedef private_node_allocator<Node, managed_shared_memory::segment_manager> TNodeAllocator;
class Node
{
private:
MyShmString _value;
vector<Node, TNodeAllocator> _children;
};
If you fill in a number for Nodesize it compiles and runs. You can get this number by compiling and printing a sizeof(Node). This is not very robust. I have tried using a forward declared constexpr function returning the size of Node, but this does not compile (on MSVC).
Is there another way to solve this?
If I understand correctly the only source of complication is with declaring datastructures that entail incomplete types.
If the boost::interprocess::sizeof_value<> specialization works, that would be enough.¹
In terms of robustness, it is easy to add a static_assert after the definition of Node has become complete to ensure that the actual value matches the size reported by the compiler:
static_assert(boost::interprocess::sizeof_value<Node>::value == sizeof(Node), "sizeof mismatch");
¹ I have a hunch it can be done without that, but I cannot spend the time to make your code self-contained right now to check
I want to specify that a certain type reported by Boost TypeIndex boost::typeindex::type_id<T>().pretty_name() would yield a specific name.
The problem I want to solve is that, as reported in other places, there is a particular case that is confusing, that is the std::string type (or alias) gets reported as std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >.
(I understand the reason for this, std::string is an alias. I just want to override the reported string in this particular case.)
I followed the instructions here http://www.boost.org/doc/libs/1_59_0/doc/html/boost_typeindex/making_a_custom_type_index.html and the beginning of the custom code looks like this:
namespace my_namespace { namespace detail {
template <class T> struct typenum;
template <> struct typenum<void>{ enum {value = 0}; };
template <> struct typenum<std::string>{ enum {value = 1}; };
struct my_typeinfo {const char* const type_;};
const my_typeinfo infos[2] = {
{"void"}, {"std::string"}
};
...
...
But at the end, the most I can do is to replace one type reporting by another, instead of just amending one case.
One light weight solution could be to specialize boost::typeindex::stl_type_index (the output type of type_id<std::string>()) but by then the actual static information of the class is lost. (there is no class to specialize.)
But this cannot be done without a full specialization of typeid<std::string> which seems to difficult to do.
Is there a workaround for this? I would prefer a solution within Boost.Typeindex rather than runtime string replacement.
This is a very dirty way I found but it is not perfect and can create other problems down the road.
struct std_string{}; // dummy replacement class name
namespace boost{
namespace typeindex{
template<> boost::typeindex::stl_type_index type_id<std::string>() noexcept{
return type_id<std_string>(); // will report "std_string", ugly, but better than `std::__cxx11::basic_string<...>`
}
}}
I am learning cpp. I thought that memeber type are functions/variable which belong to a type.
For exanple in the following
class person
{
public:
string name;
int age;
};
name and age are member type (in this case member class) of the person class.
Recently I started to read about <chrono> library, and thaen I started to confused.
There is for example class system_clock which has time_point member type. But on the other hand there is also class time_point which has Clock member type (e.g class system_clock).
How can a class contains sompe type as a member type and also be a member type of its own member type.
I hope that I succeeded to explain my confusion.
You are confusing non-static data members with nested member type aliases.
Examples of non-static data member are name and age in:
class person
{
public:
string name;
int age;
};
name and age store values inside a specific instance of person. They have an address in an lvalue instance of person so you can find out what that address is:
person p;
string* np = &p.name; // this is where p.name lives in memory
A nested type alias does not occupy storage. For example:
class person
{
public:
using name_type = string;
string name;
int age;
};
person::name_type is a type alias for string. It doesn't occupy storage. You could use it to create a string:
person::name_type x = string{};
system_clock::time_point is a type alias for:
time_point<system_clock, system_clock::duration>
time_point::clock is a type alias for Clock in:
time_point<Clock, ...>
So, time_point<system_clock, system_clock::duration>::clock is the same type as system_clock.
system_clock does not store a time_pont. Indeed, it does not store anything at all (no non-static data members).
time_point does not have a clock as a non-static data member. time_point only stores a duration which has the type of time_point's second template parameter in:
template <class Clock, class Duration = typename Clock::duration>
class time_point;
These type aliases might be used like this:
system_clock::time_point tp = system_clock::now();
Though the use of auto here is much easier (and my preference):
auto tp = system_clock::now();
Use of time_point::clock might come in handy if you had a generic time_point and you needed to call now() for whatever clock that time_point is measured with:
template <class TimePoint>
void some_function(TimePoint tp)
{
using Clock = typename TimePoint::clock;
auto now = Clock::now();
...
This latter use-case is more rare, but the capability is there if you need it.
In general, when learning about <chrono>, most people do better by reading tutorial-like information about it, or looking at example code, or reading other's Stack Overflow questions about it. When people try to learn about <chrono> by studying its implementation, they invariably have a strong negative reaction to its relatively complex implementation.
Its implementation is relatively complex because it is far more powerful than alternatives such as timespec. However its common everyday use has very simple and safe syntax. For common use cases you don't even need to know that everything is templated. You can just use things like system_clock::now(), nanoseconds and hours.
I recommend reading some of the [chrono]-tagged questions. I also recommend reading parts of the <chrono> proposal found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm
The committee itself needed a tutorial on this subject, and this paper contains a pretty good one. Skip the parts containing proposed wording unless you're in need of a sleeping aid. The paper is somewhat dated in that a few details have changed, but not many. One example is that monotonic_clock has since been renamed to steady_clock. Another detail is that constexpr has since been generously applied. And user-defined literals have since been added to the 6 concrete duration types.
Finally, Nicolai M. Josuttis' second edition of The C++ Standard Library - A Tutorial and Reference has a nice section on <chrono>.
I am new to boost and also boost graph library. Could anyone explain what is the implementation behind the property_map and what is the time-complexity of the operator [] in the following code?
Thanks!
#include <string>
#include <boost/graph/adjacency_list.hpp>
int main()
{
using namespace boost;
typedef adjacency_list<listS, listS, directedS,
property<vertex_name_t, std::string> > graph_t;
graph_t g;
graph_traits<graph_t>::vertex_descriptor u = add_vertex(g);
property_map<graph_t, vertex_name_t>::type name_map = get(vertex_name, g);
name_map[i] = "Joe";
return EXIT_SUCCESS;
}
You can create a property map by giving an std::map to it. So the time and space complexity is probably the same as the underlying std::map. You might want to look deeper into the STL documentation of a Sorted Associative Container.
I've wondered this myself and find it odd that boost::graph documentation doesn't make this clear as questions such as this are highly relevant to performance critical algorithms/applications.
In summary I believe the answer is yes, it is O(1) time complexity. My reasoning follows.
Since the property map concepts are just concepts, it makes no guarantees about the complexity. So we have to look at adjacency_list's implementation of a property map to know its complexity. I believe the relevant code is found in boost/graph/detail/adjacency_list.hpp; search for "Vertex Property Maps".
template <class Graph, class ValueType, class Reference, class Tag>
struct adj_list_vertex_property_map
: public boost::put_get_helper<
Reference,
adj_list_vertex_property_map<Graph, ValueType, Reference, Tag>
>
{
typedef typename Graph::stored_vertex StoredVertex;
typedef ValueType value_type;
typedef Reference reference;
typedef typename Graph::vertex_descriptor key_type;
typedef boost::lvalue_property_map_tag category;
inline adj_list_vertex_property_map(const Graph* = 0, Tag tag = Tag()): m_tag(tag) { }
inline Reference operator[](key_type v) const {
StoredVertex* sv = (StoredVertex*)v;
return get_property_value(sv->m_property, m_tag);
}
inline Reference operator()(key_type v) const {
return this->operator[](v);
}
Tag m_tag;
};
I believe this is the property map that is used for internal properties for an adjacency_list that is instantiated with a ListS VertexList type, as in your example. You can see that the operator[] takes a Graph::vertex_descriptor which appears to be some handle, maybe an iterator, and accesses the property structure directly without lookup, sv->m_property, thus constant time. The call to get_property_value() appears to be for property tag resolution when you have multiple properties associated with each vertex; in your case you only have one. Tag lookup is typically also constant time.
Instantiating a adjacency_list with properties with a VecS VertexList type also appears to give O(1) time complexity in property map lookup. The type used there appears to be vec_adj_list_vertex_property_map and the opearator[] uses the Graph::vector_descriptor in what appears to be an index into a vector of properties per vertex, thus O(1).
In retrospect, I suppose I would expect that because the library works so hard to be performant, it would ensure that this is also performant.
This question is out of pure curiosity. How does Cocoa define the id type? Is it just a typedef for a void *? Also, if you know which header file it is defined in, I would be interested in taking a look.
Hold down the command key and double click on any highlighted term to jump to its definition.
typedef struct objc_class *Class;
typedef struct objc_object {
Class isa;
} *id;
typedef struct objc_selector *SEL;
typedef id (*IMP)(id, SEL, ...);
It is delcared in /usr/include/objc/objc.h (on Leopard) as follows:
typedef struct objc_object {
Class isa;
} *id;
Which means it is not void * at all, but rather a pointer to a struct that contains a single member, pointing at the class definition. Interesting indeed.
I remember when I was just getting into C and learning that Objective-C was initially implemented as just a preprocessor layer on top of C. It isn't quite like that anymore.
The best reading on the topic I've found:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
in objc.h
typedef struct objc_class *Class;
typedef struct objc_object {
Class isa;
} *id;
To find out on your own, in XCode, right click id -- or any other type -- and select Jump to definition. It's interesting to note the similarities to other C/C++ based object systems; an object pointer -- an id -- points to a struct that starts with a point to shared class information. I many C++ implementations, that would be the virtual function table, as it would be with Microsoft's COM. In Cocoa, the particulars of objc_class aren't revealed to us in the header file.
The id type is generally declared like:
typedef struct objc_object *id;
This is critical for Objective-C++ where the type is part of a mangled function name.
You can take a look in /usr/include/objc/objc.h
You can refer the doc here : http://opensource.apple.com/source/objc4/objc4-437/runtime/objc.h
Hope this will do a favor for you