Hi Paul,
On Wed, Jan 7, 2009 at 10:06 PM, Paul Martz pma...@skew-matrix.com wrote:
Your recommendation below seems like it would depend on what type fxn()
returns, am I correct?
For example, if fxn() returns an int (and 'a' is declared as an int), then
the following is correct:
if ( (a
Hi All,
On Thu, Jan 8, 2009 at 9:57 AM, Robert Osfield robert.osfi...@gmail.com wrote:
My current feeling is that we should try to suppress this and a few of
the other misleading warnings via compile options rather that
#pragma's in the headers. So if we have /W4 on then we should then
Hi Robert,
I'm sorry to come late in the discussion, but I did not understand why you say
the assignment within conditional expression warning (C4706 under MSVC) is
useless. I know it is correct C/C++ to write if (a=b), but haven't you ever
typed a=b instead if a==b in a if statement? It
Hi Sukender,
On Thu, Jan 8, 2009 at 11:28 AM, Sukender suky0...@free.fr wrote:
I'm sorry to come late in the discussion, but I did not understand why you
say the assignment within conditional expression warning (C4706 under MSVC)
is useless. I know it is correct C/C++ to write if (a=b), but
Mmmh... I understand. The fact is that in every company I worked, the
affectation in a if was simply forbidden... when not strongly discouraged.
Anyway, the only thing important is to be aware of such things... (after paying
attention to the algorithm errors, as you say, of course!)
Sukender
Hi Sukender,
On Thu, Jan 8, 2009 at 12:28 PM, Sukender suky0...@free.fr wrote:
Mmmh... I understand. The fact is that in every company I worked, the
affectation in a if was simply forbidden... when not strongly
discouraged. Anyway, the only thing important is to be aware of such
things...
Robert Osfield wrote:
Hi Sukender,
Code readability is key to spotting algorithm
errors, so any slip in readability is something to take very seriously
which is why the !=0 is not what I would deem a good programming
practice.
But I find that the '!= 0' produces far more readable code,
Hi Robert,
C++ certainly gives you lots of rope to hang yourself with
Agreed! One of my favorite sentences is With the C language, you can easily
shoot yourself in the foot. The main benefit with C++ is that when you shoot
yourself in the foot, you tear off your whole leg.
If companies
Hi,
Matthew Fuesz wrote:
Robert Osfield wrote:
Hi Sukender,
Code readability is key to spotting algorithm
errors, so any slip in readability is something to take very seriously
which is why the !=0 is not what I would deem a good programming
practice.
But I find that the '!= 0' produces
Hi Matthew and JP,
Well it's always a bad idea to write *many* things in a single line in C/C++. I
already saw things like tab[++x] = (y=z++), which could be dangerous. I even
saw a x = x++, which is an undefined behaviour (does not do the same
depending on the type of x, and depending on the
Hi Matthew,
On Thu, Jan 8, 2009 at 1:22 PM, Matthew Fuesz matthew.fu...@lmco.com wrote:
But I find that the '!= 0' produces far more readable code, when the
convention is consistently adhered to.
In *your* opinion. My opinion is less readable. For the projects you
are responsible feel
Hi J.P.
On Thu, Jan 8, 2009 at 1:36 PM, J.P. Delport jpdelp...@csir.co.za wrote:
Of course, what is - IMO - the _absolutely_ most readable is to split the
statement in two - i.e., a = b; if ( a ) {}
Well stated, I agree with everything you've said and second the split
statement approach.
Hi,
Robert Osfield wrote:
Hi J.P.
On Thu, Jan 8, 2009 at 1:36 PM, J.P. Delport jpdelp...@csir.co.za wrote:
Of course, what is - IMO - the _absolutely_ most readable is to split the
statement in two - i.e., a = b; if ( a ) {}
Well stated, I agree with everything you've said and second the
Hi,
Sukender wrote:
Hi Matthew and JP,
Well it's always a bad idea to write *many* things in a single line in C/C++. I already saw things
like tab[++x] = (y=z++), which could be dangerous. I even saw a x = x++,
which is an undefined behaviour (does not do the same depending on the type of x,
Robert Osfield wrote:
Following your logic we should also do:
if (bool_variable==true)
{
}
Rather than:
if (bool_variable)
{
}
Actually, no. No ambiguity of intent is present. Only when there arises a case
where both assignment or comparison operators are logical possibilities
HI Matthew,
On Thu, Jan 8, 2009 at 4:01 PM, Matthew Fuesz matthew.fu...@lmco.com wrote:
As to the more general discussion, it is very apparent that we will never
agree on anything in this matter, as we have *drastically* different views of
what constitutes the most readable code.
I'm happy
Hi JS et. al.,
I've now checked in a number of warning fixes, out of over 1000
warnings that should be removed (mainly repeats) I think just four
were actual bugs fixes, whilst they might be minor bugs it's still
nice to see them caught and hopefully fixed . The bulk left are
unused parameter
Hello Robert,
I've now checked in a number of warning fixes, out of over 1000
warnings that should be removed (mainly repeats) I think just four
were actual bugs fixes, whilst they might be minor bugs it's still
nice to see them caught and hopefully fixed . The bulk left are
unused parameter
Hi Jean,
On Wed, Jan 7, 2009 at 3:13 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
I just did an update and it doesn't seem you fixed the warning C4512:
'classname' : assignment operator could not be generated warning? That's
the most frequent... I'd like to see it fixed or
859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday, January 07, 2009 8:30 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Warning level
Hi Jean,
On Wed, Jan 7, 2009
Hi Paul,
On Wed, Jan 7, 2009 at 4:08 PM, Paul Martz pma...@skew-matrix.com wrote:
If I understand correctly from this discussion, the intended usage is that
developers will leave OSG_USE_AGGRESSIVE_WARNINGS set to the default ON, and
we'll then tackle any warnings on a case by case basis, is
Skylark (J-S) wrote:
I'm fine with suppressing C4706 as it's true that it's a warning that
only tells you that you *might* be doing something unsafe... Whether
it's actually safe or not is totally context-dependent.
Blanket-supression of C4706 isn't really a good thing, since as you
Hi Matthew,
On Wed, Jan 7, 2009 at 4:36 PM, Matthew Fuesz matthew.fu...@lmco.com wrote:
Blanket-supression of C4706 isn't really a good thing, since as you pointed
out, it can actually point out an error (usually a typo by the developer).
C4706 will not be generated if it is made explicitly
...@lists.openscenegraph.org] On Behalf Of Matthew
Fuesz
Sent: Wednesday, January 07, 2009 9:36 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Warning level
Skylark (J-S) wrote:
I'm fine with suppressing C4706 as it's true that it's a warning that
only tells you that you *might
Hi Robert, Matthew et al.,
IMHO, the !=0 syntax in a if statement is the most portable. I know if
((a=b)!=0) does not generate warning under MSVC and GCC. So I guess it would
be the same for if ( (a = fxn()) != 0 ). For my part, I always use the !=0
syntax... and I avoid as much as possible
Hi J-S,
On Mon, Jan 5, 2009 at 7:40 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
I can, but I would think you'd prefer to offload that tedious task to some
other developers (me in this case) since it can be pretty time consuming...
I suggest you let me have a bash at fixing
Hi Robert,
If you post the warnings I can have a quick look at them and make a
judgement call on the potential risk of associated code changes, if
it's low for a certain class of warning then having others dive in is
a help. Sometimes I have to change warning fixes for coding style as
well so
Hi JS,
On Tue, Jan 6, 2009 at 3:22 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
OK, I'm doing another build now and will send you the output when it
finishes. I still think you have better things to do, at least for 95% of
the warnings which will be trivial to fix and require
Hi J-S,
On Mon, Jan 5, 2009 at 2:56 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Just to be sure, this is a Windows-only path right? To be clear:
A) Did you set OSG_USE_AGGRESSIVE_WARNINGS to OFF on Windows but ON
everywhere else?
No. OSG_USE_AGRESSIVE_WARNINGS is ON on all
Hello Matthew,
/Wall enables *ALL* warnings, including those automatically supressed by VS under any other circumstances. /W1 through /W4 set the warning level; /Wall goes far beyond /W4 by enabling normally disabled warnings.
I'm not sure if /Wall ignores #pragma warning supression as well,
Hi Robert,
Could VS users please do an svn update and see how the build now fares?
I'll do this in a few minutes.
I've just done a full build in both debug and release, with /W4 only and
OSG_USE_AGGRESSIVE_WARNINGS set to ON. All built fine. There are a bunch
of warnings I could fix, but
J-S,
/W4 is generally sufficient. I run all of my projects at warning level 4, and
effectively treat warnings as errors for my purposes. I don't enable /WX on the
off chance that I get some crazy warning that I can't suppress and isn't
meaningful in my application. I know of several such
Hi J-S,
Chnaged CMakeLists.txt now merged and submitted to SVN.
On Mon, Jan 5, 2009 at 5:20 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
By the way, a bunch of the warnings I get are of the unreferenced formal
parameter variety. I thought GCC flagged those? For example:
Hi Robert,
Chnaged CMakeLists.txt now merged and submitted to SVN.
OK, thanks!
Can you just stick the warnings into a file and post this so I can
then do a review.
I can, but I would think you'd prefer to offload that tedious task to
some other developers (me in this case) since it can
Hi Robert,
I think option A is better, since then people who want to use more
aggressive warnings (and can accept the consequences) still have that
option. Option B simply makes the flag the same whether
OSG_USE_AGGRESSIVE_WARNINGS is ON or OFF, so the option has no use on
Windows...
Is -Wall
Hi Robert,
I agree with your rationale over warnings etc.
In this instance the Windows build is now broken due to aggressive
warnings
Well, it wasn't really broken, just building *really* slowly due to
thousands of warnings being printed (probably hundreds for each source
file, since
/Wall combined with any other /Wn option is redundant.
/Wall enables *ALL* warnings, including those automatically supressed by VS
under any other circumstances. /W1 through /W4 set the warning level; /Wall
goes far beyond /W4 by enabling normally disabled warnings.
I'm not sure if /Wall
Hi All,
I turned on the aggressive warnings by default following my warnings
purge. I can disable this, but doing so would allow users to post
code with warnings without realising it, then I or others have to go
and guess at what the appropriate warning fix would be which is the
danger of
Hi JS,
IMHO, MSVC's /W3 is already quite aggressive, but I already had to go to /W4
to find a few bugs. However, I agree that /W4 is very very very aggressive. I
guess the -Wall on gcc is roughly equivalent to /W3, and -Wall -pedantic
-all other that are not in Wall is roughly equivalent to
that OSG_USE_AGGRESSIVE_WARNINGS should be turned on
per default, because this is an opposite of what Robert want to have...
Cheers
art
--- Sukender suky0...@free.fr schrieb am Di, 30.12.2008:
Von: Sukender suky0...@free.fr
Betreff: Re: [osg-users] Warning level
An: OpenSceneGraph Users osg-users
, because this is an opposite of what Robert want to have...
Cheers
art
--- Sukender suky0...@free.fr schrieb am Di, 30.12.2008:
Von: Sukender suky0...@free.fr
Betreff: Re: [osg-users] Warning level
An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Datum: Dienstag, 30. Dezember 2008, 9
Hi all, hi Robert, hope you are all having a good holiday. :-)
I was just building after an svn update today and happened to delete
my CMakeCache.txt, and the new default setting for
OSG_USE_AGGRESSIVE_WARNINGS started taking effect. (it seems that my
old cache was overriding the value before)
/W4 on windows is far from useless, and can often point out some pretty big
mistakes that the VS compiler just happens to find a way to take care of for
you (outside of the C/C++ standard).
I haven't built a newer version of OSG - my projects here are still relegated
to running 2.6.0 for the
Just did some checking on OSG VS settings, and there are some differences in
the primary warning-supressing preprocessor options - once again, I'm not
running the current version or latest dev build, so this may have changed.
In OSG 2.6.0, the following are defined:
_SCL_SECURE_NO_WARNINGS
44 matches
Mail list logo
