C++, compile-time detection of template function implementation

Polter · June 16th, 2012, 12:33 am

Right, just to make sure I understand (and to bounce some ideas off you).1. You'd like a behavior (and output) as in "spec-manual.cpp".However, you would prefer to have has_print_type_implementation<T> deduced automatically, as opposed to user-defined manually.2. For some reason (why?) you do not want compile-time error message as in "spec-broken.cpp".You prefer a run-time error message "can't print this".3. An alternative idea -- why not move the run-time error message one level up the call site, as in "spec-movedup.cpp"?4. Or, for that matter, take the "spec-movedup.cpp" to the next logical step (moving messaging up even more / unifying all the printing into "print") and just refactor it as in "spec-refactored.cpp"?Does any of this make sense?spec-manual.cpp http://ideone.com/WfAPospec-broken.cpph ... ovedup.cpp http://ideone.com/CaKMgspec-refactored. ... .com/F6U35

Cuchulainn · June 16th, 2012, 6:14 am

Playing advocate of the devil..I understand why this feature might be needed but imo it is first difficult to realise and second there are other (as possibly better?) workarounds I reckon. This 'complile-time reflection' is going to be difficult as C++ was not built for this. In a sense compile time reflection is a contradiction in terms.This however is well-known problem and has been solved. e.g. COM with its QueryInterface, .NET dynamic objects etc. Even better, .NET support Reflection that gives all the methods in a type.One possibility is template template parameters but it is very specialised, or even CRTP pattern as workarounds, but ...I think it is very ambitious and probably not achievable in the current version of C++. The resulting code in all likelihood will not be scalable. It would be amazing if you did get it working.

Cuchulainn · June 16th, 2012, 6:58 am

QuoteOriginally posted by: outrunCuch, adjust your assumption, look at the working example facts.Which assumption? I believe working code is possible. But is it scalable?

Cuchulainn · June 16th, 2012, 7:08 am

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunCuch, adjust your assumption, look at the working example facts.Which assumption?Not achievable incurrent versions of C++, scalability, design issues. You should first learn the facts before you are allowed to judge it, if not then your judgement is emotional instead of optimal.I thought my post was reasonably objective. Anyhoo, the message got lost it seems.Let me try again. What you want to do imo is 1) not directly supported in C++ , 2) can be done on other ways in C++. The answer is either yes or no. There are 4 answers.yes/yesno/noyes/nono/yesHere is a question: consider a developer who uses static and dynamic polymorphism for this feature. What are the disadvantages? In other words, what is the compelling reason for not using these techniques?

Cuchulainn · June 16th, 2012, 7:18 am

Let's say I have new functions such as display, calculate, price etc. What steps do I need to take? e.g. do I need to extend meta, for example?

Cuchulainn · June 16th, 2012, 8:00 am

QuoteOriginally posted by: outrunI'll talk more about all the pros and cons when the design is ready and testedOK. If it is easy to use and transparent it would save much time for developers. A test case with 3 different solutions (2 bad, 1 good) would be ideal.

CluelessCpp · June 16th, 2012, 8:07 am

Do you insist on using explicit specializations for print_type?if not, http://ideone.com/xMubC could be another approach.

Cuchulainn · June 16th, 2012, 2:40 pm

Boost interface library (status?)This is the kind of approach that developers use in other languages. It subsumes much.I wonder why it is not part of Boost? Too difficult, ambitious?

Cuchulainn · June 25th, 2012, 5:56 am

It could also be an indicator that BIL is too difficult to achieve in the short term. It's a non-trivial challenge. The Boost Function Types Library looks interesting in this regard but IMO difficult to fathom the library because of sparse documentation. What is interesting is the ability to define interfaces and the code in the zip attempts to experiment with. I am not sure what the advantages are of this whole approach.Here is a list of useful and well-defined features/requirements..NET Reflection