Duck Typing in C++ Using Boost

Download source code - 1.7 KB

Introduction

This article grew out of the need to make conversions between similar-looking C++ struct types. For example, consider the following declarations:

typedef struct S1_version1
{
 int scalar1; 
 int scalar2;
};

typedef struct S1_version2
{
 int scalar1; 
 int scalar2;
 int scalar3;
};

This article deals with the need to convert, for example, an instance of the first struct into an instance of the second struct. This is done in the obvious way: by copying data into the members with identical names.

The structs involved are independent of each other in the C++ typing system; they share, for example, no common base type. From a practical standpoint, though, they seem to be closely related, since the second type contains all of the members from the first type. Often, one of the types will be a later version of the other type, and some sort of backwards compatibility requirement will necessitate conversion between the types.

Conversion can, of course, be done by writing one assignment statement for each member in S1_version1. The techniques described here automate this process, so that only a single operation (assignment or method call) is necessary for conversion.

Background

In many languages, conversion of an instance of S1_version1 to an instance of S1_version2 would be available automatically. Consider the following snippet, which relies on the declarations just presented:

S1_version1 first;
first.scalar1=1;
first.scalar2=2;
S1_version2 second=first; //Does not compile

In C++, of course, this code will not compile - at least not as presented thus far. The goal of this article is to make such code compile, as transparently as possible. But for now, attempting to compile such code using, for example, the MinGW compiler results in the following error:

> structdemo.cpp:60: error: conversion from 'S1_version1' 
       to non-scalar type ‘S1_version2' requested

In other languages (specifically, in languages with so-called “duck” or “duct” typing), such automatic conversions are syntactically correct. Members get mapped based on the name as a part of the conversion.

The code presented in the rest of this article achieves something similar in C++. In particular, it offers a system of struct declaration macros. The structs declared using the macros can be converted effortlessly into instances of any other struct with the same members.

These macros use the “Boost” preprocessor. Although knowledge of Boost is not at all necessary to use the system presented here, the requisite header file relies heavily on it.

Boost is one of many “Open Source” libraries built around the C++ language, but enjoys several distinctions relative to other such libraries. First, Boost is “peer-reviewed”, i.e. multiple academics in the field of Computer Science have signed off on its contents. Second, Boost is actually intimately associated with the C++ standards committee, and has a sort of quasi-official status. Parts of Boost are slated for inclusion in forthcoming C++ standards, for example, and several leaders of the Boost working group are also on the C++ standards committee. Another point in favor of Boost is that it is completely written in C++. It does not alter the language. Rather, it augments it with a collection of standardized, well-considered code.

Finally, although it is “Open Source”, Boost is licensed in a fashion that allows for its use in for-profit work. This is a critical distinction for the professional developer, who must respect not just copyright law, but also so-called “copyleft” restrictions, which forbid using certain other Open Source libraries for profit.

Using the Code

Returning to the C++ example presented earlier, consider the following program:

#include "StructDuckTyping.h"   //Part of this article’s code
#include <cstdio>

//Declare a type named S1_version1, with two “int” members
DECLARE_DUCKTYPED_STRUCT( S1_version1,   
  ((int)(scalar1))
  ((int)(scalar2))
)

typedef struct S1_version2
{
 int scalar1; 
 int scalar2;
 int scalar3;
};

int main()
{

 S1_version1 first;
 first.scalar1=10;
 first.scalar2=20;
 S1_version2 second=first;

 printf("%d\n%d",second.scalar1, second.scalar2);

 return 0;
}

The operation of this code is similar to the JavaScript example. The conversion from S1_version1 to S1_version2 takes place automatically, and the output of the program is thus “10” followed by “20”.

The “StructDuckTyping.h” header file includes all of the code necessary to make this work. In particular, this header file contains the definition of the DECLARE_DUCKTYPED_STRUCT macro. The format used inside each invocation of DECLARE_DUCKTYPED_STRUCT is a bit unfamiliar; it looks more like LISP than C++. In summary, each member declaration is wrapped in a pair of parentheses. Within these, the type of the member is similarly wrapped, as is the member name. This member list is preceded by the name of the struct being declared, and separated from it by a comma. As suggested by the single comma, DECLARE_DUCKTYPED_STRUCT, technically speaking, takes only two parameters, although the second of these is a list. None of this has proven difficult to deal with in practice, in the author’s experience.

