 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
[Our version of] GCC seems to require a command-line switch to enable
C++11 support, so...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/05/2013 04:38 PM, Warp wrote:
> 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>;
> }
I had hoped it would "just work" the same way it does if it wasn't a
pointer. But it appears that no, you have to make it actually point to
something. (Which is reasonable.) The constructor seems like the most
sensible place to do that.
> Btw, C++98 does not support>> for closing a double template. You have
> to add a space in between.
Yeah, I already discovered that. ;-)
> 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.
Ooo, interesting... Yeah, that could work.
>>> (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.
Apparently ReSharper insists that every C# private field begins with an
underscore. I guess when the guys started writing C++, they just copied
that naming convention. After all, it's only a name, right? You can name
your stuff anything you li- oh, OK, maybe not...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Today, I spent about 2 hours trying to figure out why the hell all the
tests pass when I compile in Debug mode, but two of them fail if I
compile in Release mode.
Literally, every time I run in Debug mode, all the tests pass. It only
fails in Release mode. In particular, that means I can't fire up the
debugger to see why it's failing. You can only debug in Debug mode, and
in Debug mode it works perfectly.
Apparently Google is your friend. After some minimal amount of effort, I
came across a very well-written forum post which helpfully explains that
in Debug mode all variables are guaranteed to be initialised to default
values, whereas in Release mode variables take on whatever random
gibberish happens to be in memory, unless you remember to explicitly
initialise them to something sane.
Ouch. >_<
Now I guess I understand why Java, C#, et al make such a fuss about
insisting on explicit initialisation and / or explicitly specifying
default initialisation rules...
The other fun thing is that C++ allows you to "throw" absolutely
anything. Several places in the code throw std::string, presumably in
the hope that this will result in some helpful error message being printed.
It doesn't. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> [Our version of] GCC seems to require a command-line switch to enable
> C++11 support, so...
In other news, I may have found out why turning this on breaks GTest.
Apparently it's somehow related to a late change to the C++11 spec.
Basically VC doesn't support some feature that got added to the standard
late. (Varadic tuples or something.) That doesn't completely explain why
it compiles just fine without C++11 turned on though...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The OTHER fun thing, of course, is when you invoke a template with the
wrong parameters.
Trouble is, the compiler has no idea that the parameters are wrong. All
it knows is that when it tries to expand the template, somewhere several
million miles away from your code a type mismatch happens, or an
operator doesn't exist, or...
This would be acceptable if VC offered some how to find out WHAT
TEMPLATE it was attempting to expand when the error occurred. But no, it
just shows you the source code for the STL (or Boost or whatever) and
points at the line on which the problem was actually detected. There
seems to be no way that I can discover what line of which file resulting
in this template being invoked in the first place - and THAT is surely
where the problem is, not in STL itself.
(E.g., today I erroneously said set<string, string>. It took quite a
while to hunt through the source control history to manually inspect
every template instruction I've recently touched and thus discover the
problem. If I knew, say, WHAT FILE to look in, it might be faster...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
