CGAL: Modify an extended DCEL fetched from a locate call - c++

I have an Arrangement_2 class, instantiated with a custom Arr_face_extended_dcel to map some data to each cell.
I'd like to find some cells with a locate invocation and change their associated data, but unfortunately locate returns an iterator to some Face_const_handles, so I can't invoke set_data(...) because that would break the constness.
So, my question: is there a way to efficiently change the data mapped to a face found with a locate without resorting to nasty const_casts?

You have to use the overloaded member template functions non_const_handle() of the Arrangement_2 template class. There are 3 versions, which accept Vertex_const_handle, Halfedge_const_handle, and Face_const_handle, respectively; see the manual.
BW, const_cast<> will not work. because, for example, Vertex_const_handle and Vertex_handle are simply different types.

Related

Generic Mutator/Accessor functions

Is there a way to create generic set/get functions in C++? I have a class with a large number of attributes but no functions (ok I should probably use a struct), and really don't want to write individual set and get functions for each data member. The functions I'm thinking of would be something like 'set_member( T variable ), where T could be anything, primitive types or user defined. I imagine perhaps you could create a struct with a struct as a member, then whenever you want to access a specific member of the member struct, you refer to it by the appropriate pointer. I've tried writing something to achieve this but no luck so far.
C++ has (as far as I know) no inbuilt way to autogenerate setter/getter functions.
You might be able to work some macro-magic (with all its pitfalls), otherwise your options are slim.
I can think of following alternatives:
Some IDEs generate get, set methods automatically for the data members of class. I am not sure if it is possible for C++ IDE. But I know that Eclipse IDE for Java does it. You may check once if Eclipse IDE for C++ has this facility.
You may write a short shell script or python script for automatically generating get, set method given a text file containing names and types of variables in each line.
By default all the members of struct are public. So use struct. Or if you decide to use class, then, put all the data members in public section. If you are not doing anything other than simple set, get, then, it might be ok to do so. However, debugging will be tedious in case if you encounter issues with changes in the data members.

How to achieve constexpr pseudopolymorphism?

In a ray tracing project that I'm trying to make compile-time (constexpr) for fun and challenge, I've run into a bit of an issue: I have an object (intersection) that needs to refer to one of a group of other objects (shapes).
Now, my understanding is that you cannot use polymorphism / virtual methods with constexpr because of the vtable lookups, so as far as I know, I cannot have a superclass, Shape, from which the other classes derive. Thus, I need to make Intersection a template class that holds one of its shapes.
Unfortunately, I need to store these Intersection classes in an array or some other container, and I want to be able to call a common function on them and their shape, i.e. where the pseudopolymorphism comes in.
I implemented something that solves the problem, where I take an std::array of std::variant and whenever I add to the array, if the type isn't represented by anything in the std::variant, then I expand it. I can also achieve pseudopolymorphism by using std::visit, invoking a commonly named function on each element to result in an std::array of final elements.
My implementation is here, in this gist. I thought it would be too long to post:
https://gist.github.com/sraaphorst/28998c109f94a78616e7dd488c1491d1
Now, I've been known to solve problems with much more difficulty than is necessary, so I was wondering if any of you know of a simpler way to achieve this?

Define std::hash<std::function>

I need to create a templated class that can hold pointers to elements of type T and then performs functions on them. The functions will come from different places, so I need a container to store them, so I can call them later. I decided to use an std::unordered_set, because it offers speed and restricts duplication due to it being implemented as a hash table. I have a whole class written, but it doesn't compile due to there not being a hash function defined for my std::function that takes a pointer of type T and returns void. It's easy enough to specify it with struct hash<std::function<void(MyCustomType*)>> (and overloading the () operator, too) for each type I use, but how do I actually hash the function?
Here is a watered-down excerpt from my class with the relevant members and methods:
template <typename T>
class Master {
private:
std::unordered_set<std::function<void(T*)>> functions;
protected:
registerFunction(std::function<void(T*)> function) {
this->functions.insert(function);
}
unregisterFunction(std::function<void(T*)> function) {
this->functions.erase(function);
}
};
I'm not completely bound to using an std::unordered_set, but it seems to offer everything that I'd need to get this piece (and the rest of my code) working well.
Am I thinking about this the wrong way? Is it completely impossible to hash a std::function?
A set is mostly something you will check that data is in it.
So I do not see the point of using one here... You'll have your functions and you'll store them in the set, and after that, what ? You just iterate on them ?
For your question, a element of a set should have a way to generate a hash and an operator==(). The second is not provided for std::function and thus you wouldn't be able to check that your function is really in the set.
So even if you find a way to generate an hash from the function, you would be stuck... And I do not see how to meet the hash requirement.
Why not simply use a std::vector ?

