Two things, they define what is important to me. I seriously don't like the gym, living in Colorado, being indoors is just depressing. Currently pursuing both my passion with machine vision as well as riding every trail I can find.
Interesting to call this a bucket list, I plan on doing these all within the next year or two, though some of them may kill me, which brings the whole bucket list concept back.
Super Walker
From my apartment off Walnut, ride to baseline, and then west past Chautauqua, up flagstaff, continue on to Walker Ranch, do the clockwise loop (I may call an audible here, and go counter to the canyon and reverse, no hike-a-bike that way), and then head back home.
Enough said. This should make for a rough day! I like how few people are on the leaderboard, time to see my name there!
Golden Monster
Not sure if this is official or not, but hereās the plan:
Starting from the Chimney Gulch trailhead, ride up Chimney to the top of lookout mountain. Head along the road to the top of the Apex trail. Bomb down Apex, making sure that itās an even day of the month so that Enchanted can be ridden. From the Heritage Square lot, head south to the Dakota Ridge trail, ride up the crappy service road, play in the first part of the rock gardens before you hit the step-ramp things. Take the Zorro trail down the ridge, cross over to Green Mountain, play around there for a bit (I donāt know this trail system well at all), return back up Zorro and continue the Dakota trail south. Cross over the road and head up the Matthews/Winters trail. Persevere, take the left trail at the fork, and fight the maddening switchbacks with nasty tech. Hit the top, enjoy the views, ignore the glares from entitled hikers, ride down the mountain, return to Apex and do the reverse by heading up the mountain and down Chimney.
The Cougar Slayer
https://thecougarslayer.wordpress.com/
I signed up for the Aug 30th 2015 race day. Both excited and incredibly anxious about this one. I may have gotten myself in way over my head.
Assuming the Cougar Slayer went ok, this will be the August race of next year, hopefully. I have to win the lottery to race it, that along with fitness will be the real factors. Time to take an avalanche course this winter so that I can AT ski; I hear that requires some serious stamina.
The Colorado Trail
http://www.mtbproject.com/trail/479729
Thatās right, the whole damn thing! I was originally planning on doing it this year, but the unfortunate May weather followed by my bike being out of commission for most of June squashed my plans for this year.
Half-Baked Concepts
Ride Crested Butte to Aspen
Something something Moab
Somewhere in the PNW
Travel to a different continent and ride that stuff
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
ā Live Streamingā Interactive Chatā Private Showsā HD Qualityā Free Actions
Free to watch ā¢ No registration required ā¢ HD streaming
Well, I suppose I am bringing back my own blog. I thought, back when I started this, that this would be a release mechanism for me. Itās not that I was wrong, I just failed to account for how life doesnāt care about my plans.Ā
Not in the slightest.
So, what has happened since I wrote my first post? Well, for one, I stopped caring a lot about software elegance. Reading around online, this actually seems to be a common theme, where the more experience one accumulates, the less one really cares about the best design pattern, or whether itās ām_ā,Ā ā_ā, or whatever else a member variable is supposed to be prefixed with. For me, the catalyst for this change was moving from a software engineering heavy role to a research heavy role. When 90% of my code is going to be thrown away, by design, then what is the purpose of the elegance of my code? Just make it run fast enough, and well enough in the way it needs to. Iām not being prescriptive, just pragmatic to my situation. If your code is going to be heavily maintained by others, then please make it coherent.
More personally, I also exited the longest relationship of my life a year ago. This situation has been completely surreal, being shoved out of my comfort zone and back into the rest of the world. With adjusting back to the single life, I have also finished my computer science degree, sold my house, moved to the city Iāve wanted to live in for years, and will be embarking on a new career journey at the beginning of August. Exiting this relationship has been one of the most positive things to happen to me for a very long time. I do not say that with malice, I donāt have time nor the energy to be angry, I say it simply because it wasnāt working out between us. It was a bad, but familiar situation for both of us, which kept us both stuck in something that wasnāt right.
Maybe we all cling to something new when we are resetting our lives, but in my case, I am doubling down on biking. Itās a consistent source of happiness and passion for me.
So, Friday is my last day with AlchemyAPI. This is a group of people that I really enjoy working with. They are all awesome people, and are exceptionally smart as well. Unfortunately, and this is just something that happens, I realized that where I wanted to take my career was not in line with where Alchemy is focusing right now. This happens, and like a relationship that isnāt quite right, it is always important to introspect on our lives and make sure that where we spend our precious time is where we truly want to be spending it. I start my new job on the 3rd of August, and I am really excited about it! If there is one common theme to the past year, and to this blog post, itās that I am realigning how I actually live my life to how I want to live my life.Ā
I am also excited about the week off that I have between leaving Alchemy and starting the new job. I have decided that if I can walk at the end of this nine day break, then I did something wrong. I will be starting it off riding the Super Walker from my new apartment, up flagstaff, do the Walker loop, and then back. It should be absolutely brutal, and I canāt think of a more enjoyable way to kick things off. I also will be capping the trip with four days in Crested Butte, assuming I can find a place to sleep in between rides.
This may not be the most revolutionary opinion on header files, but here goes.
(Note: when I refer to header files, what I really mean is header/cpp file as a paradigm)
I am not sure I really understand the point of header files, from a conceptual level. I am not going to argue that they aren't necessary (hey, a compiler might actuallyĀ needĀ to separate the two for internal reasons), but I will argue that from a functional standpoint, they really only cause problems.
To explain this point, lets attack header files from what is probably the best case for their usefulness: providing a quick overview of an object, or function chunk. Header files are great at giving you an object summary, where you can quickly glance and see what an object does, as well as the public contracts for the file.
The problem with the above statement is that header files not only show you the public details of a contract, it also shows you all of the private parts of the contract. This clutters header files, which are best serviced as a public only contract between two components.
There are 2 reasonable ways to get around the above:
Create a pure virtual base class (Interface) that only exposes the public parts of the object, and pass that around. Interfaces are great because they conceptually enforce that the implementation is not importing to the consumer. One major drawback is that now you have virtual class overhead, so the compiler may not be able to optimize your type the same way.
The pimplĀ idiom. This allows you to hide all of the internal workings of a class by declaring an impl opaque pointer that isĀ generallyĀ implemented in the source file. The drawback of this is run-time overhead (you have to allocate an object on the heap almost always).
Here is one side effect of header files that I am sure happens frequently. Since a function must be represented in 2 files now, and maintained in sync, there are 3 common outcomes of this, 2 of which aren't good.
The programmer chooses not to encapsulate that function. This happens a lot for minute constructs that aren't necessarily bad, but end up duplicating a lot.
The programmer goes the inline route, and implements the entire function inside the header file. This isn't bad in and of itself, but it is bad because it goes against the paradigm of separate files. I don't want to get into a flame war about inlining, because there are a lot of reasons for this to exist, and has great properties (see: Templates), but this is not a good reason for an inline function.
The programmer is disciplined and creates the damn function because he is a purist and pedantic.
At the end of the day, the one real win for separate files is for a quick summary view of source code, but most modern IDE's provide you a summary view of an object in 3 different ways, so it's not really a win anymore. Because of this, the world seems simpler just merging the two files.
One thing that a lot of higher level OO languages (higher than C++) have going for them is having a single base class to rule them all. I am talking about 'object'. In C#, this class can represent any object in the program, and also allows you to get a string version of this object.
C++ on the other hand has no such construct. This is both good and bad. On the good side, it falls in line with C++'s tenet of "pay for only what you use". Forcing all objects to share a single base class causes 2 things to become hard:
Ā C interop becomes hard because you no longer have PODs
Ā Every class is now virtual and has a v-table.
Ā Ā Ā Ā Ā i) The destructor is virtual so cleanup is no longer trivial for RAII patterns
Ā Ā Ā Ā Ā ii) The v-table takes up an extra pointers worth of memory, so data size compression becomes trickier
For those reasons, I love that C++ doesn't enforce such a base class. However, it does make things much trickier when you just need some data to be carried through the system in a transparent way, until someone later down the road can unpack it and use it. For this reason, you often see "void *" getting thrown around a lot (especially in C api's). I am going to be so bold as to say "void *" sucks! It sucks for so many reasons that I should probably create another post for it.
In this post, I would like to talk about an implementation in C++ that allows you to store anyĀ data type transparently, while still preserving type safety. Before you blast me and say boost::any already does this, my container also supports polymorphism.
Here are the goals for this container:
It should be reference counted, so that the data can be shared amongst any number of owners safely.
It must allow any data type, be itĀ intĀ orĀ Foo.
The container must be type safe, so that you can't get a handle to invalid or corrupt data
The container must allow polymorphism to work properly. What I mean by this is that someone should be able to put a derived class into the container, and request it back as the base class.
The container should provide simple mechanisms for getting data into the container, be it a pointer, or a copyable data type. If the type is a pointer, the simplest method should also take ownership of the pointer and callĀ deleteĀ whenĀ the data is no longer used.
To implement this container, I am going to use a technique called Type Erasure. This essentially means taking a bunch of classes with a common interface and providing access to them all through a single interface. Here is the base interface for the container:
class GenericData { public: typedef boost::shared_ptr<GenericData> Ptr; virtual ~GenericData() { } template<typename T> T &GetData() const { try { // GetDataInternal will return a void* to the stored data object. // If typeid(T).hash_code() is not equal to the hash code of the stored type, // an exception is thrown that contains the name of the stored type for the exception message return *(T*)GetDataInternal(typeid(T).hash_code()); } // The types are not compatible catch (std::exception &ex) { auto fmt = boost::format("Unable to retrieve generic data. The requested data type was '%1%', but the stored type is '%2%'") % typeid(T).name() % ex.what(); throw std::exception(fmt.str().c_str()); } } template<typename T> T GetDataDyn() const { try { // The following function will throw the actual stored data. // If 'T' is the stored type, or is a base class for it, the catch handler will // trigger and we have a pointer to T at this point. It is a cool trick that abuses // the exception system, but is otherwise necessary. ThrowDataInternal(); throw std::exception("Unreachable"); } // verify_pointer is a class that prevents the use of non-pointers // This is important because an exception handler will clean up the argument to the handler, // and if the argument is not a pointer, it will have its destructor called // // 'type' is simply T, but T MUST be a pointer catch (const verify_pointer<T>::type &data) { return const_cast<T>(data); } catch (...) { // 'T' does not live in the same inheritance hierarchy as the stored type } return nullptr; } protected: // This method will return a pointer to the stored data. // If typeHash does not match the hash code for the stored data type, an exception is thrown virtual void *GetDataInternal(size_t typeHash) const = 0; virtual void ThrowDataInternal() const = 0; // Returns the name of the class of the stored type virtual const char *GetName() const = 0; };
That is it for the base class. I did omit some of the functions for brevity.Ā
The "GetData<T>" function is what you would use if your class is not polymorphic, or you know exactly what type is stored in the container. This function will throw an exception if T doesn't exactly match the type of data stored in the container.
The "GetDataDyn<T>" function allows you to access the stored data using any T that is within the inheritance hierarchy of the stored type. This function enforces that T is a pointer type.
The next step is the implementation:
template<typename DataT> class GenericDataImpl : public GenericData { public: GenericDataImpl(const DataT &data) : _data(data) { } const DataT &Data() const { return _data; } protected: virtual void * GetDataInternal( size_t typeHash ) const { // Get the hash code for the stored type static const size_t DATA_HASH_CODE = typeid(DataT).hash_code(); // Check to make sure that the stored type hash code matches the hash for the requested type (i.e. they are the same type) if (typeHash != DATA_HASH_CODE) throw std::exception(GetName()); // const_cast isn't technically necessary, however the returned type is 'const DataT *' and the requested type is 'DataT *' so this just keeps them the same return const_cast<DataT*>(&_data); } virtual void ThrowDataInternal() const { throw _data; } virtual const char *GetName() const { return typeid(DataT).name(); } private: DataT _data; };
This class is relatively self explanatory. The reason we are doing a const_cast is because the scope of the function is const, so we would technically be returning a "const DataT *" but I don't like void * voodoo, so I want the types to be the same on both sides of the wormhole.
Finally, we just have a few holes to fill before you have the full implementation (I will post the source so that you have that if you are lazy):
template<typename T> class DefaultDeleter { public: void operator()(const T &val) const { // This is a no op because T is not a pointer, and therefore is automatically destructed } }; template<typename T> class DefaultDeleter<T*> { public: void operator()(T *val) const { // Delete the pointer. This will fail for arrays, so don't use it for arrays delete val; } };
Similarly, we will use the partial specialization trick to enforce that T is a pointer for the GetDataDyn class.
// These structs are here to ensure that no one tries to access GetDataPoly with a type 'T' that is not a pointer type. // This is because the cleanup for the exception block will actually call the destructor on our type, which is not good template<typename T> struct verify_pointer { static_assert(sizeof(T) == 0, "Using generic data polymorphism requires the data be a pointer, however one was not provided"); typedef T type; }; template<typename T> struct verify_pointer<T*> { typedef T* type; };
Since we are using verify_pointer<T>::type as the exception handler argument, we are forcing the compiler to decide whether or not T is a pointer, and if not, the static_assert will trigger and fail the compile.
Finally, we just have the creation functions:
// Constructs a generic data using the specified data, and the specified deleting functor. The functor needs the "operator()(const DataT &val) const" operator. template<typename DataT, typename DeleterT> IGenericData::Ptr make_data(const DataT &data, const DeleterT &del, bool shouldTransfer = false) { return IGenericData::Ptr(new GenericDataImpl<DataT>(data, shouldTransfer), [del](GenericDataImpl<DataT> *data) { del(data->Data()); delete data; }); } // Constructs a generic data using the default lifetime for the supplied object. // This means that the destructor for the data item will get called when the GenericData shared pointer gets freed. This works for pointers and regular items. This does, however, corrupt your heap if you use it on an array. template<typename DataT> IGenericData::Ptr make_data(const DataT &data, bool shouldTransfer = false) { return make_data(data, DefaultDeleter<DataT>(), shouldTransfer); } template<typename DataT> IGenericData::Ptr make_array_data(DataT *arrData, bool shouldTransfer = false) { // Use a lambda that uses the delete[] which works for arrays auto del = [](const DataT *&d) { delete[] d; d = nullptr; }; return make_data(arrData, del, shouldTransfer); } template<typename DataT> IGenericData::Ptr make_no_delete_data(const DataT &data, bool shouldTransfer = false) { // Using this construction method, the lifetime of the data object is outside of the data container, and must be managed externally. auto del = [](const DataT &d) { }; return make_data(data, del, shouldTransfer); }
That is all. If you have questions, feel free to ask. I can also provide the actual source if you need me to.
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
ā Live Streamingā Interactive Chatā Private Showsā HD Qualityā Free Actions
Free to watch ā¢ No registration required ā¢ HD streaming
Ray Traced image of a few of the (same) trees, with a moonlit background. The spheres are because it's a ray tracer, but the caustics are what make the scene interesting. I figure this is a good first post because I do plan on talking about a Ray Tracer implementation, so here is the teaser.
Algorithms or Exercise @mranzinger-blog - Tumblr Blog | Tumlook
