>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>
> Oh, and it's probably best to write it like this:
>
> boost::shared_ptr<std::vector<Foo> > _foo(new std::vector<Foo>());
>
> Since some compilers will complain about using >> in a type definition
> (due to the ambiguity with the >> operator).

VisualStudio compiles this perfectly. GCC point-blank fails to compile 
it. *sigh* Gotta love the number of inconsistencies between two 
compilers for supposedly "the same" language...

(VC emits endless warnings about "printf may be unsafe; please use 
printf_s instead". Apparently the latter function doesn't exist in GCC...)

Post a reply to this message

>>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>>
>> Oh, and it's probably best to write it like this:
>>
>> boost::shared_ptr<std::vector<Foo> > _foo(new std::vector<Foo>());
>>
>> Since some compilers will complain about using >> in a type definition
>> (due to the ambiguity with the >> operator).
>
> VisualStudio compiles this perfectly. GCC point-blank fails to compile
> it. *sigh* Gotta love the number of inconsistencies between two
> compilers for supposedly "the same" language...

You are surprised that a Microsoft product allows something that is 
frowned upon by a more anal-retentive competitor?!?

>
> (VC emits endless warnings about "printf may be unsafe; please use
> printf_s instead". Apparently the latter function doesn't exist in GCC...)

They are MS-specific versions of the functions.

http://msdn.microsoft.com/en-us/library/8ef0s5kh%28v=vs.80%29.aspx
http://msdn.microsoft.com/en-us/library/239ffwa0%28v=vs.80%29.aspx

I'm sure the purists would frown that Microsoft decides to mess with 
<sdtio.h> instead of putting them in a "msstdio.h" or similar.  Way back 
when the dinosaurs still roamed the Earth, I used to hang in comp.lang.c 
and I vividly remember certain members being quite angry at Borland for 
pretending that conio.h was part of the standard headers and its 
functions part of the standard libraries.



-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 5/23/2013 6:27 AM, Francois Labreque wrote:

>>>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>>>
>>> Oh, and it's probably best to write it like this:
>>>
>>> boost::shared_ptr<std::vector<Foo> > _foo(new std::vector<Foo>());
>>>
>>> Since some compilers will complain about using >> in a type definition
>>> (due to the ambiguity with the >> operator).
>>
>> VisualStudio compiles this perfectly. GCC point-blank fails to compile
>> it. *sigh* Gotta love the number of inconsistencies between two
>> compilers for supposedly "the same" language...
>
> You are surprised that a Microsoft product allows something that is
> frowned upon by a more anal-retentive competitor?!?
>

Actually, I'm a little surprised that GCC didn't accept it, as that sort 
of things should be allowed under the C++11 standard 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html) and 
GCC 4.7 is listed as supporting that feature 
(http://gcc.gnu.org/gcc-4.7/cxx0x_status.html).  In general GCC seems to 
have much better C++11 support that MSVC, so it's strange to see an 
example of the opposite -- perhaps Andrew's using an old version of GCC 
or something.

Post a reply to this message

>>> boost::shared_ptr<std::vector<Foo> > _foo(new std::vector<Foo>());
>>>
>>> Since some compilers will complain about using >> in a type definition
>>> (due to the ambiguity with the >> operator).
>>
>> VisualStudio compiles this perfectly. GCC point-blank fails to compile
>> it. *sigh* Gotta love the number of inconsistencies between two
>> compilers for supposedly "the same" language...
>
> You are surprised that a Microsoft product allows something that is
> frowned upon by a more anal-retentive competitor?!?

boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());

I don't see how the >> is ambiguous at all in this statement. Seems to 
me like lazy/bad parser design if this trips it up.

Post a reply to this message

On 5/23/2013 7:14 AM, scott wrote:
>
> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>
> I don't see how the >> is ambiguous at all in this statement. Seems to
> me like lazy/bad parser design if this trips it up.
>

It's not quite so cut and dry as you might guess.  For example:


#include <iostream>
using std::cout;
using std::endl;

int _foo(int i) {
	return i;
}

namespace std {
	static const int vector = 7;
}

namespace boost {
	static const int shared_ptr = 5;
}

int main(int argc, char** argv) {
	int Foo = 3;
	cout << (boost::shared_ptr<std::vector<Foo>> _foo(NULL)) << endl;
	return 0;
}


If you run this program it should print "1" (at least in MSVC), which is 
the result of treating < and >> and the less-than and bit-shift 
operators.  Of course you couldn't write "new std::vector<Foo>()" in 
this scheme, but it does show that it's hard to tell what's a template 
and what's not at a purely syntatic level.

In any case, the C++11 standard does allow 
"boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>()); " and 
the most recent version of GCC supposedly supports this.  You can read a 
bit more about it here: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> > What do you mean by "field"? Your question is not clear enough.

> I mean something like

>    class Foobar
>    {
>      private:
>        boost::shared_ptr<std::vector<Foo>> foo;
>      public:
>        Foobar()
>    }

Why didn't you say so in the first place?

If you want to initialize that member function in the constructor, use
the constructor's initializer list or just assign to it in the contructor's
body. In the first case:

    Foobar::Foobar(): foo(new std::vector<Foo>)
    {}

Or if you prefer,

    Foobar::Foobar()
    {
        foo = new std::vector<Foo>;
    }

Btw, C++98 does not support >> for closing a double template. You have
to add a space in between.

I'm wondering why you are using a std::vector, though. I thought that what
you wanted was something like this:

//----------------------------------------------------------------

class Foobar
{
    struct Impl;
    boost::shared_ptr<Impl> impl;

 public:
    Foobar();
};
//----------------------------------------------------------------

In which case the implementation would be like:

//----------------------------------------------------------------
struct Foobar::Impl
{
    std::vector<Foo> array;
}

Foobar::Foobar(): impl(new Impl)
{}
//----------------------------------------------------------------

Much simpler and cleaner that way.

> > (And btw, don't start names with an underscore. Those are reserved for
> > the compiler.)

> Hoooookay... In that case, there's about 200 lines in the existing 
> codebase that need to be changed. o_O

I have never quite understood why so many programmers seem to be obsessed
with putting underscores at the beginning of names.

-- 
                                                          - Warp

Post a reply to this message

Kevin Wampler <nob### [at] nowherenet> wrote:
> On 5/21/2013 10:25 AM, Orchid Win7 v1 wrote:
> > However, I can't seem to figure out what to write in the constructor.
> > I've got a field that looks like
> >
> >    boost::shared_ptr<std::vector<Foo>> _foo;
> >
> > What do I need to do to initialise this correctly?

> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());