gtkmm treemodel adding rows

I'm somewhat confused as to how this ListStore works in this tutorial http://developer.gnome.org/gtkmm-tutorial/3.0/sec-treeview-examples.html.en
I understand pretty much everything except for the row[m_Columns.m_ITEM] = value
My issue is how it knows which column in the row to set the value to based on some other object that is passed to the overloaded []. Does it just check if the types are the same? If so then what happens if you have two columns of the same type? Does it work based on memory offsets to figure out which column it is?
I'm having a tough time figuring out how it goes from giving a member of the m_Columns instance to figuring out which column it should put the value in.
I guess if I could just get someone to explain how the internals work on the treemodel system that would be great, like what happens with creating and then each step of adding new rows and what not.
There's a bit of template trickery going on. The array operator in TreeRow is overloaded for each instantiation of TreeModelColumn<ColumnType>. To allow you to assign to the column as well as read it, it returns a proxy object (TreeValueProxy<ColumnType>) which actually implements those operations. Proxy objects are a standard C++ technique to implement array-like objects. The proxy contains references to the relevant TreeRow and TreeModelColumn<ColumnType> objects which it uses to do the actual work.
The TreeModelColumn<ColumnType> object also stores a gobject type corresponding to the type of the column, as well as an integer corresponding to the column position. This is eventually used to interface with the gtk+ library starting in TreeRow::set_value<ColumnType>() and TreeRow::get_value<ColumnType>().
The source files to look at if you want the messy details are here for TreeRow and here for TreeModelColumn.

Proper usage - accessors/getters vs normal methods

I am having trouble differentiating between accessors/getters, which represent object's properties and normal methods. In C++, the naming conventions for accessors and normal methods are different (e.g. Google Style guide suggests lower-case for accessors and PascalCase for normal methods). Moreover, the order of normal methods and accessors/getters (before or after) is also subject to conventions. In Java, one might have a dilemma whether a method should begin with "get" or "compute"/"find" to indicate a getter and a normal method, respectively. In C#, there is a dilemma what should be a property and what should be a method. Whenever I create a new class, I am not sure how to classify methods to normal methods and getters.
Is there an easy way to determine whether what is a property of an object / accessor/getter and what should be a normal method?
And does any of the following have something to do with differentiating between an accessor/getter and a normal method:
Computation is cheap
A new object (or a copy) is returned, instead of (const) reference
There is no setter
There is a way to influence that "property" but indirectly
To illustrate this, here is the example (in C++): Suppose I want to create a data structure which can hold a fixed number of elements, and apart from insertion/removal operations it offers a series of methods which work on the elements contained (i.e. average, median, minimum, maximum etc.). Now, take a function which computes the average for example; one might say that this is a property of an object and re-calculate it whenever an element is inserted/removed and thus treat it as a getter like const double& average(). The other way would be to compute it on-demand and treat it as a normal method, i.e. double ComputeAverage(). Also, suppose there is a method which returns a set of contained elements; it could be treated as a getter const set<int>& unique_elements() if there is no need to compute it every time, but if the class computes it every time then the set<int> ComputeUniqueElements() would be more appropriate.
Creating a separation between accessors and "normal methods" is a bad idea. A method is a method; it's a member function that has some specific effect. The fact that a member function simply sets the value of a member variable, or returns the value of a member variable, is an implementation detail.
And a good API isolates the outside world from implementation details. The outside world should neither know nor care that a particular function is just an accessor, if for no other reason than the fact that this can change.
Let's say you have a name "property" in your class. Originally, you store it as a std::string. You provide functions to get and modify the name. All well and good.
Now, let's say that you decide to change how the name is stored. You need to parse the name into a first name and a last name. Does the outside world need to know you're doing this? The name of your setter method doesn't need to change. It's interface doesn't need to change. All that needs to change is how you implement the function.
In C++, the naming conventions for accessors and normal methods are different (e.g. Google Style guide suggests lower-case for accessors and PascalCase for normal methods).
Google's Style guide does not represent C++ or its programmers; it only represents what Google does.