C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Suggestion for C++ language extensions Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Ekkehard Morgenstern Guest Posted: Sat Nov 15, 2003 3:01 pm    Post subject: Suggestion for C++ language extensions Hi all, I'd like to suggest the following features for future standards of the C++ programming language. I have not read the more recent standard documents, so I'm not sure whether some are already in the standard, so tell me if so. 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " 2. The addition of at least standard headers, if not new types, for bit-size-specific types, like "uint32_t". 3. The addition of optional range checking for standard array types. array-dim-def := '[' expr [ 'range' [ expr '..' expr ] 'checked' ] ']' . this could look like "int a[3 range checked 0..2]" or "int a[3 range checked]" for example. 4. The addition of dynamic arrays. array-dim-def := '[' expr | 'dynamic' ']' this could look like "int a[dynamic];" 5. The addition of optionally checked pointer types. pointer-def := 'checked' type '*'; // or similar this could look like "checked int* p;" a pointer like this would be checked during runtime before usage (like, at the first use in every block scope or something, or during every operation). 6. The addition of value range checking for integral or floating-point base types. range-checked-base-type := [ 'range' [ expr '..' expr ] 'checked' ] base-type . This could look like "range 0..2 checked int a;" A check would be performed before every assignment to such a variable. A default range-checked variable, like "range checked int a;" would be checked for overflows in arithmetic operations also. 7. The addition of an optional byte ordering syntax for integral or floating-point base types. ordered-base-type := [ ( 'msblsb' | 'lsbmsb' ) 'ordered' ] base-type . This would look like 'msblsb ordered int a = 0x12345678;'. This would permit setting the byte ordering for structure members, for example. The compiler would generate code to read and write such variables properly, for example. This way, reading and writing such fields from and to permanent storage or streams would be a piece of cake without any programming overhead. 8. The definition of anonymous classes. class-decl := ( 'anonymous' 'class' | 'class' identifier ) class-decl-body . this would look like "A* a = new anonymous class : public A { ... }" Constructors and destructors could use "anonymous()" then. (I'll implement these features in my new Q2 (working title) programming language, but it'd be great to find them in C++ as well.) Regards, Ekkehard Morgenstern. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top James Kuyper Guest Posted: Sun Nov 16, 2003 11:18 pm    Post subject: Re: Suggestion for C++ language extensions [email]ekkehard.morgenstern (AT) onlinehome (DOT) de[/email] ("Ekkehard Morgenstern") wrote in message news:<bp3l5h$hm9$1 (AT) online (DOT) de>... Quote: Hi all, I'd like to suggest the following features for future standards of the C++ programming language. I have not read the more recent standard documents, so I'm not sure whether some are already in the standard, so tell me if so. 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " What is the use of this? How is this better than: int c = 3+5; Quote: 2. The addition of at least standard headers, if not new types, for bit-size-specific types, like "uint32_t". These were added in C99, and are likely to be added in some form to the next version of C++. Quote: 4. The addition of dynamic arrays. array-dim-def := '[' expr | 'dynamic' ']' this could look like "int a[dynamic];" I think you mean something similar to C99's variable length arrays. If so, it needs to be considered very carefully. The C99 committee found that VLAs had lots of complicated side-effects on the language specification. In particular, sizeof(vla) has to be evaluated at run time, rather than compile time. I suspect that the revisions to C++ that would be needed are much greater. It's also less useful in C++, since C++ already has a way to declare dynamically sized arrays (with somewhat different semantics): vector<int> a(initial_size); --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Pete Becker Guest Posted: Mon Nov 17, 2003 4:57 pm    Post subject: Re: Suggestion for C++ language extensions James Kuyper wrote: Quote: I think you mean something similar to C99's variable length arrays. If so, it needs to be considered very carefully. The C99 committee found that VLAs had lots of complicated side-effects on the language specification. In particular, sizeof(vla) has to be evaluated at run time, rather than compile time. I suspect that the revisions to C++ that would be needed are much greater. One fairly obvious example is the interaction of VLA's with inheritance. -- Pete Becker Dinkumware, Ltd. (http://www.dinkumware.com) --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Kevin Saff Guest Posted: Wed Nov 19, 2003 3:14 am    Post subject: Re: Suggestion for C++ language extensions ""Ekkehard Morgenstern"" <ekkehard.morgenstern (AT) onlinehome (DOT) de> wrote in message news:bp3l5h$hm9$1 (AT) online (DOT) de... Quote: Hi all, 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " There's no need to add a keyword for something like this - just use a named function. Quote: 2. The addition of at least standard headers, if not new types, for bit-size-specific types, like "uint32_t". I agree. Quote: 3. The addition of optional range checking for standard array types. array-dim-def := '[' expr [ 'range' [ expr '..' expr ] 'checked' ] ']' . this could look like "int a[3 range checked 0..2]" or "int a[3 range checked]" for example. Use std::vector and at(). Quote: 4. The addition of dynamic arrays. array-dim-def := '[' expr | 'dynamic' ']' this could look like "int a[dynamic];" std::vector. Quote: 5. The addition of optionally checked pointer types. pointer-def := 'checked' type '*'; // or similar this could look like "checked int* p;" a pointer like this would be checked during runtime before usage (like, at the first use in every block scope or something, or during every operation). I'm not sure what you want to "check", but here's one way: template <class T> class checked_ptr { T *held; public: T *operator->() { if (held) return held; else throw std::exception ("checked_ptr::operator-> failed"); } T& operator* () { if (held) return *held; else throw std::exception ("checked_ptr::operator* failed"); } /* include appropriate constructors, destructors, and operators. */ }; Also the syntax "checked int * p" is horrible. For consistency with C type declarations this would mean the int is checked, not the pointer. "int * checked p" would be better, although still unnecessary. Quote: 6. The addition of value range checking for integral or floating-point base types. range-checked-base-type := [ 'range' [ expr '..' expr ] 'checked' ] base-type . This could look like "range 0..2 checked int a;" A check would be performed before every assignment to such a variable. A default range-checked variable, like "range checked int a;" would be checked for overflows in arithmetic operations also. template <class T, T Min, T Max> // fine for integral types class range { T value; public: range& operator= (T newval) { if (newval >= Min && newval <= Max) value = newval; else throw std::exception ("value out of range"); return *this; } /* include other appropriate constructors and operators*/ }; Some compilers support floating-point types as template parameters - I think this is an extension. So for those you may need members representing max and min, or stick to integral and rational bounds. Quote: 7. The addition of an optional byte ordering syntax for integral or floating-point base types. ordered-base-type := [ ( 'msblsb' | 'lsbmsb' ) 'ordered' ] base-type . This would look like 'msblsb ordered int a = 0x12345678;'. This would permit setting the byte ordering for structure members, for example. The compiler would generate code to read and write such variables properly, for example. This way, reading and writing such fields from and to permanent storage or streams would be a piece of cake without any programming overhead. This is more complex than the above examples, but can still be accomplished with a user-defined class. The nice thing about user-defined types is the language does not have to have built-in ways to define every conceivable datatype. Quote: 8. The definition of anonymous classes. class-decl := ( 'anonymous' 'class' | 'class' identifier ) class-decl-body . this would look like "A* a = new anonymous class : public A { ... }" Constructors and destructors could use "anonymous()" then. Again, I think there's no need to add new syntax for this when it is rarely needed and a class in an anonymous namespace works as well. Quote: From what you've said, it sounds like you'd be better off just implementing the types you need in C++ then trying to create a new language to handle these things. Languages get too convoluted when they try to create new syntax for everything - the power of object-oriented programming is that a language can provide the minimum necessary types and users can create all the aggregate types they need. For example, I sometimes need a pointer which may or may not take ownership of an object. This was easy to implement using standard language features, so there was no need to add new syntax to the language. I recommend you first provide this amount of flexibility to your language, before you worry about which things should be syntactically simpler. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ekkehard Morgenstern Guest Posted: Thu Nov 20, 2003 3:15 am    Post subject: Re: Suggestion for C++ language extensions "James Kuyper" <kuyper (AT) wizard (DOT) net> schrieb im Newsbeitrag news:8b42afac.0311161239.1e75f3f4 (AT) posting (DOT) google.com... Quote: 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " What is the use of this? How is this better than: int c = 3+5; It allows grouping of expressions in an extra scope. Like, you'd sometimes create an isolated code block within a code block, as in: { ... { ... } } to distinguish code blocks from one another. A valof{} expression does the same, but permits to return a result. Bjarne Stroustrup once wrote in an issue of "The C++ Programming Language" (on page 4 of the Second Edition), that "C++ still lacks a VALOF block". I agree that that would be a useful extension to the language. valof{} blocks have some of the advantages of unnamed functions. At least you can integrate code that would normally belong into a seperate function, but is used only once, into a seperate block of the same function, to be moved out later when necessary. Quote: 4. The addition of dynamic arrays. array-dim-def := '[' expr | 'dynamic' ']' this could look like "int a[dynamic];" I think you mean something similar to C99's variable length arrays. If so, it needs to be considered very carefully. The C99 committee found that VLAs had lots of complicated side-effects on the language specification. In particular, sizeof(vla) has to be evaluated at run time, rather than compile time. I suspect that the revisions to C++ that would be needed are much greater. Since the compiler knows what type an array is of, it can generate code for sizeof() appropriately, either generating a constant expression or an intrinsic function call. For example, if the dynamic array is to be internally represented by either a specialized pointer type or a pointer to a specialized data structure, implementation-dependent, then sizeof() could return a constant value if applied to a structure containing a dynamic array, but return the array's actual size when applied to the array itself. With 'dynamic array' I mean an array that changes size dynamically during runtime. For example, it could be replaced by vector<T> internally, if so defined. It would just be syntactically easier to write "int a[dynamic];" instead of "vector<int> a;" and then some. Quote: It's also less useful in C++, since C++ already has a way to declare dynamically sized arrays (with somewhat different semantics): vector<int> a(initial_size); This has the disadvantage that the template class "vector" has to be available and properly implemented in the implementation. Also, if the compiler replicates the template instance's code over every module, it can lead to code bloat. A dynamic array for base types would resolve the cases of most frequent use. Of course, then you could also integrate a "string" type into the language. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ekkehard Morgenstern Guest Posted: Thu Nov 20, 2003 10:55 pm    Post subject: Re: Suggestion for C++ language extensions Quote: 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " There's no need to add a keyword for something like this - just use a named function. Sometimes you don't want to use a named function, especially if you need it only once, and/or if the code is to be private to the function it's in, or if it's to be moved out later. valof{} blocks also permit to group code in the case you don't want to create an extra function but a subroutine within a function. Quote: 3. The addition of optional range checking for standard array types. array-dim-def := '[' expr [ 'range' [ expr '..' expr ] 'checked' ] ']' . this could look like "int a[3 range checked 0..2]" or "int a[3 range checked]" for example. Use std::vector and at(). 4. The addition of dynamic arrays. array-dim-def := '[' expr | 'dynamic' ']' this could look like "int a[dynamic];" std::vector. Using "vector" requires that you have a C++ compiler that is shipped with the STL, and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. A built-in dynamic array type would relieve the programmer from such worries. Explicit range check declarations would also contribute to the overall readability of the code. Plus, it would be possible then to modify code that used to work with regular arrays to be dynamic and/or range checked. Quote: 5. The addition of optionally checked pointer types. pointer-def := 'checked' type '*'; // or similar this could look like "checked int* p;" a pointer like this would be checked during runtime before usage (like, at the first use in every block scope or something, or during every operation). I'm not sure what you want to "check", but here's one way: It's not just about null pointer checking. It would be possible then to perform an implementation-defined pointer check (like checking if the pointer is (still) addressing the memory it was allocated for, or if it points to specific allocated memory pages of the process). You could also use the term "validated". By using classes, you possibly cannot achieve this, since it's a feature that is implementation-specific but should be made transparent to the programmer. Quote: Also the syntax "checked int * p" is horrible. For consistency with C type declarations this would mean the int is checked, not the pointer. "int * checked p" would be better, although still unnecessary. You're right, technically it belongs to the group "volatile / const / mutable" . So one could add another, "checked" or "validated". Quote: 6. The addition of value range checking for integral or floating-point base types. range-checked-base-type := [ 'range' [ expr '..' expr ] 'checked' ] base-type . This could look like "range 0..2 checked int a;" A check would be performed before every assignment to such a variable. A default range-checked variable, like "range checked int a;" would be checked for overflows in arithmetic operations also. Quote: Some compilers support floating-point types as template parameters - I think this is an extension. So for those you may need members representing max and min, or stick to integral and rational bounds. The approach you suggested to this would be nonstandard and with excess typing overhead for using. The reason why I'd like to see it as a standard feature in C++ is because I'd like to encourage the use of range checks to make software more readable and less error prone. Also, if the range checking was a standard feature, it would also generate less code than with user-supplied classes. Quote: 7. The addition of an optional byte ordering syntax for integral or floating-point base types. ordered-base-type := [ ( 'msblsb' | 'lsbmsb' ) 'ordered' ] base-type . This would look like 'msblsb ordered int a = 0x12345678;'. This would permit setting the byte ordering for structure members, for example. The compiler would generate code to read and write such variables properly, for example. This way, reading and writing such fields from and to permanent storage or streams would be a piece of cake without any programming overhead. This is more complex than the above examples, but can still be accomplished with a user-defined class. The nice thing about user-defined types is the language does not have to have built-in ways to define every conceivable datatype. That's true, but if it's not a standard feature, people won't use it and still store or transmit data in a platform-dependent manner. If it'd be a standard feature to specify the byte ordering, it'd be possible to encourage writing code platform-independently. It'd also be easier for the compiler to do these things, than for the programmer coding it manually, because many processors have already instructions for those things. Like, on the IA-32 architecture, a "msblsb ordered int a; int b; ... ; a = b;" sequence could be translated to "mov eax,ebx; bswap eax;" for example, that'd be just one extra instruction overhead. Quote: 8. The definition of anonymous classes. class-decl := ( 'anonymous' 'class' | 'class' identifier ) class-decl-body . this would look like "A* a = new anonymous class : public A { ... }" Constructors and destructors could use "anonymous()" then. Again, I think there's no need to add new syntax for this when it is rarely needed and a class in an anonymous namespace works as well. Anonymous classes would be good for creating temporary classes that are needed only for a specific purpose. If you don't have such a feature, you have to create a class for every single case of such use. Quote: From what you've said, it sounds like you'd be better off just implementing the types you need in C++ then trying to create a new language to handle these things. Languages get too convoluted when they try to create new syntax for everything - the power of object-oriented programming is that a language can provide the minimum necessary types and users can create all the aggregate types they need. So you think C++ is a minimal and lightweight programming language? ;-) As I said, some of the features just belong into the language because the compiler would be able to generate shorter and more efficient code, and the users would actually feel encouraged to use them. They wouldn't add much extra complexity to the language, in fact most of them would be simple to integrate into an existing compiler. As for my own programming language developments, I will still try to think of simpler and easier to use programming languages. :-) --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top James Kuyper Guest Posted: Fri Nov 21, 2003 12:53 am    Post subject: Re: Suggestion for C++ language extensions [email]ekkehard.morgenstern (AT) onlinehome (DOT) de[/email] ("Ekkehard Morgenstern") wrote in message news:<bpfts2$46i$1 (AT) online (DOT) de>... Quote: "James Kuyper" <kuyper (AT) wizard (DOT) net> schrieb im Newsbeitrag news:8b42afac.0311161239.1e75f3f4 (AT) posting (DOT) google.com... 1. The addition of the BCPL valof (value of) expression syntax. valof-expr := 'valof' type '{' statement-block '}' . It would be notated like " int c = valof int { return 3+5; } " What is the use of this? How is this better than: int c = 3+5; It allows grouping of expressions in an extra scope. Like, you'd sometimes create an isolated code block within a code block, as in: { ... { ... } } to distinguish code blocks from one another. A valof{} expression does the same, but permits to return a result. I'm afraid that still leaves me unclear about the advantages of this feature. Perhaps a more specific example would make the usefullness clearer? .... Quote: I think you mean something similar to C99's variable length arrays. If .... With 'dynamic array' I mean an array that changes size dynamically during runtime. OK, so that's not quite the same as a VLA. VLAs have a potentially different size each time they are initialized, but do not change size during their own lifetimes. .... Quote: It's also less useful in C++, since C++ already has a way to declare dynamically sized arrays (with somewhat different semantics): vector<int> a(initial_size); This has the disadvantage that the template class "vector" has to be available and properly implemented in the implementation. Also, if the compiler replicates the template instance's code over every module, it can lead to code bloat. Well, that's also true it the compiler replicates the code needed to implement the dynamic array in every module. That's purely a QoI issue. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Bob Bell Guest Posted: Fri Nov 21, 2003 6:21 am    Post subject: Re: Suggestion for C++ language extensions [email]ekkehard.morgenstern (AT) onlinehome (DOT) de[/email] ("Ekkehard Morgenstern") wrote in message news:<bpfts2$46i$1 (AT) online (DOT) de>... Quote: "James Kuyper" <kuyper (AT) wizard (DOT) net> schrieb im Newsbeitrag news:8b42afac.0311161239.1e75f3f4 (AT) posting (DOT) google.com... It's also less useful in C++, since C++ already has a way to declare dynamically sized arrays (with somewhat different semantics): vector<int> a(initial_size); This has the disadvantage that the template class "vector" has to be available and properly implemented in the implementation. How much of a problem is that? Where is std::vector not available or implemented so poorly as to make this an issue? Quote: Also, if the compiler replicates the template instance's code over every module, it can lead to code bloat. So we need to introduce VLAs for compilers that don't compile templates very well, which by the time the next standard is finalized won't be very many compilers. Bob --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Matt Seitz Guest Posted: Fri Nov 21, 2003 6:24 am    Post subject: Re: Suggestion for C++ language extensions Ekkehard Morgenstern wrote: Quote: Using "vector" requires that you have a C++ compiler that is shipped with the STL, Doesn't the Standard already require that every C++ compiler be shipped with std::vector? Quote: and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. It might. How many people use compilers that don't support template instance optimizations? How much extra code do those compilers add to an actual project? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Francis Glassborow Guest Posted: Fri Nov 21, 2003 10:47 am    Post subject: Re: Suggestion for C++ language extensions In article <bpfvqu$9nl$1 (AT) online (DOT) de>, Ekkehard Morgenstern <ekkehard.morgenstern (AT) onlinehome (DOT) de> writes Quote: Using "vector" requires that you have a C++ compiler that is shipped with the STL, and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. A built-in dynamic array type would relieve the programmer from such worries. Explicit range check declarations would also contribute to the overall readability of the code. Plus, it would be possible then to modify code that used to work with regular arrays to be dynamic and/or range checked. And where is the array going to expand (The core language by design never uses new/delete)? I cannot think of a single feature of a 'built-in' dynamic array that is not already provided by std::vector. In addition it is completely contrary to the design philosophy of C++ to introduce a built-in type that could be provided as a library type. It seems to me that many of your proposals are concerned with QoI issues and are, perhaps, motivated by exposure to a very poor C++ implementation. Legislation will not change that problem. -- Francis Glassborow ACCU If you are not using up-to-date virus protection you should not be reading this. Viruses do not just hurt the infected but the whole community. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Richard Smith Guest Posted: Fri Nov 21, 2003 5:25 pm    Post subject: Re: Suggestion for C++ language extensions Matt Seitz wrote: Quote: and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. It might. How many people use compilers that don't support template instance optimizations? How much extra code do those compilers add to an actual project? What do you mean by "template instance optimizations"? Are you suggesting that some compilers are intelligent enough to notice when A<T1>::fn() is exactly the same as A<T2>::fn() and to commonise the implementation? -- Richard Smith --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top James Kuyper Guest Posted: Fri Nov 21, 2003 5:28 pm    Post subject: Re: Suggestion for C++ language extensions [email]ekkehard.morgenstern (AT) onlinehome (DOT) de[/email] ("Ekkehard Morgenstern") wrote in message news:<bpfvqu$9nl$1 (AT) online (DOT) de>... .... Quote: Using "vector" requires that you have a C++ compiler that is shipped with the STL, and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. A built-in dynamic array type would relieve the programmer from such worries. ... Why? How would you gaurantee that the implementation of the dynamic array type was any more efficient than the implementation of std::vector<>? .... Quote: This is more complex than the above examples, but can still be accomplished with a user-defined class. The nice thing about user-defined types is the language does not have to have built-in ways to define every conceivable datatype. That's true, but if it's not a standard feature, people won't use it and still store or transmit data in a platform-dependent manner. Standardizing it won't change that. People who can't be bothered with it won't use it, even if it's standardized. .... Quote: From what you've said, it sounds like you'd be better off just implementing the types you need in C++ then trying to create a new language to handle these things. Languages get too convoluted when they try to create new syntax for everything - the power of object-oriented programming is that a language can provide the minimum necessary types and users can create all the aggregate types they need. So you think C++ is a minimal and lightweight programming language? Yes, it is, at least when compared to what it would like like if every feature similar to the ones you propose were actually implemented at the language level. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Matt Seitz Guest Posted: Sat Nov 22, 2003 12:21 am    Post subject: Re: Suggestion for C++ language extensions Richard Smith wrote: Quote: Matt Seitz wrote: and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. How many people use compilers that don't support template instance optimizations? What do you mean by "template instance optimizations"? I meant whatever the original poster meant. To be clearer, I should have said "compiler/linker pairs" as the original poster did. Quote: Are you suggesting that some compilers are intelligent enough to notice when A<T1>::fn() is exactly the same as A<T2>::fn() and to commonise the implementation? No. I am asking whether the claim that std::vector "might generate extra code for every module if the compiler / linker pair does not support template instance optimizations" is relevant for a signicant number of developers, or is it just a hypothetical concern with little practical effect? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Kevin Saff Guest Posted: Sat Nov 22, 2003 3:24 am    Post subject: Re: Suggestion for C++ language extensions ""Ekkehard Morgenstern"" <ekkehard.morgenstern (AT) onlinehome (DOT) de> wrote in message news:bpfvqu$9nl$1 (AT) online (DOT) de... Quote: Using "vector" requires that you have a C++ compiler that is shipped with the STL, and it might generate extra code for every module if the compiler / linker pair does not support template instance optimizations. I don't see how your suggestion helps here. If a compiler is so old/bad it can't correctly handle vector how is adding dynamic arrays to the language spec going to help? It will just mean 5 years of poor quality dynamic array implementations, when proper vector support is available now. Quote: Also, if the range checking was a standard feature, it would also generate less code than with user-supplied classes. That may be true. Give you range-checking now, though, and I'm sure you'll want built-in _dynamic_ range-checking next year. Quote: If it'd be a standard feature to specify the byte ordering, it'd be possible to encourage writing code platform-independently. Like, on the IA-32 architecture, a "msblsb ordered int a; int b; ... ; a = b;" sequence could be translated to "mov eax,ebx; bswap eax;" for example, that'd be just one extra instruction overhead. I don't see how byte ordering could be useful outside of I/O operations, where compared to the I/O bottleneck an extra function call or two would hardly be noticed? Presumably one could use inline assembly to optimize for specific platforms when necessary. Put it in a place like boost.org, and I'm sure some people will use it. Quote: From what you've said, it sounds like you'd be better off just implementing the types you need in C++ then trying to create a new language to handle these things. Languages get too convoluted when they try to create new syntax for everything - the power of object-oriented programming is that a language can provide the minimum necessary types and users can create all the aggregate types they need. So you think C++ is a minimal and lightweight programming language? Of course not; I think it's already so complicated adding such new syntax is unlikely to improve clarity. Quote: As for my own programming language developments, I will still try to think of simpler and easier to use programming languages. I am sorry for being hard on you, though at a kidney per suggestion you did go through about 5 lifetimes in writing that list. I can think of two things that will never be in C++, that might be worth building a new language for: 1) Macros that respect scope, namespaces, and optional strong-typing. No matter how many language constructs are added to avoid macros, it seems they still have their uses. It might be best to admit their necessity and fix macros themselves instead of adding more workarounds for them. 2) User-defined "metaclasses". C++ only provides two kinds of "metaclasses" that barely differ: struct and class. Even the standard has the need to define sets of classes that are not easily described in the language itself (POD). Also, consider how inheritance is inadequate for dealing with all the boiler-plate necessary to define a singleton, for instance. I hope you can find a way to work one of these into your language. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Francis Glassborow Guest Posted: Sat Nov 22, 2003 11:16 pm    Post subject: Re: Suggestion for C++ language extensions In article <HopKws.9Bv (AT) news (DOT) boeing.com>, Kevin Saff <google.com (AT) kevin (DOT) saff.net> writes Quote: 1) Macros that respect scope, namespaces, and optional strong-typing. No matter how many language constructs are added to avoid macros, it seems they still have their uses. It might be best to admit their necessity and fix macros themselves instead of adding more workarounds for them. Indeed which is why one of the proposals being considered by the evolution group is to provide a mechanism for scoping macros. Quote: 2) User-defined "metaclasses". C++ only provides two kinds of "metaclasses" that barely differ: struct and class. Even the standard has the need to define sets of classes that are not easily described in the language itself (POD). Also, consider how inheritance is inadequate for dealing with all the boiler-plate necessary to define a singleton, for instance. I would not be so certain, as for all ideas for evolution of C++ it would depend on a good well-presented proposal that passed cost-benefit and impact analyses. -- Francis Glassborow ACCU If you are not using up-to-date virus protection you should not be reading this. Viruses do not just hurt the infected but the whole community. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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, library and standards 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.