Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:

> ABX <abx### [at] abxartpl> wrote:
>   I also disagree with the idea that a compiler should not issue any
> warnings about code which is correct according to the C++ syntax
> definition. The fact that a piece of code is syntactically correct does
> not mean that it works ok. That's exactly what warnings are for: To
> inform you that the piece of code you just wrote might not work as you
> want. The warning might be irrelevant in some cases, but it still can be
> of great aid in many cases.

I agree. A simple case is the line:
  if (a = b)
It is perfectly legal in C, but at some warning level, the compiler howls...

And I agree with it. I may wanted to check if b is non-null, but most of the 
case, I just failed to type two equal signs.

If I want to do:
  if (f = Foo())
to check if Foo is not returning an error status, I should instead write:
  if ((f = Foo()) != 0)
which is uglier, but less prone to errors or ambiguity.

I know that some coders prefer to write:
  if (Foo() == f)
because if they forget an equal, an error will be thrown. But I don't like 
much this form, habits, you know?

BTW, I write now:
  f = Foo();
  if (f != 0)
which is more elegant, easier to read, and probably as efficient.
Some may object it wastes space (see the hot discussion about soft braces 
placement...) but I now prefer a nice layout to a compact one.
There was a time were I admired C's compactness (coming from Basic and 
Pascal worlds), but experience changed that :-)

BTW, removing warnings is not a futile task.
Lua programmers take careful steps to maintain strict ANSI C compliance, so 
their code is very portable. Sometime, when compiling with VC++, I get some 
warnings. Most of the time, they correct the code (mostly to add some 
explicit casts).
It allows:
- to insure no ambiguity (because of default rules) remains;
- to avoid inundating the poor programmer with a lot of harmless warnings, 
letting him miss the important ones...

Last note: you can't please everyone, including compilers.
Lua has the following function:
  static int io_exit (lua_State *L) {
    exit(luaL_opt_int(L, 1, EXIT_SUCCESS));
    return 0;  /* to avoid warnings */
  }
Well, VC++ issues a warning on the return line:
D:\Programmes\Langages\Lua\src\lib\liolib.c(565) : warning C4702: 
unreachable code
Both are right, of course. :-)
Note: the function must return an int because it is the signature of all Lua 
functions (called by the interpreter).

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

In article <3d9a4b7e@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I also disagree with the idea that a compiler should not issue any
> warnings about code which is correct according to the C++ syntax definition.

Well, if you don't read carefully you will of course continue to miss that I
am complaining about the default warnings.  Not about being able to enable
other warnings.  In fact, I made this clear early in this thread.

It is hard to argue if you either intentionally misunderstand what I say or
simply intentionally forget it.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <Xns### [at] 204213191226> , Philippe Lhoste 
<Phi### [at] GMXnet>  wrote:

> Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:
>
>>   I also disagree with the idea that a compiler should not issue any
>> warnings about code which is correct according to the C++ syntax
>> definition. The fact that a piece of code is syntactically correct does
>> not mean that it works ok. That's exactly what warnings are for: To
>> inform you that the piece of code you just wrote might not work as you
>> want. The warning might be irrelevant in some cases, but it still can be
>> of great aid in many cases.
>
> I agree.

Well, Warp intentionally misrepresented what I said in order to argue about
something else just for the sake of argument.  I never disagreed on the
point he makes, in fact I made very clear:

In article <3d8ed609$1@news.povray.org> , "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> Of course, setting the maximum warning level changes this rule (it should
> then warn about everything it can detect), but such a thing does not belong
> into the default warning set, but the all warning set (gcc and VC warn by
> default about this incorrectly).


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Philippe Lhoste <Phi### [at] GMXnet> wrote:

> I agree. A simple case is the line:
>   if (a = b)
> It is perfectly legal in C, but at some warning level, the compiler howls...
> 
> And I agree with it. I may wanted to check if b is non-null, but most of the 
> case, I just failed to type two equal signs.

And I usually avoid this kind of code. Sapphire doesn't allow it, and I 
probably won't add it.


> If I want to do:
>   if (f = Foo())
> to check if Foo is not returning an error status, I should instead write:
>   if ((f = Foo()) != 0)
> which is uglier, but less prone to errors or ambiguity.

I'm just too lazy to keep typing " != 0" or " != NULL"...it hasn't 
caused me trouble yet, but for reading I'd prefer it because of its 
unambiguity.


> I know that some coders prefer to write:
>   if (Foo() == f)
> because if they forget an equal, an error will be thrown. But I don't like 
> much this form, habits, you know?

Besides, it doesn't always work in C++...a function can return a 
reference.

myCam.Location() = blah;

is perfectly valid code. Not a good design in most cases, but valid.


> BTW, I write now:
>   f = Foo();
>   if (f != 0)
> which is more elegant, easier to read, and probably as efficient.
> Some may object it wastes space (see the hot discussion about soft braces 
> placement...) but I now prefer a nice layout to a compact one.

If f is used later, then yes. Otherwise the larger amount of code 
outweighs the clearer wording, in my opinion. "if(Foo() != 0)" or 
"if(Foo())" are clearer.


> There was a time were I admired C's compactness (coming from Basic and 
> Pascal worlds), but experience changed that :-)

