What is a User-Defined Type?


The meaning of “user-defined type” is so obvious that the Standard doesn’t define it. But it uses the term over a dozen times, so it might be good to know what it means.

bjarne2Prof. Stroustrup knows what it means and he is very clear that any type that is not built-in is user-defined. (See the second paragraph of section 9.1 in Programming Principles and Practice Using C++.) He even specifically calls out “standard library types” as an example of user-defined types. In other words, a user-defined type is any compound type.

The Standard does seem to agree in several places. For example in [dcl.type.simple] the standard says:

The other simple-type-specifiers specify either a previously-declared user-defined type or one of the fundamental types. (Emphasis mine.)

In context, it is pretty clear that std::string (for example) is a simple-type-specifier and it clearly isn’t a fundamental type so it must be a user-defined type. (In [basic.fundamental], the standard says that there are two kinds of types: fundament types and compound types. It then lists the fundamentals types–there are no Standard Library types in the list.)

So what’s the problem? The problem is that sometimes the term seems to be used in a way that implies that Standard Library types are not user-defined.

Consider this from [namespace.std]:

A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited. (Emphasis mine.)

Here the standard is saying that it is legal to create a specialization like:

namespace std
    template <>
    void swap<my_type>(my_type&, my_type&) {…}

This is okay because:

  • swap is Standard Library template and
  • my_type is a user-defined type.

The reason that the standard makes the restriction that the template type must be user-defined is because it wouldn’t do to allow users to do something like this:

namespace std
    template <>
    void swap<int>(int&, int&) {…}

Allowing a user to define the implementation of std::swap() could lead to nasty surprises for some users. In so many words, the Standard is saying that you only get to define the implementation of std::swap() for types that you define yourself, not for int, double, etc. But what about std::string? Does the Standard intend for users to legally do this:

namespace std
    template <>
    void swap<string>(string&, string&) {…}

and provide an implementation of std::swap() for std::string of the user’s choosing? This is what the Standard is saying, if we choose to interpret the meaning of user-defined types as any compound type.

There are several similar references in the Standard. References where something is only permitted in instances where at least one type is a user-defined type. Consider

  • common_type in Table 57 of [meta.trans.other],
  • the last requirement in the first paragraph of [unord.hash], and
  • is_error_code_enum and is_error_condition_enum of [syserr].

In these and other references, it really doesn’t make sense to allow users to create specializations for Standard Library types.

My informal, not statistically significant, survey of a couple of friends of mine on the Standards Committee indicated that there are Committee members who don’t use the any-compound-type-is-a-user-defined-type definition, but instead accept (as one of them said) that:

user defined types are, broadly speaking, types that aren’t mentioned in the standard.

I think the Standard should be clear about the definition of this term and not leave it up to use to guess, because, while user-defined types are good for C++, user-defined terms are not.

Let me know what you think.

Unofficial Update on C++Now 2104

I want to point out that what I’m saying here is “unofficial.” Any dates or details about C++Now that are known for certain we would publish on the official C++Now website. I’ve gotten a number of message from people about the 2014 conference and I wanted to let people know what to expect.


The dates are May 12-17. This is official, but it might be a little surprising or confusing. For all of conference history, going back to the misty beginnings of BoostCon, the conferences has started with registration followed by a reception or other socializing on Sunday and the first technical sessions on Monday morning. This year registration and the reception will be on Monday with the first technical sessions starting on Tuesday morning. The conference isn’t shorter, it will end on Saturday instead of Friday. We’ve made this change to accommodate individuals that don’t want to travel on Sunday which is Mothers’ Day in the US.


Also official is that the last day to get the Early Bird discount (saving $20 per night) on hotel rooms at the Aspen Meadows is January 10th. This is coming right up, so make your arrangements right now. Do not wait for registration to open!


Here is what is unofficial:


Although we did have to extend the submission deadline (it seems that we always do) we ended up with a nice number of quality submissions (we always do!), so we’ll have three tracks just like we did the last two years. We haven’t finished reviewing the submissions so it will be awhile before we will have a schedule online or even be able to let submitters know what has been accepted.


We will again have Student/Volunteers. We did this for the first time last year and it was quite successful. Last year we had seven volunteers (grad students, undergrads, and a high school student) and we were able to raise funds for travel and lodging for all of them. We found that seven was more than we needed, so this year we’ll probably have fewer. We will certainly waive registration fees for volunteers, but how much we can help with travel and lodging depends on how successful we are raising funds for that purpose. If you are or know someone who is interested in applying to be a Student/Volunteer, be ready to submit your application. We’ll want to see your résumé and a personal statement about why we should choose you. We’ll probably be accepting these Real Soon Now™.


But what most people seem to be concerned about is registration. This isn’t surprising. Last year, for the first time, we sold out. It was very gratifying to sell out. But it was very painful to have a waiting list full of people that we had to disappoint.

We are pretty close to opening registration for 2014. We expect to sell out again this year. In fact, we expect to sell out even sooner because, unlike last year, people know that we’ve sold out before. Last year we sold out by the middle of March. How soon we’ll sell out this year is anybody’s guess, but it is clear already that people are concerned about ending up on the wait list.

So my advice, if you are interested in attending is:

  1. Make your hotel arrangements now!
  2. If you need approval from your boss or spouse to attend, start working on that now.
  3. Watch for the “registration is open” announcement.
  4. Don’t hesitate when registration opens. (Unless you have made a presentation submission – see Submitters below.)

Where should you look for the “registration is open” announcement? Well you could check the official website everyday, but who is going to remember to do that? If you use a feed reader, there is an RSS feed you can follow. You can also follow the official twitter account. You can also expect the announcement on any of these Boost mailing lists: the user list, the developer list, and/or the interest list. I also expect to see it reported on isocpp.org. (If you were on last year’s wait list, you’ll receive an email from Marshall Clow, the conference registrar, with the announcement.)


If you have made a session submission, do not register now. If you’ve submitted a session, we’ll hold a place for you. When the decision is made about which submissions will be accepted, we’ll contact you with instruction about how you can register. Even if we’ve decided not to accept your submission, you’ll have a chance to register.

Good luck and I hope to see you all in Aspen this May!

Comment on Google+.