Clearly, DECLARE_DUCKTYPED_STRUCT is a powerful macro. However, it is worth noting that the file in which it is defined is not so large (less than 150 lines of code, even with some fairly extensive comments). Moreover, the way the macro expands during preprocessing is quite mechanical. The macro expansion can be obtained by using the –E option of MinGW, which runs the preprocessor without compiling. The expansion of the macro as used in the example above is shown below:

typedef struct 
{ 
 int scalar1 ; 
 int scalar2 ; 
 
 template <class T> operator T() 
 {
  T out; 
  out.scalar1 =scalar1 ; 
  out.scalar2 =scalar2 ; 
  return out; 
 }

 template <class T> void GetMembers(T& out) 
 {
  out.scalar1 =scalar1 ; 
  out.scalar2 =scalar2 ; 
 }

} S1_version1;

This looks essentially like the declaration used for the struct in the first example, except that a type converter method has been added, along with a similar-looking GetMembers() method. In summary, for any type T, the type converter method will instantiate an instance of T and then attempt to copy all struct members into this new instance on a name-by-name basis. Then, the new instance is returned by value to the caller.

Note that there are situations in C++ where member-wise copy of the sort shown above is done automatically, without any need for special macros. In particular, classes and structs without an explicit copy constructor (i.e., a constructor taking another instance of the same class) will have an implicit copy constructor that uses member-wise copy. However, nothing in the C++ language allows for automatic member-wise copy between unrelated data types.

Also, some considerations related to performance and storage utilization ought to be mentioned. In particular, the creation of an instance of type T on the stack, followed by its return to the caller on a value basis, is somewhat inefficient. It would be more efficient for the caller to create the instance a single time, and then for the macro logic to simply fill the members of that instance. Note that the user of this library can accomplish this using the GetMembers() method. This method accepts an existing instance of type T and populates the members of this instance.

It must be mentioned, too, that DECLARE_DUCKTYPED_STRUCT does not support conversions where type T lacks one or more members present in the source type. Fortunately, in cases where a data model fails to respect this constraint, a compile-time error (as opposed to a run-time failure) is obtained. In MinGW at least, the error message is remarkably intuitive:

