POV-Ray : Newsgroups : povray.programming : cleaning source code from warnings troubles Server Time
28 Jul 2024 12:22:09 EDT (-0400)
  cleaning source code from warnings troubles (Message 44 to 53 of 53)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Christopher James Huff
Subject: Re: cleaning source code from warnings troubles
Date: 2 Oct 2002 15:46:40
Message: <chrishuff-7DF213.15434602102002@netplex.aussie.org>
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

From: Warp
Subject: Re: cleaning source code from warnings troubles
Date: 3 Oct 2002 06:58:00
Message: <3d9c22b8@news.povray.org>
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

From: Vadim Sytnikov
Subject: Re: cleaning source code from warnings troubles
Date: 3 Oct 2002 06:59:01
Message: <3d9c22f5$1@news.povray.org>
"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

From: Warp
Subject: Re: cleaning source code from warnings troubles
Date: 3 Oct 2002 07:00:38
Message: <3d9c2355@news.povray.org>
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

From: Christopher James Huff
Subject: Re: cleaning source code from warnings troubles
Date: 3 Oct 2002 19:47:10
Message: <chrishuff-A442C8.19434703102002@netplex.aussie.org>
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

From: Philippe Lhoste
Subject: Re: cleaning source code from warnings troubles
Date: 4 Oct 2002 07:06:09
Message: <Xns929D850D4AC5FPhiLho@204.213.191.226>
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

From: Vadim Sytnikov
Subject: Re: cleaning source code from warnings troubles
Date: 4 Oct 2002 07:31:10
Message: <3d9d7bfe$1@news.povray.org>
"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

From: Warp
Subject: Re: cleaning source code from warnings troubles
Date: 4 Oct 2002 07:47:43
Message: <3d9d7fdf@news.povray.org>
Christopher James Huff <chr### [at] maccom> wrote:
> 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)

  Yes, if you want a conglomeration of values (ie. a type which contains
several variables inside it), use struct instead of class.
  In these cases it's ok. However, if it would contain more than four or
five values, then you might want to think about abstracting it.

  A good(?) example of this usage is the 'pair' struct in the standard
library.

> 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. 

  I have sometimes wished this too. It would certainly be useful if you
could say "class A can access this private method of this class B, but
nothing else".
  I can imagine an easy syntax for this as well. Something like:

class B
{
 private:
    void foo() friend A;
};

  (If you want more than one class to have access to the method, you could
just list them separated with commas after the 'friend' keyword.)


>> > 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.

  I don't use it often, but sometimes it's handy. For example:

cout << "The switch 1 is " << (switch1 ? "on" : "off") << endl;

  I think that's quite readable, and less cluttered than:

cout << "The switch 1 is ";
if(switch1) cout << "on";
else cout << "off";
cout << endl;

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: Christopher James Huff
Subject: Re: cleaning source code from warnings troubles
Date: 4 Oct 2002 13:06:40
Message: <chrishuff-10D1AA.13015204102002@netplex.aussie.org>
In article <3d9d7fdf@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I have sometimes wished this too. It would certainly be useful if you
> could say "class A can access this private method of this class B, but
> nothing else".

It would be helpful in something similar to the MVC pattern. You could 
have classes that implement the objects but are not concerned with 
drawing them, and classes that have access to certain APIs that let them 
draw the objects, without exposing these APIs to everything else. Good 
for tightly related classes that don't have strong dependencies on each 
other. You could write OpenGL and DirectX versions of the viewer classes 
without ever touching or recompiling the model classes, just derive them 
from a class that has access. Hmm...this brings up the question of 
whether access should be inherited or not. I think it would make sense 
if it was.


> class B
> {
>  private:
>     void foo() friend A;
> };
> 
>   (If you want more than one class to have access to the method, you could
> just list them separated with commas after the 'friend' keyword.)

I'm not sure I like that...I think it muddles the meaning of "friend".
Maybe something like this, which seems to fit in with the other access 
labels:

