Thread: kestion about boost

Originally Posted by c++0x

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).

Originally Posted by cyberfish

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.

Originally Posted by c++0x

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.

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';
}

Originally Posted by Bubba

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.

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.

Originally Posted by Bubba

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.)

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.

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

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.

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.

Originally Posted by Bubba

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.