kestion about boost

This is a discussion on kestion about boost within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by c++0x One of the biggest problems with committees is that they infringe upon the freedom of the ...

  1. #31
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Quote Originally Posted by c++0x View Post
    One of the biggest problems with committees is that they infringe upon the freedom of the end user to decide what stays and what goes. Its rather elitist, do you not concur?
    Absolutely not.
    First, you don't need to use what you don't want.
    Second, it's open, so you can enlist and have a say.
    This is unlike proprietary systems, where you don't have a say, whatsoever (although, you can make suggestions).

    Quote Originally Posted by cyberfish View Post
    I hope Greek is that easy...
    An iterator is just like a pointer wrapped in a pretty interface.
    I'd say an iterator is (or can be) a powerful generalization of a pointer.
    Imagine a search class.
    Iterators are used to iterate search results.
    Each time you increment the iterator, it could search the next search result on-demand. It saves valuable execution time to find all results, and it makes things transparent to the user.
    It works the way it is supposed you, and fast, yet with things going on behind the scenes with the help of an iterator.

    Or another example. What is testing the iterator is boolean fashion like:
    Code:
    if (it)
    Returns false if it's beyond the range of what it is iterating (ie, found the last search result)?

    These are small examples of what generalization of iterators can do.

    Quote Originally Posted by c++0x View Post
    U r so rite anon you are so much more helpful than anyone else who posts here! Thank you so much.
    That is called "You are so right". Best to learn to spell properly, or you won't be taken seriously.

    As for what smart pointers are... basically, they remove the burden of deallocation from the programmer.
    boost::shared_ptr will keep a reference count to an object, so each time another part of the program keeps a reference (so to speak) to the allocated object, the count increases. When the references go down, so does the count, until it reaches 0, when it finally releases the allocated object.
    This is basically done so that everytime a new boost::shared_ptr is created and assigned another boost::shared_ptr, the count increments. And everytime one of those objects go out of scope, the count decrements.
    boost::shared_ptr is the most useful and popular smart pointer in the library and comes in handy pretty much all the time. boost::shared_ptr is also available in TR1: std::tr1::shared_ptr.
    There are other smart pointers to solve other problems.
    For example std::tr1::weak_ptr and std::auto_ptr.
    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.

  2. #32
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    After reading the preliminary spec for C++ 0x it appears that shared_ptr and weak_ptr are the only safe pointer types being added to the standard. Correct me if I'm wrong.

    Also there are other items in the new standard that are either troubling or simply not needed IMO - tuples being one of them since the same thing can be accomplished now through the use of user-defined types. Also the auto variable idea needs to be trashed and discarded since it's a huge bug just waiting to occur. So I will concur that some of the new additions don't look all that 'cutting edge' to me and appear to be just bloat at times.

    However the best part about C++ is that you don't have to use the features you don't like or are unfamiliar with. IMO if you are unfamiliar with any of the STL I'm not sure you are really utilizing the power of C++ but if you are writing your own containers I guess it is possible.
    I have no problems with the standards committee since we aren't being forced to use any of the new features and if C++ as a language does not evolve to meet ever growing needs then the language will die. Periodic updates will keep it alive long into the future. Personally I've been looking at many other languages and scripts such as C#, Java, VB, ActionScript, and others. None of them give me the raw power and raw responsibility that C++ does.

    There has never really been a time with C++ where I felt like the language was working against me. In every other language when I try to do A it seems like I cannot because of language constraint B which is so annoying. C++ has very few constraints and if periodic updates continue to make it a viable solution for the marketplace then so be it. The alternative is very ugly.

  3. #33
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Also the auto variable idea needs to be trashed and discarded since it's a huge bug just waiting to occur.
    Why so?

    Code:
    #include <iostream>
    #include <cstring>
    #include <boost/bind.hpp>
    
    int main()
    {
        //auto fun = boost::bind(strcmp, _1, _2);
        boost::_bi::bind_t<
            int, int (*)(const char*, const char*),
            boost::_bi::list2<boost::arg<1> (*)(), boost::arg<2> (*)()>
            > fun = boost::bind(strcmp, _1, _2);
        std::cout << fun("hello", "world") << '\n';
    }
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  4. #34
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Bubba View Post
    After reading the preliminary spec for C++ 0x it appears that shared_ptr and weak_ptr are the only safe pointer types being added to the standard. Correct me if I'm wrong.
    unique_ptr. It's a rvalue-reference-using replacement for auto_ptr.

    Also there are other items in the new standard that are either troubling or simply not needed IMO - tuples being one of them since the same thing can be accomplished now through the use of user-defined types.
    Not really, not always. Tuples are better to work with in generic code. Also, tuples can be used to wrap a vararg template parameter set into a single parameter. I currently use tuples to simulate a vararg template - thought of course this particular use will be obsolete in C++0x. Tuples support tying, which would be complicated at best with user-defined types. That's another big advantage.

    Also the auto variable idea needs to be trashed and discarded since it's a huge bug just waiting to occur.
    If I can create variables of a result type in generic code witout having to duplicate the generating expression, if I can store the result of expression templates in a variable without having to write four lines of type first, then this is worth the small possibility of bugs from auto a hundred times.
    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

  5. #35
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I feel that the auto keyword will definitely make maintenance more difficult and the code less readable and thus I'm not for it. None of my fellow programmer friends/co-workers like the idea as it is. Perhaps that will change later but this is certainly a feature I will not be utilizing. Besides I doubt we get a fully 0x compiler for quite some time.

    I also notice that C++ 0x has taken on C# and every other new OOP language's idea of one level of derivation. Is this for concrete classes only or for abstract as well? In other words can a concrete class inherit from several abstract classes? I completely agree with not allowing multiple inheritance when it comes to concrete classes.

    Even though this thread was about boost I still think my questions are in line with the general theme thus far. I'm not against improvements to the language since it is my bread and butter but I hope the improvements are because of necessity and not to be 'like the other guy'. Other OOP languages don't even come close to C++ so far and perhaps b/c they don't need to or weren't designed to. I know the standards committee has the best intentions at heart when it comes to improvements and so I guess I will trust their judgement on what needs to be improved. As long as the language prospers well into the future I will be fine with that. I really don't understand the trend away from it and the excuse that it is slow to develop in and hard is not acceptable since this really depends on the programmer's ability.
    Last edited by VirtualAce; 12-13-2008 at 11:43 AM.

  6. #36
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Bubba View Post
    I feel that the auto keyword will definitely make maintenance more difficult and the code less readable and thus I'm not for it. None of my fellow programmer friends/co-workers like the idea as it is. Perhaps that will change later but this is certainly a feature I will not be utilizing. Besides I doubt we get a fully 0x compiler for quite some time.
    GCC 4.3 already supports auto. I think the Visual Studio 2010 preview supports auto. auto will make the code it's intended for more readable, more likely to be correct, and more maintenable:
    Code:
    // Doesn't need changing if the container type is changed, or c goes from non-const to const.
    for(auto it = c.begin(); it != c.end(); ++it) {}
    When abused, it will be confusing and make code harder to understand. But give me one feature for which this cannot be said.

    I also notice that C++ 0x has taken on C# and every other new OOP language's idea of one level of derivation.
    Huh? C++0x does no such thing. That would break pretty much every bit of C++ code out there, since the standard library itself uses multiple inheritance of concrete classes. (iostream derives both istream and ostream.)
    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

  7. #37
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,313
    Quote Originally Posted by Bubba
    Besides I doubt we get a fully 0x compiler for quite some time.
    Yes, though MSVC10 will include support for the new use of auto. Stroustrup also suggests that this be one of the first changes to the core language that should be implemented.

    Quote Originally Posted by Bubba
    I also notice that C++ 0x has taken on C# and every other new OOP language's idea of one level of derivation. Is this for concrete classes only or for abstract as well? In other words can a concrete class inherit from several abstract classes? I completely agree with not allowing multiple inheritance when it comes to concrete classes.
    This comes as a surprise to me, but I am not that well read concerning C++0x. Kindly elaborate
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #38
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I ran into this while designing a new system. A friend stated that MSVS 2008 does not allow multiple derivations and will either throw a warning or error if you attempt it. I absolutely do not know if this is true since I do not own any version of it. However most new C++ ish languages have disallowed multiple inheritance and I heard a rumor that 0x would follow suit and there is a blurb about it in the wiki.

    Also, note that there are restrictions for multiple inheritance, such that class constructors cannot be inherited from two classes that use constructors with the same signature. Nor can a constructor in the derived class exist that matches a signature in the inherited base class.
    It appears that my co-worker did not completely understand the restriction. Perhaps someone could comment on this further?

    When abused, it will be confusing and make code harder to understand. But give me one feature for which this cannot be said.
    Very true and well said.

    Huh? C++0x does no such thing. That would break pretty much every bit of C++ code out there, since the standard library itself uses multiple inheritance of concrete classes. (iostream derives both istream and ostream.)
    Which is a huge relief since this has major implications if it were true.
    Last edited by VirtualAce; 12-13-2008 at 11:52 AM.

  9. #39
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Your friend might be confusing C++0x with C++/CLI. The latter is a variant of C++ targeted at the .Net framework. Since the CLS doesn't allow multiple inheritance, any C++/CLI class that uses it is not portable to other CLI languages, and the compiler warns about this or throws an error, I don't know and don't care which.

    It appears that my co-worker did not completely understand the restriction. Perhaps someone could comment on this further?
    The restriction is about explicit inheritance of constructors, which is new in C++0x. Constructor inheritance means this:
    Code:
    struct A
    {
      A(int, int, int);
      A(std::string);
    };
    
    struct B
    {
      using A::A;
      // Equivalent to:
      B(int i1, int i2, int i3) : A(i1, i2, i3) {}
      B(std::string s) : A(s) {}
    };
    Now, the restriction blurb says that these two cases are invalid:
    Code:
    struct A
    {
      A(int);
      A(float);
    };
    
    struct B
    {
      B(int);
    };
    
    struct C : A, B
    {
      using A::A;
      using B::B; // Invalid: B(int) conflicts with inherited A(int)
      C(float); // Invalid: C(float) conflicts with inherited A(float)
    };
    Simple. Although, I'm not quite sure if these restrictions still apply. The first one is sensible, but the second one feels like a great restriction.
    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. #40
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Quote Originally Posted by Bubba View Post
    Besides I doubt we get a fully 0x compiler for quite some time.
    Perhaps it will be less that we think...
    Compiler vendors previously did not want to implement newer things in the standard because they might be burned if the implementations changed.
    Today, however, they are scrambling to implement everything that has been standardized.
    Visual Studio 10 supports auto, lambdas and parallel libraries already. Probably more when it is finally shipped.
    GCC supports variadic templates, among other features.
    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.

  11. #41
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    GCC supports variadic templates, among other features.
    Different patches are being developed to provide for most of the good stuff. They just haven't merged the various patches into a coherent unit.

    Static Assertions + Variable Templates + RV References + Automatic Types = Happy Fruit! ^_^

    Soma

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

Similar Threads

  1. Boost Auto-Linking
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 12-30-2007, 06:11 AM
  2. Boost Serialization: shared_ptr
    By KessiMC in forum C++ Programming
    Replies: 0
    Last Post: 12-26-2007, 08:17 PM
  3. Replies: 2
    Last Post: 12-12-2007, 06:45 AM
  4. building boost iostreams
    By l2u in forum C++ Programming
    Replies: 3
    Last Post: 04-14-2007, 03:29 PM
  5. Integrating Boost with STLPort
    By Mario F. in forum Tech Board
    Replies: 1
    Last Post: 11-11-2006, 06:49 AM

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