class MyClass {
    exposeto SomeClass:
    ...declarations exposed to SomeClass...
    
    exposeto AnotherClass:
    ...declarations exposed to AnotherClass...

    exposeto SomeClass, AnotherClass:
    ...declarations exposed to SomeClass and AnotherClass...
    
    public:
    ...declarations exposed to all external code...
};

Maybe something like this too:
class MyClass {
    interface GeneralAPI access public {
        ...drawing API declarations...
    };
    interface DrawingAPI access Viewer {
        ...drawing API declarations...
    };
};

The first one has no functionality over a simple "public:" label, but 
helps document the code as having these functions be grouped together. 
The second one is similar, but only a specific list of classes has 
access to the API.


>   I don't use it often, but sometimes it's handy. For example:
> cout << "The switch 1 is " << (switch1 ? "on" : "off") << endl;

I would have to agree here...I've just never had to do that. I probably 
won't add this function to CSDL, though I might add a select() function. 
It could be done now:
function select(cond, ifTrue, ifFalse) {
    if(cond)
        return ifTrue;
    else
        return ifFalse;
};

Or eventually something like this, to handle any number of possiblities:
function select(cond) {return params[cond + 1];};

console.write("The switch 1 is ", select(switch1, "on", "off"), "\n");

Hmm...longer by a few characters, and maybe no more readable, but a C++ 
version:

template<typename T>
inline T select(bool cond, T ifTrue, T ifFalse)
{
    if(cond)
        return ifTrue;
    else
        return ifFalse;
}

cout << "The switch 1 is " << select(switch1, "on", "off") << endl;

Would it work? I always mess up on templates. It isn't quite the same as 
the Sapphire version, because the parameters and return value aren't 
passed by reference. "select(foo, a, b).SetSomething()" wouldn't work, 
because it would be calling SetSomething() on a copy. However, if 
references are used, 'select(switch1, "on", "off")" wouldn't work 
because the parameters are temporaries...pointers will work fine though:
select(foo, &a, &b)->SetSomething()
Should work.

Or:
char * modes[2] = {"off", "on"};//rewrite to use string class if you want
cout << "The switch 1 is " << modes[switch1] << endl;

The Sapphire equivalent (still working out the syntax):

def modes: ["off", "on"];
console.write("The switch 1 is ", modes[switch1], "\n");

Has the advantage of being easy to expand to more than 2 possiblities.

-- 
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

From: Warp
Subject: Re: cleaning source code from warnings troubles
Date: 4 Oct 2002 15:34:57
Message: <3d9ded61@news.povray.org>
Christopher James Huff <chr### [at] maccom> wrote:
> template<typename T>
> inline T select(bool cond, T ifTrue, T ifFalse)
[snip]

> Would it work?

  You need to make some different version of the template function in
order to to take into account all the possibilities.
  This works in all cases I tested:

#include <iostream>

template<typename T>
inline const T* Select(bool cond, const T* ifTrue, const T* ifFalse)
{
    if(cond) return ifTrue;
    else return ifFalse;
}

template<typename T>
inline T& Select(bool cond, T& ifTrue, T& ifFalse)
{
    if(cond) return ifTrue;
    else return ifFalse;
}

template<typename T>
inline const T& Select(bool cond, const T& ifTrue, const T& ifFalse)
{
    if(cond) return ifTrue;
    else return ifFalse;
}


int main()
{
    bool flag = true;
    char test[2][4] = { {'o', 'n', 0}, {'o', 'f', 'f', 0} };

    Select(flag, test[0], test[1])[0] = 'O';

    std::cout << "The flag is " << Select(flag, test[0], test[1]) << std::endl;
    std::cout << "The flag is " << Select(flag, "on", "off") << std::endl;
    std::cout << "The flag is " << Select(flag, 1, 0) << std::endl;

    int i = 0, j = 0;
    Select(flag, i, j) = 1;
    std::cout << "i=" << i << ", j=" << j << std::endl;

    return 0;
}


-- 
#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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.