Cross origin compile on coliru seems not working now, neither on en.cppreference.com nor here. It was working just a few days ago. I was trying to do the same thing with coliru, any idea ?
k_pi and k_pi_inverse not defined
That is fascinating post and thank you for sharing. There are things here that I didn’t think some time recently. On account of cool such a position, to the point that is extremely elegantly composed. http://www.clazwork.com/proficient-accounting-essay-topics-writer
Thanks for you input.
How do you deal with rotating a model and avoid matrix multiplication?
i have some strong opinions about this stuff having worked a lot out for myself from nothing… vectors, matrices and trig are overkill to start with, and introducing them so early obscures the simplicity of what is actually necessary imo…
as an obvious example, generic matrix multiplication is pretty useless (and classically confusing) compared to the change of basis/coordinate system that happens to be the same operation as multiplying square matrices.
This is probably the most thorough explanation I’ve seen on this subject. I found the tables and tips for navigating hexadecimal to be really helpful.
Thanks for pointing that out.
Yes, the code you mention is a mistake, I will correct it.
I adapted my implementation from the version in the proposal paper I cite, N4115. Their implementation chooses to swap the parameters. This form didn’t feel intuitive to me.
I needed the pop_back function, so the latest file I have uploaded has some additional functionality:
- move_item (moves items between lists)
- split (splits a list at a specified pivot point)
Is there a mistake on line 195( of the downloadable file), if not could you explain the template parameters are reversed (the line is also shown in your “One Last Tip” example above on line 20) ? Thanks
Some minor issues folowed by fixes:
“prefer the format year/month/day.”
“prefer the format day/month/year.”
“Instead of doing one thing will,”
“Instead of doing one thing well,”
Thank for the compliment Larry.
Someone has to count, and I’m glad you took the time to correct me.
Damn clever presentation! Actually the terms coupling and cohesion predate the 1974 IBM Systems Journal article (Stevens, Myers, and Constantine). They were first used and described in a more obscure paper by me in the 1968 National Symposium on Modular Programming. But who’s counting.
–Larry Constantine (pen name, Lior Samson, author of Flight Track)
One more note:
I basically create two sets of windows, one if code highlighting styles, and the other set with editing styles.
Normally the editing styled windows are hidden. Then when you press run this code, the editing windows appear, and the others are hidden.
It’s not an elegant solution because I need to duplicate the code twice. However, I am happy with how it looks.
The JS file contains the code to send to coliru to compile and receive a response.
Thanks for the explanation! I’ll try to use your solution and let you know if it works on my site (based on blogger.com)
No, I haven’t tested any other alternatives, but coliru seems to be used quite often. So it seems it’s a good choice.
@Jamie, thanks for pointing that out.
@rightfold, I definitely agree. I think that public inheritance is overused mostly because it is misused. I also agree about templates.
One of the main points that I wanted to convey, is that devs may be trying too hard to reuse code by inheritance, when composition is all that is needed. Not even features like templates have to be employed to gain the benefits.
Nice post, although I think in languages that have good alternatives to inheritance, those may be preferred to achieve substitutability. For example, in C++ you would often use templates and concepts instead of inheritance.
Typo I think. 3rd paragraph:
“Tight coupling increases the probability that a component can be reused in more places, by limiting its capabilities to small well-defined tasks. For those of you keeping score at home, high cohesion is the realization of the S, Single Responsibility, in SOLID object-oriented design.”
That should begin “Tight *cohesion* increases the probability that a component can be reused in more places” should it not?
Thanks for the compliments.
This entry is based on a presentation I gave to colleagues at work for a “Lunch & Learn” session.
With my increased interest in unit-testing and generic-programming over the last 7 or so years I noticed that all of the classes and code that I reuse, as well as the C++ Standard Library are small concise objects.
I like metaphors, although I know they don’t immediately register for everyone. The Legos seemed like such a natural visual representation of an interface and how each of the different types of pieces interact.
Then add in the wisdom I have picked up from reading Meyers, Sutter, Andrescu, and Stroustrup…
Well, thanks again.
It wasn’t too difficult, but it did take me a few days to create a nice looking solution.
At first I started with a .js file I found from a GitHub project. However, it didn’t quite work the way I wanted it to.
I was aiming for the same behavior that is found on cppreference.com.
So I analyzed their HTML, modified the .js project from GitHub until I arrived at what I have now.
You can find the JS file that I created at this path:
With that I had to figure out how to integrate things with the CMS software that my site runs on, which I just created custom CSS tags for the compiled code windows.
If you would find it useful, I could write an entry on it, I have been considering that for a while.
One of the better entries that I have created that demonstrates the online compiler is the SFINAE article.
I haven’t looked into other online compilers because coliru has worked pretty well. Are you aware of any others?
Is it easy to integrate this button on other sites? How to do it quickly? Have you considered other alternatives?
Love your analysis and your example: So many have tried this and have failed to elucidate. Grouping the pieces by characteristic does clarify the use of the pieces and the case for reuse (and abstinence).
Great article! I love the use of Lego bricks to illustrate the problem ;)
About ugly code: unfortunately code abuse are occurring quite often and after several months/years all you have to do is to write a new code from scratch. Scarry…
Very insightful article!
… well I got coliru back up and running.
There are some things that I would like to do to allow the code to be compilable, without having to include so much text.
I need to tackle the sites conversion of < to <
Thanks for taking the time to comment.
I do need to come up to speed on the C++11 features, especially for templates. I’m not fortunate enough to be able to use a C++11+ compiler because of the hardware we use.
I will be updating my Alchemy project with some of the modern syntax improvements where they make sense. I will be sure to edit the examples to show the newer and cleaner syntax when I am more familiar with them.
As far as the appearance, I apologize. I am aware of what is happening to the formatting. Late December my site had an “incident". A bad database entry or something. In trying to fix it, I updated the version of this blog suite, and it overwrote some of the customizations that I have added.
I have them backed up. However, I have not made the time to get its appearance as clean as it was.
One other thing I lost that I am currently working on restoring, is integration with the Coliru online compiler.
Originally this article was planned to be able to compile the examples inline. I will update that as well, when I get the interactive compiler working again.
Thanks for scrutinizing the code and keeping me honest. More importantly taking the time to let me know so that this entry will be accurate.
No, I didn’t run the code at first. I have since compiled them and corrected most of the errors.
My intention was to create a demonstration that is more useful that what you find with most descriptions of this technique. Taking it a step further with the find wrapper.
Yes, the has_find definition still has the issue that you describe. I will be correcting soon. Unfortunately my day job has gotten in the way.
Hey, nice article, but be aware that your “<” characters get html-ized in “<” and that’s not a good thing for a post based on templates…
That said, can I suggest you get rid of “static T* this_t();” in your selector template and simplify things a bit taking advantage of std::declval which I presume has been introduced in C++11 exactly for such cases where a type might not be default constructible)?
Thanks for your good posts!
A good explanation of SFINAE, but did you ever tried to run the code you wrote?
Let’s forget about the bunch of syntax errors and all the missing typenames, your code could never work for containers that doesn’t have find, because even if has_find evaluates to false, the compiler has still to fully compile the if clause.
thank you for the compliment.
I really appreciate it.
One of the best article I’ve read on the topic. Excellent. Thanks for sharing.
Thanks for taking the time to add comments and start a discussion.
I don’t think I was ever counting on any specific internal representation from the std:tuple. I was more interested the ability to access both the type info and the data with one data type.
There are two concepts to manage with Alchemy:
- The working object the user manipulates to access the data.
- The actual packed message format defined for the network or serialization protocol.
The Tuple represents item 1. Where the fields are represented internally are not necessarily important to me, only that they use the fixed index, I can access the data, and the type information is correct so I can calculate the total size of the structure defined for item 2.
This is a concept I was aware of, but didn’t pay too much attention to until I reached the later stages of development when I started to add support for arrays and vectors.
I wrote a function that actually calculates OffsetOf for a std::tuple.
This is kinda ugly because it derefenrences a NULL-pointer and shouldn’t be used in production code.. but it shows that (at least on gcc/linux, same for clang btw) the offset of the 0-th element (as obtained by std::get<0>(tuple) ) is not 0. And while it seems like the value is at the beginning of one std::tuple_element (offset 0 within it), I wouldn’t take that for granted in general, either.
OffsetOf() is kinda interesting for an idea I’ve been having.. but it seems to assume that there is no padding within a tuple (the offset is just the sum of sizeof() of the predecessing elements).
Is that actually guaranteed? I didn’t read the standard, but at least cppreference.com, cplusplus.com and MSDN don’t mention any requirements on the memory layout.
http://mitchnull.blogspot.de/2012/06/c11-tuple-implementation-details-part-1.html says that the tuple elements may even be in the wrong order in memory…
(for soome reason newlines in the text don’t seem to work, neither br-html-tags, at least in the preview?)
Edit - I changed the settings to allow basic HTML tags through, use a <p> grouping to get newlines now.