 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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] 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>;
> }
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 23/05/2013 19:33, Orchid Win7 v1 a écrit :
> 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. >_<
>
That's why options like -Wall -Wextra -pedantic -Wold-style-cast are my
friends with g++.
I do not know MSVC enough, but it might have that kind of warnings too
(on explicit demand, of course)
> 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. ;-)
with gdb, "catch throw" is wonderful before "run" in such cases.
Now, someone need to have an exploration of the standard exception
mechanism, as there is already a lot of derived types (and many allow a
string parameter which will be incorporated in the what() return)
--
Just because nobody complains does not mean all parachutes are perfect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> 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.
Initializing variables takes clock cycles, which is why C hackers don't
want them being initialized in situations where they are going to be
assigned to anyway... (As if this matters at all in 99.999% of the cases.)
Many compilers will analyze the code and give a warning about variables
being used uninitialized, but this analysis will always be inevitably
limited (because, as you may know, proving that eg. a variable is used
uninitialized is an improvable problem.)
There are some external tools that can be used to analyze the program
while it runs, and will detect things like this (as well as memory leaks
and accessing freed memory or out-of-bound accesses.) The only free one
I know of is valgrind. However, it only works on Linux and Mac OS X. No
such luck in Windows.
There are commercial programs that do the same (and more.) One that I know
of is AQtime.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> 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.
All compilers I know if will give you the full chain of calls that
ended up in the erroneous line. (And usually looking at the first error
message that refers to your code will immediately reveal the problem.)
I would be quite surprised if VC didn't do this.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24/05/2013 06:00 PM, Warp wrote:
> All compilers I know if will give you the full chain of calls that
> ended up in the erroneous line. (And usually looking at the first error
> message that refers to your code will immediately reveal the problem.)
>
> I would be quite surprised if VC didn't do this.
...which probably just means I need to go discover where in the UI this
information is hidden. It's probably quite simple once you know where to
look.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.>_<
>
> That's why options like -Wall -Wextra -pedantic -Wold-style-cast are my
> friends with g++.
>
> I do not know MSVC enough, but it might have that kind of warnings too
> (on explicit demand, of course)
I think MSVC actually *does* output warnings... It's just that every
time you compile the sources, it generates many hundred lines of
"stuff", and any warning messages are swamped by all the other output. I
think I've seen a warning or two flash past, but it would be quite
time-consuming to actually go read them all. (And most warnings are just
"printf is deprecated; please use printf_s instead".)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
