C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  'Pure' value types? Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Roland Pibinger Guest Posted: Mon Oct 10, 2005 10:20 am    Post subject: 'Pure' value types? Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? TIA Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top chris jefferson Guest Posted: Mon Oct 10, 2005 1:40 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; Remember ++ and -- Quote: 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? I've always called them "builtin-like" types, but I'm sure there is a beter name. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Mon Oct 10, 2005 1:41 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I just call them value types. Quote: I mean value types that meet the following criteria: Quote: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; That's a difficult requirement. In practice, most of my value types meet it, but only because I replace the new_handler to abort, rather than throw, if allocation fails:-). Quote: - assignment is the only way to change (mutate) the object; I presume you also allow the <op>= operators (when appropriate). Quote: 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? Good question. You'd think that there would be, but I consistently hear things like std::string refered to as a value type. How about "correctly designed value types"? :-) -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Mon Oct 10, 2005 8:15 pm    Post subject: Re: 'Pure' value types? On 10 Oct 2005 09:40:34 -0400, chris jefferson <caj (AT) cs (DOT) york.ac.uk> wrote: Quote: Remember ++ and -- Not necessarily, think of string types! Best wishes, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Wed Oct 12, 2005 12:56 am    Post subject: Re: 'Pure' value types? kanze wrote: Quote: Roland Pibinger wrote: [...] 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? Good question. You'd think that there would be, but I consistently hear things like std::string refered to as a value type. How about "correctly designed value types"? I guess you could say that there are "strong" value types and "string" value types ;-) Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Daniel Krügler Guest Posted: Wed Oct 12, 2005 3:07 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: On 10 Oct 2005 09:40:34 -0400, chris jefferson wrote: Remember ++ and -- Not necessarily, think of string types! But which ones? std::basic_string can't provide the no-throw guarantees you mentioned, so only static strings would be proper candidates or something like boost::array. Since you emphasize that increment/decrement operations need not to be available I assume you don't restrict on scalar-like data types, right? Considering your exception guarantees one might chose a name like "statically-sized value types". Greetings from Bremen, Daniel Krügler [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Herlihy Guest Posted: Wed Oct 12, 2005 3:09 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? TIA Roland Pibinger I have seen the term "strong typedef" used to describe a user-defined type that is functionally equivalent to another, existing type. The term "strong" serves to distinguish the type from an ordinary typedef which does not define a new type but simply aliases an existing one. Unfortunately, being an alias for another type, typedefs do not provide the degree of type safety that a diferentiated type would provide. In fact there is a proposal to add support for strong typedefs to C++. I think that the language would benefit from having such a feature. In the meantime for anyone interested in the idea, I would suggest looking at Boost's implementation of the strong typedef (in strong_typedef.hpp) for one way to create a strong typedef using existing C++ language facilities. Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Wed Oct 12, 2005 3:15 pm    Post subject: Re: 'Pure' value types? On 10 Oct 2005 09:41:04 -0400, "kanze" <kanze (AT) gabi-soft (DOT) fr> wrote: Quote: Roland Pibinger wrote: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; That's a difficult requirement. In practice, most of my value types meet it, but only because I replace the new_handler to abort, rather than throw, if allocation fails:-). The above requirements should hold. Other constructors (non-default and non-copy constructors) may throw because they need to validate input and report failure with an exception. The idea is to define basic 'bricks' with strong constraints. Larger objects (value and entity types) made of these bricks automatically 'inherit' (in a non-OO-sense) their properties. Best regards, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Tony Delroy Guest Posted: Wed Oct 12, 2005 4:36 pm    Post subject: Re: 'Pure' value types? Roland wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; I think you're specifying a weird mix of criteria here - perhaps you have a vague instinctive notion about some kind of "basic" type and think others will access similar notions they have, despite your actual description. Terminology I've encountered that relates vaguely to what you mention includes value-semantic types, vocabulary types, and POD types. Quote: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; This suggests POD types. Robust operation in the presence of dynamic memory usage requires either throwing or placing the object in an error state to be tested later. The latter approach can be elegant, but it is more subtle and users of such a class often get it wrong. Quote: - assignment is the only way to change (mutate) the object; This is an unusual requirement. It suggests that the type is notionally "atomic" (as you won't provide operations to set particular fields), OR something bizarre like a type-map where the field to set is implicit in the type being assigned from. This criteria doesn't match the types discussed elsewhere in this thread: for example, strings can be mutated by non-assignment member functions. Generally, I suggest you read about (user-defined) "value-semantic" types. Informally, my impression of typical features: - observed behaviour for copy-construction and assignment is as per a new instance with the value of the right-hand-side/source/copied object - operators work in an intuitive way, matching analogous behaviours for whatever int/real/string types they resemble - sensible automatic memory management if necessary (for things like variable-sized character buffer for string) - there's a sense that they encapsulate some small unit of data, rather than provide high-level procedural services - typically types that you might reasonable imagine a container of, as distinct from singletons. - there's no requirement for them not to throw though - indeed, robust but concise behaviour of copy-constructors and operators is a core motivation for exceptions - examples include dates, where mutating member functions may include things like set_to_first_day_of_month(), set_to_next(TUESDAY) etc.. Some containers take ownership of the values they store, and have value-semantic behaviours for copy-construction and assignment. I don't know whether they are formally considered value-semantic types, but suspect not. Regards, Tony [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Mirek Fidler Guest Posted: Wed Oct 12, 2005 4:38 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? Well, I believe than in some languages they are called "immutable", but I might be wrong. Also, as James correctly pointed out, built-in value types in C++ are not strictly "immutable", because there are operators like '+=' or '++' which can be considered mutating methods. Mirek [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Wed Oct 12, 2005 10:45 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; chris jefferson wrote: Quote: Remember ++ and -- Roland Pibinger replied: Quote: Not necessarily, think of string types! I don't get what you're saying. Chris was surely pointing out that you can mutate int and long with ++ and --, which is not normally considered assignment. What you're saying about std::string doesn't seem to make sense in this connection. Then again, std::string doesn't seem to match your criteria either, because the constructor can throw. I'm sure that I'm missing some subtle meaning here, because at first glance it looks to me like NONE of the standard types (either built-in or library) obey your criteria. Quote: 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? I'd ask what you're trying to accomplish.. but it looks like you're looking for terminology, not techniques. Quote: I've always called them "builtin-like" types, but I'm sure there is a beter name. Presumably meant to parallel the name "builtin" types, which refers to types that can be used without having to #include anything at all...? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Thu Oct 13, 2005 1:16 pm    Post subject: Re: 'Pure' value types? On 12 Oct 2005 12:38:20 -0400, Mirek Fidler <cxl (AT) volny (DOT) cz> wrote: Quote: Well, I believe than in some languages they are called "immutable", but I might be wrong. Also, as James correctly pointed out, built-in value types in C++ are not strictly "immutable", because there are operators like '+=' or '++' which can be considered mutating methods. I've also had 'immutable objects' in mind. But, as you point out, an object with operator= cannot be called 'immutable'. In C#, Java, ... in order to be usable immutable objects need mutable references. So, conceptually, there is no big difference between 'immutable' value objects in C#, Java, ... and [to be filled] value objects in C++. Best wishes, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Thu Oct 13, 2005 1:31 pm    Post subject: Re: 'Pure' value types? Tony Delroy wrote: Quote: Roland wrote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; I think you're specifying a weird mix of criteria here - Not really. I can see a lot of advantage of a type giving these guarantees. With the possible extension that there might be additional mutating operators (like +=), provided that these operators are all defined in terms of assignment. Quote: perhaps you have a vague instinctive notion about some kind of "basic" type and think others will access similar notions they have, despite your actual description. Terminology I've encountered that relates vaguely to what you mention includes value-semantic types, vocabulary types, and POD types. They're definitely not just POD types. Think of things like complex. Quote: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; This suggests POD types. Not at all. Quote: Robust operation in the presence of dynamic memory usage requires either throwing or placing the object in an error state to be tested later. It depends on the application and the object. In most of my applications, I replace the new_handler to abort, so I can never see a bad_alloc -- it makes life a lot simpler, and in practice, the only way I'm going to run out of memory is if I leak. (It's worth pointing out, of course, that I mostly develop server software which runs on dedicated servers. There aren't othe applications on the system which might cause me to run out of memory.) Also, it's possible to design a class like string so that the default constructor and the assignment operator don't allocate, although other constructors might. Quote: The latter approach can be elegant, but it is more subtle and users of such a class often get it wrong. I don't think he was recommending the latter approach. The latter approach is valid for object types which may become invalid after having been validly constructed -- the user has to systematically check the state anyway, so having to do so after construction is no additional burden. But that's about it. (There are a few other exceptions, and I've seen this technique used in transactional systems.) Quote: - assignment is the only way to change (mutate) the object; This is an unusual requirement. It suggests that the type is notionally "atomic" (as you won't provide operations to set particular fields), OR something bizarre like a type-map where the field to set is implicit in the type being assigned from. He didn't say anything about assignment being atomic. The requirement does mean that the user cannot modify individual parts of the object. This is generally the case for non collection value objects, however, or should be. Quote: This criteria doesn't match the types discussed elsewhere in this thread: for example, strings can be mutated by non-assignment member functions. std::string can be. I've never heard anyone accusing std::string of being particularly clean design, however. Cleanly designed string classes (like my pre-standard String, or java.lang.String) can't be modified other than by assignment, however. This is, of course, supposing that the abstraction behind string is a text string -- if the abstraction is just a collection of characters, other rules hold. Quote: Generally, I suggest you read about (user-defined) "value-semantic" types. Informally, my impression of typical features: - observed behaviour for copy-construction and assignment is as per a new instance with the value of the right-hand-side/source/copied object - operators work in an intuitive way, matching analogous behaviours for whatever int/real/string types they resemble - sensible automatic memory management if necessary (for things like variable-sized character buffer for string) - there's a sense that they encapsulate some small unit of data, rather than provide high-level procedural services - typically types that you might reasonable imagine a container of, as distinct from singletons. - there's no requirement for them not to throw though - indeed, robust but concise behaviour of copy-constructors and operators is a core motivation for exceptions Not necessarily. There is a very great advantage in being able to construct types without risk of throwing. Quote: - examples include dates, where mutating member functions may include things like set_to_first_day_of_month(), set_to_next(TUESDAY) etc.. I would be very sceptical of a design in which the date class had such mutating functions. Far better would be functions (probably non-member) which would create a new date. In fact, IMHO, date would be a very good example of the type of class he is looking for. Quote: Some containers take ownership of the values they store, and have value-semantic behaviours for copy-construction and assignment. I don't know whether they are formally considered value-semantic types, but suspect not. Containers are a special case. Their only semantic is to contain other objects, so of course, these other objects are exposed to the user. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Thu Oct 13, 2005 1:33 pm    Post subject: Re: 'Pure' value types? Mirek Fidler wrote: Quote: Roland Pibinger wrote: Is there a name in use for user-defined value types that behave essentially like built-in value types? I mean value types that meet the following criteria: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; - assignment is the only way to change (mutate) the object; 'Pure' or 'strong' value types may be an appropriate name. But probably there exists one already? Well, I believe than in some languages they are called "immutable", but I might be wrong. Also, as James correctly pointed out, built-in value types in C++ are not strictly "immutable", because there are operators like '+=' or '++' which can be considered mutating methods. Yes and no. The formal definition of a += b is that it is the same as a = a + b, except that (the lvalue of) a is only evaluated once. And the formal definition of ++ a is a += 1. So semantically, these are all the equivalent of an assignment. Of course, there is also the problem that they may throw. Overflow is undefined behavior, and one possible actual behavior would be to throw an exception. But with regards to the formal definition, the exception is raised during the calculation of the value to be assigned. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Thu Oct 13, 2005 1:34 pm    Post subject: Re: 'Pure' value types? Roland Pibinger wrote: Quote: On 10 Oct 2005 09:41:04 -0400, "kanze" <kanze (AT) gabi-soft (DOT) fr> wrote: Roland Pibinger wrote: - default constructor, copy constructor and operator= do not throw an exception, i.e. have exception specification 'throw()'; That's a difficult requirement. In practice, most of my value types meet it, but only because I replace the new_handler to abort, rather than throw, if allocation fails:-). The above requirements should hold. Other constructors (non-default and non-copy constructors) may throw because they need to validate input and report failure with an exception. The idea is to define basic 'bricks' with strong constraints. Larger objects (value and entity types) made of these bricks automatically 'inherit' (in a non-OO-sense) their properties. I understand the interest of such types. I'm just pointing out that if the class needs resources, and acquiring those resources may fail, you may have problems with the copy constructor, at least if deep copy is implemented. The most ubiquious resource is dynamic memory, and I can imagine a lot of value-oriented classes which use dynamic memory. Of course, if the only modification of the object is through assignment, then reference counting can be used for copy. (In this case, I think we could extend "assignment" to include any operation whose semantics are defined in terms of total assignment. The thing which breaks reference counting is partial modification.) -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.