C:\beau>c:\mingw\bin\c++ dt_basic.cpp

 > dt_basic.cpp:31: error: 'struct S1_version2' has no member named 'scalar2'
 > dt_basic.cpp: In member function `S1_version1::operator T() [with T = S1_version2]':
 > dt_basic.cpp:29: instantiated from here
 > dt_basic.cpp:4: error: 'struct S1_version2' has no member named 'scalar2'

When faced with such an issue, one option is to run the preprocessor without compiling (e.g., to use “MinGW –E”) to obtain the macro expansion. Then, assignments into the “missing” member can be commented out, and the resulting code placed into the original .CPP file in lieu of the macro invocation.

One final limitation of DECLARE_DUCKTYPED_STRUCT is that methods (other than the conversion methods generated by the macro) are not supported. Although it is somewhat atypical for structs (as opposed to classes) to contain methods, it is by no means forbidden by the C++ standard. However, the syntax of DECLARE_DUCKTYPED_STRUCT does not contain any support for methods, nor does it support the use of access modifiers (e.g., public and private). Again, the use of these modifiers is more typical of class declarations than of struct declarations, and the use of DECLARE_DUCKTYPED_STRUCT completely rules out their use.

At this point, the entire DECLARE_DUCKTYPED_STRUCT macro has been presented and explained. However, some nuances of its operation with more complex types still need to be explored. First, it bears mentioning that the macro, as already presented, supports the nesting of duck-typed struct instances within other duck-typed structs. The type converter method both uses and overrides the assignment operator. So, conversions involving nested structs naturally result in a call from one struct’s type converter into the other struct’s type converter, down to any level of nesting. Even if the inner struct(s) actual types have changed, proper function will be provided, so long as members with the correct names are present. Consider the following example code:

#include "StructDuckTyping.h"
#include <cstdio>

DECLARE_DUCKTYPED_STRUCT(Inner_version1,
 ((int)(inner_scalar1))
)

DECLARE_DUCKTYPED_STRUCT(Inner_version2,
 ((int)(inner_scalar1))
 ((int)(inner_scalar2))
)

DECLARE_DUCKTYPED_STRUCT(Outer_version1,
  ((int)(n))
  ((Inner_version1)(inside))
) 

DECLARE_DUCKTYPED_STRUCT(Outer_version2,
  ((int)(n))
  ((Inner_version2)(inside))
) 

int main()
{
 Outer_version1 first;
 first.inside.inner_scalar1=111;

 Outer_version2 second=first;

 //Prints "111"
 printf("\n%d", second.inside.inner_scalar1);

 return 0;

}

This example really points out the power of the macro system used here. Four structured types are in play, none of which have any real relation to each other in the basic C++ typing system. The use of DECLARE_DUCKTYPED_STRUCT allows for effortless conversion among these four types, to the extent that member names match up correctly.

Another aspect of DECLARE_DUCKTYPED_STRUCT that remains unmentioned is its support for array members. This support is complete, and transparent. Consider the following declaration:

DECLARE_DUCKTYPED_STRUCT(S1_version1,
  ((int)(ara)(10)(20)(30)(40))
)

This expands as follows:

typedef struct 
{ 
 int ara [10] [20] [30] [40] ; 
 template <class T> operator T() 
 {
  T out; 
  for(int counter0 =0; counter0 <10; ++counter0 ) 
   for(int counter1 =0; counter1 <20; ++counter1 ) 
    for(int counter2 =0; counter2 <30; ++counter2 ) 
     for(int counter3 =0; counter3 <40; ++counter3 ) 
      out.ara [counter0] [counter1] [counter2][counter3] =
       ara [counter0] [counter1] [counter2] [counter3] ; 

  return out; 
 }  
} S1_version1;

(GetMembers() is omitted for brevity, but is again essentially identical to the type converter, minus the instantiation of out.)

This expansion will work in seamless fashion so long as the dimensions of ara only grow over time. Also, ara need not be an array of a simple type. It can be an array of structs, even structs declared using DECLARE_DUCKTYPED_STRUCT. Because of the general way in which this macro overloads assignment, the assignment operation inside the mechanically generated for loops will end up invoking our templated type converter method, and proper name-by-name mapping will occur for each array element.

In using arrays we do, unfortunately, encounter a run-time risk; if the dimensions shrink from one struct to the next, a buffer overrun can occur. However, this is but one instance of a very typical issue presented by the C++ language.

Finally, DECLARE_DUCKTYPED_STRUCT also supports the inheritance of struct members. It is atypical, at least in the experience of the author, for C++ structs to inherit from each other. Nevertheless, DECLARE_DUCKTYPED_STRUCT has been extended to support this feature – and even to support multiple inheritance. This proved to be practical without adding too much to the necessary header file. In particular, the existing GetMembers() method proved helpful in implementing support for inheritance.

Declaration of derived struct types uses a second macro, DECLARE_DUCKTYPED_STRUCT_BASES. This is similar to DECLARE_DUCKTYPED_STRUCT, except that it takes as its final parameter a list of base types. An example declaration is given below:

DECLARE_DUCKTYPED_STRUCT(Base1_version1,
  ((int)(base1_member))
) 

DECLARE_DUCKTYPED_STRUCT(Base2_version1,
  ((double)(base2_member))
) 

DECLARE_DUCKTYPED_STRUCT_BASES(Derived_version1,
  ((int)(derived_member)),
  (Base1_version1)(Base2_version1)
)

The expansion of Derived_version1 is as shown below. Again, GetMembers() is omitted for the sake of brevity, since it follows logically from the type converter:

typedef struct dummybaseversionatorDerived_version1{}; 
typedef struct : dummybaseversionatorDerived_version1, 
                 Base1_version1 ,Base2_version1 
{ 
 int derived_member ; 
 template <class T> operator T() 
 {  
  T out; 
  ((Base1_version1*)this)->GetMembers(out); 
  ((Base2_version1*)this)->GetMembers(out); 
  out.derived_member =derived_member ; 
  return out; 
 } 
} Derived_version1;

The most unfamiliar aspect of this macro expansion is probably the use of the additional type named dummybaseversionatorDerived_version1. The dummy base type ensures that at least two struct types will be present in the listing of base types near the top of the expanded declaration. This allows the logic that does the work of constructing the listing to simply append a comma to this listing before each of the actual base types. This is a somewhat atypical approach. If emitting a similar list (for whatever reason) at run-time, it would be reasonable to treat the first base class as a special case that does not need a comma. However, preprocessor logic is tricky to code and maintain, and the use of the “dummy” base type is a welcome simplification.

As hinted, GetMembers() is used to effect name-by-name assignment of each base type’s members into the variable out. Each base type’s GetMembers() method is invoked upon the derived type instance (i.e., on this), in order to extract the members received from that base type. To allow access to each base type's version of GetMembers(), the converter methods generated by the declaration macros are not marked as virtual. This means that the static (i.e., compile-time) type of the instance used to invoke GetMembers() determines which version of the method gets executed. As a result, typecasting this to a base type pointer allows the base type’s GetMembers() method to execute.

Points of Interest

At this point, some details about the requisite header file (StructDuckTyping.h) are in order. While complete coverage of the Boost knowledge that underlies this header’s construction cannot be provided here, it is not difficult to describe the general workings of the file. In fact, the macro expansion examples already given provide a very complete high-level summary of the contents of StructDuckTyping.h.

The core of the header file is DECLARE_DUCKTYPED_STRUCT, whose definition is as follows:

#define DECLARE_DUCKTYPED_STRUCT(name,seq) \
typedef struct  \
{ \
    \
   /* Declare members */ \
   BOOST_PP_SEQ_FOR_EACH(DEF_MEMBER,~,seq) \
   \
   /* Provide a copy method */ \
   template <class T> operator T()\
   { \
     T out;\
     \
     /* Copy members to new stack struct */ \
     BOOST_PP_SEQ_FOR_EACH(COPY_MEMBER,~,seq) \
     return out;\
   }\
   template <class T> void GetMembers(T& out) \
   { \
     /* Copy members to existing struct */ \
     BOOST_PP_SEQ_FOR_EACH(COPY_MEMBER,~,seq) \
   }\
} name;

Like any C++ parameterized macro, this entire entity represents a blueprint for the text replacement that constitutes macro expansion. As is typical of such macros, the “line continuation” backslash is used to mark out the extent of the macro. The constituent parts of the expansion examples (i.e., the two converter methods, and the members themselves) are clearly visible in the macro definition, albeit in strangely augmented form.

Clearly, BOOST_PP_SEQ_FOR_EACH and the seq macro parameter play a key role here. This seq parameter is a Boost “sequence”. The sequence is a Boost concept, which consists of a parenthesized list of parameters designed to be iterated over – during preprocessing - by BOOST_PP_SEQ_FOR_EACH, and some other similar Boost constructs. A simple sequence might take the form (1)(2)(3)(4).

BOOST_PP_SEQ_FOR_EACH takes three parameters, of which only the first and third are used here. The first parameter is another preprocessor macro into which each sequence element gets passed as a parameter. This macro is expanded at the point in the code where BOOST_PP_SEQ_FOR_EACH appears. The third parameter is the sequence over which iteration will occur.

Sequences can be nested; in fact, this is critical to the library presented here. Consider, for instance, the following member list taken from a previous example:

((int)(inner_scalar1))
((int)(inner_scalar2))

This fragment is itself a sequence, i.e., it is a list of parenthesized elements. Each of these elements is also a sequence. The outer sequence gets passed to DECLARE_DUCKTYPED_STUCT as a member list. Then, each element of the outer sequence is iterated over by the three invocations of BOOST_PP_SEQ_FOR_EACH visible in the macro definition. Respectively, these will perform the mechanical generation of the member list, of the assignments in the type converter, and of the assignments in GetMembers().

The first invocation of DECLARE_DUCKTYPED_STRUCT builds the member list. This is shown below:

/* Declare members */ \
BOOST_PP_SEQ_FOR_EACH(DEF_MEMBER,~,seq) \

This means that the DEF_MEMBER macro will get expanded into the preprocessed source for each element of seq. For example, in its first invocation, DEF_MEMBER will receive ((int)(inner_scalar1)) as its parameter, and will use Boost for the sequence-processing facilities to emit a syntactically correct declaration (int inner_scalar1;) into the preprocessed code. Similarly, COPY_MEMBER uses BOOST_PP_SEQ_FOR_EACH to generate the for loops necessary to copy array members.

In closing, I want to contrast the techniques described here with a potential low-level approach I considered. Consider, for example, the program shown below:

#include <cstdio>
#include <memory.h>

typedef struct S1_version1
{
 int scalar1; 
 int scalar2;
};

typedef struct S1_version2
{
 int scalar1; 
 int scalar2;
 int scalar3;
};

int main()
{

 S1_version1 first;
 first.scalar1=1;
 first.scalar2=2;

 S1_version2 second;

 //Just copy the bytes and hope for the best 
 memcpy((void*)&second, (void*)&first, sizeof(S1_version1));

 //Prints “1” then “2”… seems to work well
 printf("\n%d\n%d",second.scalar1, second.scalar2);

 return 0;
}

The call to memcpy() does the job, in this case, of moving data from one struct to the other. Superficially, one might wonder if this low-level approach might be extended to deal with all the other scenarios already dealt with in the discussion above (arrays, nested structs, and so on). It seems surprisingly easy to address 90% or so of the real-world cases addressed by StructDuckTyping.h by using memcpy() or something like it; the logical question is thus whether it is possible to reach 100% using such techniques.

To do this would be extremely difficult, or at least significantly more difficult than the approach outlined in this article. Fundamentally, such an effort would have to rely on logic to determine numerical offsets for each struct member in memory. This is no problem in the example given above, since the second struct is identical to the first, except for the new member at its end. More substantial differences in struct declarations – such as changes in the dimension of array members, or changes in the declarations of base types or member struct types – would make the task of determining member offset quite difficult. More subtle issues impinge on such an effort as well, such as padding and alignment rules. These rules are compiler-specific and even project-specific.

The power of name-based assignment abstracts over a whole range of such issues, and hints at what I consider to be an oft-overlooked strength of C++: its rich set of compile-time facilities, such as the preprocessor and templates. Very often, C++ programmers are instructed to minimize the use of the preprocessor. I sympathize with this desire. As this article hints, though, the preprocessor is quite powerful in the right hands. In theoretical terms, macro expansion offers the full power of Lambda Calculus’ “normal-order reduction”, which is the most powerful method of function invocation. The practical value of the preprocessor is, I hope, hinted at by my library. The preprocessor can be difficult to deal with, but it is, at times, a very necessary evil.

One big advantage of using the preprocessor in StructDuckTyping.h is that this aspect of the design reduces the run-time burden associated with duck typing. True “dynamic typing” – of which most duck typing is an example - occurs at run-time. In JavaScript, for example, types are checked for member-level compatibility as necessary during execution. This results in a performance penalty, and also defers potential errors from compile-time to run-time, at which point the consequences of an error are often much more dire.

To summarize, I think the approach described here is a powerful, optimal, and general one. These aspects of my design serve to justify the (somewhat tricky) preprocessor macro development that was required.

History

This is the second major version of this article. Some minor changes to terminology were made.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

_beauw_

United States

Member

I was educated at Southern Miss.

Article Top

Poor

Excellent

Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

You must Sign In to use this message board. (secure sign-in)

Search this forum
	Profile popups Noise Layout Per page

Boost License

Greg Prosch

11:22 2 Mar '10

Your comments regarding the Boost license imply that Boost is not free to use in "for profit" software but this is not the case. You can read the Boost license here: [Boost License]
Sign In·View Thread·Permalink

Re: Boost License

_beauw_

12:54 2 Mar '10

You are correct, and this is definitely information I want to communicate. While I do mention that "Boost is licensed in a fashion that allows for its use in for-profit work," I did not make it 100% clear that this can be done free-of-charge. If I make another update to this article, I will try to be more explicit.
Sign In·View Thread·Permalink

My vote of 2

marl

22:01 1 Mar '10

I think that this is an article about sofisticated way to do ugly thing.
Sign In·View Thread·Permalink	2.00/5 (1 vote)

Re: My vote of 2

S.H.Bouwhuis

4:23 2 Mar '10

I have to agree a little bit here. I think the article has been skillfully written, but I cannot recommend people using this in any serious (commercial) project. The chance of side-effects and bugs is simply to great.
Sign In·View Thread·Permalink	5.00/5 (2 votes)

My vote of 5

^CPallini

22:21 8 Mar '10

marl wrote:
I think that this is an article about sofisticated way to do ugly thing.

I think this is a good article about sofisticated way to do ugly thing.
We have to master the language, not nursed by.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Some context for the critics of this article [modified] [modified]

_beauw_

14:22 1 Mar '10

I hear you. What's presented here is not OOP, is a bit cryptic, may not be maintainable, etc. I actually used the words "cryptic" and "tricky" in my article.

But as I said in response to one critical comment, I feel that ratings of "1" and "2" ought to be reserved for the abundance of articles with bad (or no) English, or un-buildable source code, or (especially) a complete lack of innovation.

The material presented here is novel. Sure, COBOL supposedly had something like this; but duck typing is more commonly associated with newer languages like Ruby and JavaScript, and there aren't any other articles that discuss duck typing in C++ - or anything like it - at this site. The article is well-documented. And if I may say so, it's interesting. At least, it has provoked strong reactions, and - for better or worse - offers a break from the constant re-hashing of orthodox techniques that characterize many better-rated articles.

I would ask you, "What sort of articles do you want to see on this site?" There are plenty of articles here rehashing the OOP techniques that you probably prefer. Do a site search for "model view," "object oriented," or "polymorphism" and you will be inundated with literally hundreds of articles that exist for no other purpose than to allow yet another programmer to pad his resume ("See, I can do MVP too!")

I personally get very little out of those articles. I feel I stuck my neck out in presenting something different. There really is not much coverage here of, for example, the Boost preprocessor, or metaprogramming in any form. It's all OOP. OOP has its place but, believe me, it doesn't offer much fertile ground for a CodeProject article at this point in time.

In rating my article a "1" or "2," the message I get is "Don't post anything novel. Post the same old techniques, or risk damaging criticism." After all, I have to stay employed. I have a family to feed. If I find myself applying for C++ jobs, I may even find myself in the position of having to present these articles as a sort of portfolio. At least, that was once a possibility... there is a human being on the other end of your criticism, and this criticism also has implications for the breadth of discussion at this site.

Moreover, there is a difference between the code I deliver professionally and what I put in a CodeProject article. I did not ask anyone to use this technique, or maintain code like this. I even think it's a bit of a misconception that I "encouraged" anything (as one critic posted). Yes, I presented my technique along with its strong points, but I purposefully did not compare it to any other approach.

Beyond that, the technique described here helped me out of a jam. It was originally developed to provide backwards compatibility for an application with an immense, preexisting base of evolving struct declarations with no object hierarchy. I didn't have the authority or time to rebuild these declarations into some kind of inheritance-based OO design, which is something that seems to be a prerequisite for all of the proposed alternatives to my (horrible) approach, e.g. http://www.codeproject.com/tips/61723/Collect-data-from-an-object-of-some-other-class.aspx[^]

I rated Alain's "tip" poorly, because (as I explain in my message at that link) what he presented is not an alternative to what I've done here. It's a type conversion technique for types actually designed with common base classes. But at least Alain's comment tried to present an alternative. The more recent comments have basically just said things like "Ugh.. COBOL did that, too; I vote 1" or "That's just plain C; don't write C." (Keep in mind that there is not, that I'm aware of, a separate "C" area on this site... this is the "C/C++" section).

I could go on and on. I could talk about the composition of the Boost working group, and the post-OOP vision they (along with proponents of STL) share for the C++ language. Believe it or not, there are other paradigms out there, and C++ is a multi-paradigm language. I could further talk about the spartan nature of the object code generated via my approach, versus the object code generated by OOP techniques.

I won't bother any further with all of that. I think the larger point is to ask, once more, whether there is to be any room at all for outside-of-the-box thinking here, and whether this site is to be a mutual admiration society for one particular programming paradigm, or if there is not legitimate credit that ought to be given for encouraging different perspectives.

modified on Monday, March 1, 2010 9:21 PM

modified 4 May '12.

Re: Some context for the critics of this article

S.H.Bouwhuis

4:27 2 Mar '10

I will not use this article's content, nor will I allow any of my employees to use such a convoluted thing. Still, I gave your article a 5 for originality and writing skill. It surely is thought provoking. We need more articles like this on CodeProject.
Sign In·View Thread·Permalink	5.00/5 (1 vote)

Re: Some context for the critics of this article

_beauw_

12:46 2 Mar '10

Thank you, I cannot disagree with anything you wrote.
Sign In·View Thread·Permalink

Back to the Future?

David Scambler

12:42 1 Mar '10

In the 1960's COBOL had the syntax MOVE CORRESPONDING to move items with common names from one structure to another. This form of move was deprecated in many corporate style manuals due to the unmaintainable atrocities that programmers could commit using the syntax.
Sign In·View Thread·Permalink	5.00/5 (1 vote)

My vote of 1

Crawfis

10:08 1 Mar '10

Encouraging the creation of garbage should be avoided. Making it "more transparent" to shoot oneself in the foot is not a good contribution here. Modern languages are nice for some of these features, but if you must use C do not be lazy about your coding style.
Sign In·View Thread·Permalink	1.00/5 (1 vote)

My vote of 2

Alain Rist

5:32 25 Feb '10

See my previous post
Sign In·View Thread·Permalink	1.00/5 (2 votes)

My vote of 2 explained

Alain Rist

5:31 25 Feb '10

Hi,
I am really sorry to downvote your article as it is clear that you worked it hard. But I think you are on a very bad track here. Your article's code is NOT C++ but some kind of pidgin.

In C++ your last code block would be:

#include <iostream>

struct S1_version1 
{
    int scalar1,
        scalar2;
};
 
struct S1_version2 : S1_version1
{
    int scalar3;
    S1_version2(const S1_version1& v1) : S1_version1(v1)
    {}
};
 
int main(int argc, char* argv[])
{
 
    S1_version1 first = {1, 2};
    S1_version2 second = first;
    std::cout << second.scalar1 << '\t' << second.scalar2 << std::endl;
 
    return 0;
}

This is poor code as second.scalar3 is garbage but it is poor C++.

Note that S1_version2(const S1_version1& v1) : S1_version1(v1){} solves the problem you raise in your intro with 1 (2 with formatting) line of code.

Read all Bjarne Stroustrup's C++ Style and Technique FAQ and happily program in C++.

cheers,
AR

Re: My vote of 2 explained [modified]

_beauw_

6:12 25 Feb '10

That seems a rather negative assessment and I think you ought to consider revising your vote. People use this site to build portfolios, and I reserve my 1s and 2s for things that are incorrect, don't compile, or don't have good English.

My approach is not OOP. So what? There are other programming paradigms out there. In particular, metaprogramming and generic programming are the two that I would highlight as influences here.

There are reasons I tend to avoid OOP when working in C++. C++ OOP uses static method binding by default, which introduces the problem of non-virtual base class destructors failing to run. (I notice you did nothing in your code example to prevent this in cases where your classes might be extended). C++ OOP also allows multiple inheritance, and does not have an explict interface keyword, aspects of the language that make it awkward compared to, say, C# or Java.

And when you say "Note that S1_version2(const S1_version1& v1) : S1_version1(v1){} solves the problem you raise in your intro with 1 (2 with formatting) line of code" that's not really true. You completely took apart my declarations - introducing an inheritance tree. There's no "one line" solution anywhere in your post.

My approach was explicitly designed to work with types not related to each other in the C++ type system. That's what makes it interesting. Might it be more appropriate to use an inheritance tree in many real-world applications? Absolutely, but that does not make my contribution a "2."

And when you say "my article is not C++," what do you mean? Surely everything I've presented here is syntactically valid on any up-to-date C++ compiler.

Are you upset that I don't use iostream.h? That's really a matter of preference. Remember, C++ is essentially a superset of C. Besides that, I don't like the way C++ overloads the bit-shift operators to do something completely different, and then injects that little "setiosflags" monstrosity into the mix.

This C++ I/O looks cute in an introductory CS class but beyond that it seems to me to add very little to the language. It's bastardized, and I reserve the right to use "stdio.h." Note that I at least paid homage to modern C++ sensibilities by using "cstdio," which is more than most people with a background in C would do.

Finally, I don't think you've considered the ramifications of certain things I support, e.g. array members with changing dimensions. For example, I can say

DECLARE_DUCKTYPED_STRUCT(S1_version1,
((int)(ara)(10)(20)(30)(40))
)

DECLARE_DUCKTYPED_STRUCT(S1_version2,
((int)(ara)(100)(200)(300)(400))
)

Then I can fill S1_version1.ara, and move its contents in a single assignment to an instance of S1_version2.

Sure, you could write the "for" loops to do this yourself. Part of my work here is showing how to automate this process using Boost. I really don't see an easy way to integrate this into your approach.

modified on Thursday, February 25, 2010 12:32 PM

Re: My vote of 2 explained

Alain Rist

7:24 25 Feb '10

Well, this post was intended to help you progress, your answer shows that you can't progress as you are already at top cheers, AR
Sign In·View Thread·Permalink	1.29/5 (9 votes)

Re: My vote of 2 explained

_beauw_

11:15 25 Feb '10

I'm not sure what you mean... is this a sarcastic way to say that I lack the ability to learn anything more about programming? That's simply not true. I am very open to alternative approaches. I was very studious in my last response to say that I was not advising any particular architecture; I simply offered one interesting technique I'd found.

On the other hand, if you were sincerely trying to praise my response, I would one again request - humbly - that you upgrade your vote of 2. You have fairly high status on this site and your vote is, as a result, articifically dragging down my article's rating. As I post this, I have 2 votes of "5," 4 votes of "4," and then your vote of "2," with an overall result of something like 3.7. Throwing out your vote - which is an outlier compared to the others - would give a rating of 4.33.

I'm not obsessed with these matters; traditionally, I've received votes in the 3-5 range and taken feedback in stride. I've even updated this article in response to feedback from others. But as I said, your vote is really an outlier and it besmirches my honest effort to share some novel and interesting techniques.

At a very minimum, I would appreciate a more to-the-point response to what I wrote in my last post.

Re: My vote of 2 explained

Leslie Sanford

7:32 28 Feb '10

Alain Rist wrote:
Well, this post was intended to help you progress, your answer shows that you can't progress as you are already at top

_beauw_ showed that he's open to your criticisims by trying to address them. He also asked for clarification where he was uncertain what you meant. Your sarcastic response shows an uwillingness to have a dialog with him regarding the issues you raised. This makes you look like the one who's unwilling to progress, not him.

oops

Stephen Swensen

15:06 24 Feb '10

I don't believe your Javascript example actually demonstrates the kind of type coercion you're claiming it does. The expression w=v simply reassigns the variable w to refer to the same object as v. A good example might come from Groovy, which allows you to construct any object from a map.

It's been a while since I've programmed in c++ so I only scanned the real meat of the article, but it looks like some pretty cool stuff, and I always love experimenting with programming languages this way. In fact, it's a really neat idea and I think I'll explore for c# (which will be much easier since it has a fully reflective runtime).

ss

Re: oops

_beauw_

15:11 24 Feb '10

That's an interesting possibility you raise about the JavaScript... I am going to try to write some kind of test to verify what you're suggesting, and if this is the case then I will revise the article to reflect this.

EDIT: I ran a test and I think you're right. It's a bit tangential to the main point of the article (i.e. the C++ portions aren't affected). But I will correct this in the net update.

Re: oops

Stephen Swensen

15:16 24 Feb '10

Cool. I came up with a test but didn't post it because I didn't feel it quite "proved" my claim. But, after the assignment, w==v is true, however (new PointType1(0,0) == new PointType2()) is false. I would expect those expressions to both have the same result if w=v is actually performing type coercion rather than reassignment.
Sign In·View Thread·Permalink

Re: oops

_beauw_

15:20 24 Feb '10

This is what I made for a test: function PointType1(x, y) { this.x = x; this.y = y; } function PointType2() { this.x = 0; this.y = 0; } var v=new PointType1(10,20); var w=new PointType2(); w=v; v.x="uh oh"; //THIS IS NEW alert(w.x); //THIS DISPLAYS THE MESSAGE "uh oh" alert(w.y); The fact that the first "alert" displays "uh oh" hints that what you wrote is correct.
Sign In·View Thread·Permalink

Re: oops

Stephen Swensen

15:23 24 Feb '10

Excellent. I don't know why I had the presence of mind to spot the mistake but not find such a clear demonstration!
Sign In·View Thread·Permalink

Re: oops

_beauw_

5:35 25 Feb '10

I just submitted an update that removes the JavaScript example. It wasn't really crucial to the article anyway.
Sign In·View Thread·Permalink

Another way to do it

Gordon Brandly

9:58 24 Feb '10

I'm glad to hear you've changed the name to "duck". I've never ever heard it called "duct typing".

This is a subject that interests me very much since I'm often dealing with structs that differ in only one or two members. Your solution is interesting, but I think I prefer the solutions offered in this Stack Overflow question[^].

I can see that those solutions might not cover every case, though, so I'm definitely bookmarking your article for future use. Thumbs Up | :thumbsup:

It's Duck Typing

William E. Kempf

6:28 24 Feb '10

As in, "if it walks like a duck and talks like a duck". http://en.wikipedia.org/wiki/Duck_typing[^] William E. Kempf
Sign In·View Thread·Permalink	5.00/5 (3 votes)

Re: It's Duck Typing

_beauw_

7:36 24 Feb '10

Hmm... I always associated it with "duct tape," which doesn't have anything to do with ducks. I do mention the term "duck typing" in the article body. Maybe I will change this in the next update... "duck typing" does seem to be more prevalent.
Sign In·View Thread·Permalink