*Where* are you doing that?

If you mean it like this:

class Foobar
{
    boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
};

then it works, but only in C++11. I think Andrew needed to do it in C++98.

-- 
                                                          - Warp

Post a reply to this message

>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>>
>> I don't see how the >> is ambiguous at all in this statement. Seems to
>> me like lazy/bad parser design if this trips it up.
>
> It's not quite so cut and dry as you might guess.  For example:
...
>      cout << (boost::shared_ptr<std::vector<Foo>> _foo(NULL)) << endl;

Is that ambiguous?

Post a reply to this message

On 5/23/2013 8:58 AM, scott wrote:
>>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>>>
>>> I don't see how the >> is ambiguous at all in this statement. Seems to
>>> me like lazy/bad parser design if this trips it up.
>>
>> It's not quite so cut and dry as you might guess.  For example:
> ...
>>      cout << (boost::shared_ptr<std::vector<Foo>> _foo(NULL)) << endl;
>
> Is that ambiguous?
>


Obviously not since it compiles.  It is, however, ambiguous unless you 
know the types of boost::shared_ptr and std::vector (and you need to 
know them during lexical analysis).  I wasn't saying that it's 
impossible to correctly parse this sort of thing, just that correctly 
parsing it is a more non-trivial task than it might at first appear.

Post a reply to this message

On 5/23/2013 8:41 AM, Warp wrote:
> Kevin Wampler <nob### [at] nowherenet> wrote:
>> On 5/21/2013 10:25 AM, Orchid Win7 v1 wrote:
>>> However, I can't seem to figure out what to write in the constructor.
>>> I've got a field that looks like
>>>
>>>     boost::shared_ptr<std::vector<Foo>> _foo;
>>>
>>> What do I need to do to initialise this correctly?
>
>> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>
> *Where* are you doing that?
>

I was just giving him an example to point out that you pass a raw 
pointer to the constructor of shared_ptr and assuming that he'd figure 
the rest out from there.  But you're right that I perhaps should have 
been more explicit.

Post a reply to this message