C++0x Concepts fall

This is a discussion on C++0x Concepts fall within the General Discussions forums, part of the Community Boards category; In general, Direct3D is designed to be a 3D hardware interface. The feature set of Direct3D is derived from the ...

  1. #16

    Join Date
    May 2005
    Posts
    1,041
    In general, Direct3D is designed to be a 3D hardware interface. The feature set of Direct3D is derived from the feature set of what hardware provides. OpenGL, on the other hand, is designed to be a 3D rendering system that may be hardware accelerated. These two APIs are fundamentally designed under two separate modes of thought. The fact that the two APIs have become so similar in functionality shows how well hardware is converging into user functionality[citation needed].
    Comparison of OpenGL and Direct3D - Wikipedia, the free encyclopedia
    I'm not immature, I'm refined in the opposite direction.

  2. #17
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Why is this thread turning into "OpenGL vs Direct3D"?

    Anyway, I think concepts are a good idea, but not a great one. I understand that they dropped them. Seems like they have understood that they were making the language too complex. There are so many things that are added, and I doubt there will be a complete reference for C++0x - The current ones for "normal" C++ are thick enough.

    I personally don't like the new function definition types nor the new typedef possibilities.

    But I love static_assert and many others.

    And I don't know who will implement all this

  3. #18
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    Why is this thread turning into "OpenGL vs Direct3D"?
    I should not have used that as an example. I forgot how easy it was to derail threads simply by mentioning those two words.

    At any rate, I'm just looking forward to the "auto" keyword. Everything else is just unnecessary fluff

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,438
    Quote Originally Posted by Brafil View Post
    Seems like they have understood that they were making the language too complex.
    I have very personal opinions on that matter which probably aren't very popular. But I don't see syntax or semantics complexity as such a big problem. But hey, here it is...

    C++ is already a complex language to learn and use. Certainly adding new features to the language while keeping a close eye on complexity is a good goal. But there's three aspects to Concepts that I think make the whole "will Joe Coder want to use Concepts" the wrong debate. The fact that this is at the core of the decision to abandon Concepts on C++0x, since even the implicit or explicit concept mapping discussion has its roots on that question, is very disheartening to me. It leaves a foul taste in my mouth that politics and frivolous debate was the real issue. Not Concepts. A feeling that Herb Sutter's recent blog post makes even stronger. Especially if you then compare that to Stroustrup article.

    But the three aspects...

    1. Can we tell exactly what adds more to complexity? Hard to follow syntax and semantics, or weak error diagnostics? It's my feeling it is the latter. A hard to follow syntax is invariably going to be learned at some point, the same goes for semantics. It's a matter of study. No different from so many other professional areas, from accounting to scientific fields. But hard to track bugs or hard to understand compiler reports is going to strain the coder a lot more. What we have now is a syntax that is somewhat easy to teach, semantics somewhat easy to learn, but the coder is left alone trying to understand template related errors messages. This is particularly damaging to library developers who suffer the most. One of Concepts primary aim was exactly to create the necessary groundwork that would help to considerably improve current template diagnostics. In my view, this alone makes Concepts a feature that reduces programming complexity already.

    2. C++ is a multi-paradigm programming language. This has far more repercussions than just the admission we can use different tools for different jobs. It should also be the understanding that some jobs simply aren't as easy as others. In C++ certain paradigms are definitely harder to grasp than others. For a newcommer going from procedural programming to OOP is a big step. The language is made harder for them and it will take a long while until all the new concepts, semantics and syntax get buried in their brain. It is in my view acceptable that Generic Programming is accepted as being even harder. Of course, whenever there is a chance to simplify learning and usage one should take it. But this can't be the basis for deciding wether a feature is going to be implemented or not. Being that Concepts was primarily aimed at Library Developers, does it really makes sense to ask "will Joe Coder use Concepts"? Joe Coder will use concepts yes. One day, whe, he feels more comfortable with the language and decides to step into more complex areas of software development. Just like he did a couple of years ago when he decided it was time to go OOP and tackle all the incredible complexity of this new paradigm in C++. This has also a lot to do with the natural characteristic of C++ of being a modular programming language, which makes it easy to teach and learn. And it really surprises me the whole debate around complexity vs. simplicity. It's in my opinion a mistake to oversimplify or to aim for simplicity above all else. "Simple" is often harder or impossible to achieve... should the alternative be no feature at all?

    3. Finally, there's the admission that conceptually C++ templates are irreprehensible, but the theoretic basis on which they were implemented in C++ is weak. I'm not sure I understand this argument very well. But it's a fact that it took me a long time to actually soak in the concept of Generic Programming to start taking advantage of it beyond simple function templating. However the concept of Concepts was immediately understood. It made a whole lot of sense to me. That... and I liked it because of that. It just seems, with Concepts, C++ Generic Programming would be made easier to teach and learn. Can I be biased by the fact I was already aware of Generic Programming concept and its advantages when I first started reading about Concepts? It's possible. I may be looking at Concepts as easier simply because I understand better now what generic programming is under C++. But inm my defense I'll say that I'm in fact a newcmmer to generic programming with no more than 1 year on my back and very little to show in terms of actual work. So I'd give this 3rd point also some consideration.
    Last edited by Mario F.; 07-24-2009 at 10:42 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #20
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by phantomotap View Post
    "Integration, especially with the library, was a very complex task, and uncovered many weaknesses, both of concepts themselves and of other language features, such as rvalue references."

    O_o

    Please don't tell me "r-value references" were dropped too!?
    No.

    But it was the interaction with concepts that pointed out that it's not safe, in general, to let rvalue references bind to lvalues. So they changed it.

    It was in the course of concept integration that they discovered that throwing move constructors (and moving is closely tied with rvalue refs) are completely unsafe - as with throwing destructors, if you have one, you simply cannot write exception-safe code. Now they're discussing a "nothrow" annotation that is actually part of the type system.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #21
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    Quote Originally Posted by Brafil View Post
    Why is this thread turning into "OpenGL vs Direct3D"?

    Anyway, I think concepts are a good idea, but not a great one. I understand that they dropped them. Seems like they have understood that they were making the language too complex. There are so many things that are added, and I doubt there will be a complete reference for C++0x - The current ones for "normal" C++ are thick enough.

    I personally don't like the new function definition types nor the new typedef possibilities.

    But I love static_assert and many others.

    And I don't know who will implement all this
    I think you have a negative outlook.
    C++ is supposed to be a general purpose programming language, combining multiple paradigms.
    Now, templates are difficult to master. Should we remove them to make the language easier to learn? I think not. Expert programmers should not have to suffer because newbies might have a difficult time grasping all concepts.
    Is there a single developer out there that knows the entire C# or Java Standard Library? Doubtful.
    What I mean is that usually we strive to learn what it is we want to do and a language provides the facilities to do so. So you want to do OOP programming. Sure. Learn the OOP part.
    So, you want to do Generic programming. Sure. Learn the generic part.

    The new typedefs and the new function definition types enhances the parts that C++ specializes in. Making it easier and more powerful, even.
    So I think it's a real shame they dropped Concepts, but I am very positive about every other added feature.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    I don't blame. Many concepts are great:

    constexpr,
    rvalue references,
    extern templates,
    initializer lists,
    auto variable,
    decltype,
    the new for-loops,
    thread_local,
    regexes,
    Suffixes - a nice "toy" that can be both very fun and useful

    The things I would reconsider:
    nullptr - It's not very elegant IMO. But I don't know a better way of doing it.
    using instead of typedef. I didn't really grasp that.

    Just a question: Isn't it possible to add template typedefs?
    Just another question: can you have mixed initalizer lists (std::initializer_list<int, char, double>)?

    Now, templates are difficult to master. Should we remove them to make the language easier to learn? I think not. Expert programmers should not have to suffer because newbies might have a difficult time grasping all concepts.
    Never! Templates are a very important part of C++!

    The only thing I didn't like was the added complexity for _compiler-writers_ and the possibility of misusing some concepts. Like always using the new function definitions - looks more like Pascal. The "C" way is one of the things I truly like about C/C++.

    But the discussion was about concepts, right? Maybe they'll include them later.

  8. #23
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    Quote Originally Posted by Brafil View Post
    using instead of typedef. I didn't really grasp that.
    You declare template typedefs the same way you declare namespace aliases.

    But the discussion was about concepts, right? Maybe they'll include them later.
    Maybe. We'll see in the future.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Brafil View Post
    The things I would reconsider:
    nullptr - It's not very elegant IMO. But I don't know a better way of doing it.
    What do you think are the problems of nullptr? I've played around with it (and I've implemented it) and I find it very intuitive.

    using instead of typedef. I didn't really grasp that.

    Just a question: Isn't it possible to add template typedefs?
    The alias declarations with 'using' can do that, yeah. You can actually have a lot of fun with them. The reason we have 'using' instead of 'typedef' is, I think, mainly one of grammar. The way typedef works, I think it would be very hard to make template typedefs that don't look absolutely atrocious. In general, the new syntax is much nicer than the arcane C syntax.
    Code:
    using INT = int;
    // Arcane:
    typedef void (*WhyIsTheNameHere)(int);
    // Logical:
    using ThisIsGood = void (*)(int);
    
    // Template:
    template <typename T>
    using SpecialVector = std::vector<T, SpecialAllocator<T>>;
    
    // Fun:
    template <bool MutablePointer>
    struct MetaFunction {
      using type = std::string;
    };
    template <>
    struct MetaFunction<true> {
      using type = std::vector<char>;
    };
    template <bool MutablePointer>
    using StringType = typename MetaFunction<MutablePointer>::type;
    
    StringType<false> this_is_a_std_string;
    Stringtype<true> this_is_a_char_vector;
    Just another question: can you have mixed initalizer lists (std::initializer_list<int, char, double>)?
    Initializer lists can be heterogenous, and the compiler will interpret the elements as constructor arguments and do overload resolution. However, std::initializer_list can only represent homogenous initializer lists.
    Code:
    class A {
      A(int, float, std::string);
    };
    class B {
      B(std::initializer_list<int>);
    };
    
    A a{1, 1, "hello"};
    B b{1, 2, 3, 4, 5, 6, 7, 8, 9};
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #25
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Why is this thread turning into "OpenGL vs Direct3D"?
    It's not.

    I was hoping the new standard would be finalized soon because the longer it takes the longer we have to wait for it to appear in compilers. It does seem to me that, based on the article, there have been some significant missteps.

  11. #26
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Yeah, but anyone should agree it's not easy to design all that. So we should rather have called it C++1x. Some do so.

    How about that:
    Code:
    template <typename Type>
    typedef Getter = const Type &(*)(void);
    
    template <typename Type>
    typedef Setter = void (*)(const Type &);
    
    Getter<bool> IsActive;
    Setter<bool> SetActive;
    So, just typedef instead of using? With the new syntax? I think that would be nice.
    Last edited by Brafil; 07-25-2009 at 02:18 AM.

  12. #27
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    So, just typedef instead of using? With the new syntax? I think that would be nice.
    As I said, it's a grammar problem. I know the internals of only one compiler, but I can tell that while it would be possible to modify it to parse this, it would lead to some very ugly code in the parser.
    The using keyword doesn't have as much grammatical cruft attached.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #28
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,546
    Quote Originally Posted by Brafil View Post
    Yeah, but anyone should agree it's not easy to design all that. So we should rather have called it C++1x. Some do so.
    I kinda agree. It would be far better if they incorporated less stuff in less timeframes so new standards can be released more often. It already takes a decade to figure out how to implement all this stuff since they meet so "often."
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #29
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    I kinda agree. It would be far better if they incorporated less stuff in less timeframes so new standards can be released more often. It already takes a decade to figure out how to implement all this stuff since they meet so "often."
    But then again, switching between languages often isn't good either.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  15. #30
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    Ok. I understand now. As far as I know, using is only used for copying data into namespaces. And in C++0x, also into classes, right?

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 5
    Last Post: 08-31-2004, 06:41 PM
  2. Programming concepts
    By lyx in forum C++ Programming
    Replies: 2
    Last Post: 12-02-2003, 11:37 PM
  3. Independent & Effeciency :: Programming Concepts
    By kuphryn in forum C++ Programming
    Replies: 5
    Last Post: 06-08-2002, 05:08 AM
  4. Basic 2d Programming Concepts
    By JoshG in forum Game Programming
    Replies: 4
    Last Post: 05-17-2002, 05:54 AM
  5. Microsoft Fall?
    By Sekti in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 02-25-2002, 03:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21