Well...being excessively verbose is bad too. For example, I much prefer 
"{}" braces to a "begin...end" style, it is easier to recognize the 
symbols when mixed in with lots of other words and nicely short to type, 
but languages like Python which use white space to define blocks of code 
drive me nuts.
And I doubt anyone would prefer "add", "multiply", etc for 
operators...think of how huge simple expressions would get. However, I 
do prefer "and" and "or" to "&&" and "||". And I've never used the "?:" 
operator.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> myCam.Location() = blah;

> is perfectly valid code. Not a good design in most cases, but valid.

  Yes.
  The problem with that is that returning a non-const reference to a
member variable (which is of course private; if you see a member variable
anywhere else than in the private part, then dump that code, it's crap)
is against good OO coding practices, as it pretty much nullifies the whole
purpose of keeping it in the private part of the class.

  Reading and writing to that variable should be done eg. like this:

var = myCam.Location();

myCam.Location(newLocation);

  (The reason for this is left as homework... :) )

> And I've never used the "?:" operator.

  Why not? It's handy. :)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Philippe Lhoste" <Phi### [at] GMXnet> wrote:
> If I want to do:
>   if (f = Foo())
> to check if Foo is not returning an error status, I should instead write:
>   if ((f = Foo()) != 0)
> which is uglier, but less prone to errors or ambiguity.
>
> I know that some coders prefer to write:
>   if (Foo() == f)
> because if they forget an equal, an error will be thrown. But I don't like
> much this form, habits, you know?
>
> BTW, I write now:
>   f = Foo();
>   if (f != 0)
> which is more elegant, easier to read, and probably as efficient.

Yes, it is generally as efficient. And clear. I tend to use this form most
of the time as well...

BTW, there's one more way to express that same thing and not to cause any
warning messages:

if((f=Foo()))

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>>   I also disagree with the idea that a compiler should not issue any
>> warnings about code which is correct according to the C++ syntax definition.

> Well, if you don't read carefully you will of course continue to miss that I
> am complaining about the default warnings.  Not about being able to enable
> other warnings.  In fact, I made this clear early in this thread.

  Ok, I can admit this misunderstanding. However, it would be easier if
it was the *only* thing that you claimed. What I don't like is that you
call the compiler "broken" just because it has a default warning set which
you think should not be default, but behind a higher warning level option.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3d9c22b8@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   The problem with that is that returning a non-const reference to a
> member variable (which is of course private; if you see a member variable
> anywhere else than in the private part, then dump that code, it's crap)

Well, it is useful, but rarely. The only time I've ever used public 
variables is for the components in a 3D vector type, and a color type. 
My reasons: they are the only members, and are never going to change, 
and it makes code using these vectors a lot shorter and clearer. Speed 
isn't a factor, I expect any decent compiler to optimize the function 
calls away.
I do use "struct" instead of "class" to differentiate these...there is 
no real difference to the compiler other than default access level, but 
you will never see a class from me with a public variable. (unless it is 
something left over from debugging or some coding mistake)

Off the topic of this discussion, but another thing I've occasionally 
wished for was a way to specify specific methods as being exposed to 
objects of a class...friend classes are close, but are all-or-nothing. 
Sometimes there are two closely related classes that need to talk to 
each other, but the API between them doesn't need to be public and they 
don't need private access to each other. Maybe a way to group 
methods/data members into categories that can be exposed to specific 
classes. (category is a bad term, it is already used for something else 
in many OO languages and doesn't apply to C++, but I can't think of 
anything better)


> is against good OO coding practices, as it pretty much nullifies the whole
> purpose of keeping it in the private part of the class.
>   Reading and writing to that variable should be done eg. like this:

Exactly.


> > And I've never used the "?:" operator.
>   Why not? It's handy. :)

Never needed it. Expressions using it are much less readable IMO, and 
I've never had a situation where using if...else was significantly 
longer or more awkward.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
A44### [at] netplexaussieorg:

> In article <3d9c22b8@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
>> > And I've never used the "?:" operator.
>>   Why not? It's handy. :)
> 
> Never needed it. Expressions using it are much less readable IMO, and 
> I've never had a situation where using if...else was significantly 
> longer or more awkward.

printf("There is %d object%s\n", objNb, objNb > 1 ? "s" : "");

Alternatives: use two printf (may be better if you need to localize it, some 
languages may not use the same plural rules) or an intermediate variable.
I don't like much the "object(s)" syntax when I can avoid it. Even less the 
"1 objects" form...

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

"Philippe Lhoste" <Phi### [at] GMXnet> wrote:
>
> printf("There is %d object%s\n", objNb, objNb > 1 ? "s" : "");
>
> Alternatives: use two printf (may be better if you need to localize it,
some
> languages may not use the same plural rules) or an intermediate variable.
> I don't like much the "object(s)" syntax when I can avoid it. Even less
the
> "1 objects" form...

"Have no fear of perfection: you'll never reach it!" :-)

IMHO in this particular case two printf()s would be better than the
altogether correct

printf("There %s %d object%s\n", objNb > 1 ? "are" : "is", objNb, objNb > 1
? "s" : "");

BTW, can't there be no objects at all? ;-)

Follow-ups to povray.off-topic.

Post a reply to this message