Thursday, December 11, 2014

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

agent@drrob1.com: Dec 10 09:22PM -0500

On 10 Dec 2014 19:22:24 GMT, jt@toerring.de (Jens Thoms Toerring)
wrote:
 
 
>Without dpecifying how that's to be done make invokes the
>default C++ compiler (for .cpp files) with your CXXFLAGS.
 
> Regards, Jens
 
 
It's interesting that my makefile works anyway.
Ian Collins <ian-news@hotmail.com>: Dec 11 03:52PM +1300


>> Without dpecifying how that's to be done make invokes the
>> default C++ compiler (for .cpp files) with your CXXFLAGS.
 
> It's interesting that my makefile works anyway.
 
That's because (as Jens mentioned above) make is using its default rule
to make a .o from a .cpp. The only line doing anything is
 
rpnc : $(objects)
 
--
Ian Collins
ruben safir <ruben@mrbrklyn.com>: Dec 11 11:38AM -0500

JiiPee <no@notvalid.com>: Dec 11 04:33PM

I am creating these Point (x, y) and Size (width, height) classes.
Because they are pretty much the same thing I would like to re-use the
Point class. If I use typedef it works, but then Size would get x and y,
but I want width and height instead. I was thinking to use union. It
would do the job, the only small issue is then that Point also has them
(not a major issue for me though). Is there any other way to do this so
I could use width and height?
 
Is there any way to hide the width and height for point and x, y for Size?
 
I know I could use getters and setters, but I would rather not use it here.
 
template <class T>
class Point2D
{
public:
Point2D(const Point2D& point) = default;
// other functions
// ...
union
{
T x;
T width;
};
union
{
T y;
T height;
};
};
JiiPee <no@notvalid.com>: Dec 11 12:17AM

Sutter keeps saying that "never use public members, but instead
gettes/setters. Only if its a struct type bundling together data and no
functionality". So he seems to say never publics....
 
Lets see Point-class:
 
a)
class CPoint
{
public:
int x;
int y;
};
 
b)
class Point
{
public:
int& X() { return x; }
int& Y() { return y; }
private:
int x;
int y;
};
 
Now Point will have many member functions as well, thus according to
Sutter we should do b). But what would you guys prefer? On the one hand
Point is a very simple structure and we would rather like to make calls
like: pt.x rather than pt.X(). But on the other hand having X() would
make it easier to debug plus we can later add more stuff inside getter
if needed, for example:
 
class Point
{
public:
int& X()
{
++xCallCount;
return x;
}
int& Y() { return y; }
private:
int x;
int y;
int xCallCount = 0;
};
 
(to know how many times x has been called).
But seems to me that most library implementators prefer 1) version, even
Microsoft.
 
So a poll: how many or you chose a) and how man b)??
JiiPee <no@notvalid.com>: Dec 11 12:18AM

Ups.... was meant to say "No public member variables".
Ian Collins <ian-news@hotmail.com>: Dec 11 01:24PM +1300

JiiPee wrote:
> But seems to me that most library implementators prefer 1) version, even
> Microsoft.
 
> So a poll: how many or you chose a) and how man b)??
 
I prefer c: If it's a POD, use public members, if not only expose const
members.
 
--
Ian Collins
Christopher Pisz <nospam@notanaddress.com>: Dec 10 06:29PM -0600

On 12/10/2014 6:17 PM, JiiPee wrote:
 
> (to know how many times x has been called).
> But seems to me that most library implementators prefer 1) version, even
> Microsoft.
 
I figure 1) Carry over from C 2) Lazy 3)They don't care
Microsoft breaks so many rules, that I would never ever cite them as an
example of how to code, not even with the languages they made up themselves.
 
> So a poll: how many or you chose a) and how man b)??
 
You only mentioned "functionality" as the determining factor, but I'd
make the decision based on whether there exists any method that would
mutate the class data.
 
If I've got
 
struct Point
{
Point(int x, y)
int GetArea();
 
int m_x;
int m_y;
}
 
I'd go with struct and public
 
If I wanted to add void ShrinkBy(int amount, bool heightOrWidth)
I'd go with protected/private and class.
Ian Collins <ian-news@hotmail.com>: Dec 11 01:33PM +1300

Christopher Pisz wrote:
> {
> Point(int x, y)
> int GetArea();
 
I assume you meant to write
 
int GetArea() const;
 
 
--
Ian Collins
JiiPee <no@notvalid.com>: Dec 11 12:35AM

On 11/12/2014 00:24, Ian Collins wrote:
 
>> So a poll: how many or you chose a) and how man b)??
 
> I prefer c: If it's a POD, use public members, if not only expose
> const members.
 
Because Point needs many member functions, thus you would do then X().
 
Many professionals do public members though. For example famous SFML
graphics library does:
 
class Rect <cid:part1.07010403.04050503@notvalid.com>
{
public:
... many functions
// Member data
T left <cid:part2.04090608.04020102@notvalid.com>;
T top <cid:part3.09010201.08000807@notvalid.com>;
T width <cid:part4.09000604.04050100@notvalid.com>;
T height <cid:part5.02030302.09060600@notvalid.com>;
};
 
And Visual Studio also doing it.
JiiPee <no@notvalid.com>: Dec 11 12:35AM

On 11/12/2014 00:35, JiiPee wrote:
> T height <cid:part5.02030302.09060600@notvalid.com>;
> };
 
> And Visual Studio also doing it.
 
Do you think they are wrong by doing this?
JiiPee <no@notvalid.com>: Dec 11 12:40AM

On 11/12/2014 00:29, Christopher Pisz wrote:
 
> I'd go with struct and public
 
> If I wanted to add void ShrinkBy(int amount, bool heightOrWidth)
> I'd go with protected/private and class.
 
Ok, but how about the issues of being able to debug x and y, plus being
able later on extend the class? You don't see them problems? Am actually
thinking about this as I need to create Rect and Point to my library :).
But I do not really like to write pt.X(). Its just pain it the code. And
pt.x looks even better. But true, pt.X() has its benefits....
Ian Collins <ian-news@hotmail.com>: Dec 11 01:43PM +1300

JiiPee wrote:
 
>>> I prefer c: If it's a POD, use public members, if not only expose
>>> const members.
 
>> Because Point needs many member functions, thus you would do then X().
 
In my case:
 
int x() const;
 
I doubt I'd ever return a public member by reference, that's no
different to having a public member.
 
I agree with what Christopher Pisz wrote and I would extend my original
to include classes with const qualified member functions.
 
>> };
 
>> And Visual Studio also doing it.
 
> Do you think they are wrong by doing this?
 
If they have non-const member functions, yes.
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Dec 11 01:46PM +1300

Ian Collins wrote:
 
> int x() const;
 
> I doubt I'd ever return a public member by reference, that's no
> different to having a public member.
 
I doubt I'd ever return a *private* member by reference
--
Ian Collins
JiiPee <no@notvalid.com>: Dec 11 12:47AM

On 11/12/2014 00:43, Ian Collins wrote:
 
>>> Because Point needs many member functions, thus you would do then X().
 
> In my case:
 
> int x() const;
 
yes true, thats better, even looks better. And member could be: int m_x;
 
 
> I doubt I'd ever return a public member by reference, that's no
> different to having a public member.
 
But it would still have 2 benefits: 1) can be debugged, 2) can add code
inside getters. So I would not say its no different, but you could say
its not essentially different.
JiiPee <no@notvalid.com>: Dec 11 12:48AM

On 11/12/2014 00:46, Ian Collins wrote:
 
>> I doubt I'd ever return a public member by reference, that's no
>> different to having a public member.
 
> I doubt I'd ever return a *private* member by reference
 
Sutter suggested that that would be better than putting member variable
public. Its doing the same job plus the 2 things I mentioned.
JiiPee <no@notvalid.com>: Dec 11 12:55AM

On 11/12/2014 00:48, JiiPee wrote:
 
>> I doubt I'd ever return a *private* member by reference
 
> Sutter suggested that that would be better than putting member
> variable public. Its doing the same job plus the 2 things I mentioned.
 
So far all libraries I have checked (3-4) use public x and y. For
example b2Vec2 in physics library Box2D also doing it. So seems like
putting them public seems to be prefered among library makers
Ian Collins <ian-news@hotmail.com>: Dec 11 02:11PM +1300

JiiPee wrote:
 
> But it would still have 2 benefits: 1) can be debugged, 2) can add code
> inside getters. So I would not say its no different, but you could say
> its not essentially different.
 
Care to explain "can be debugged"?
 
--
Ian Collins
JiiPee <no@notvalid.com>: Dec 11 01:21AM

On 11/12/2014 01:11, Ian Collins wrote:
>> inside getters. So I would not say its no different, but you could say
>> its not essentially different.
 
> Care to explain "can be debugged"?
 
void Point::setX(int x)
{
m_x = x;
}
 
Lets say we have a very large code and we know that the problem is that
some line is setting x to zero (we cannot divide by zero). We do not
know who set it to 0. But we can put a code temporary inside:
 
void Point::setX(int x)
{
if(x == 0)
cout<<"error";
m_x = x;
}
 
Now, we cannot do the same if we set m_x as a public member variable.
Ian Collins <ian-news@hotmail.com>: Dec 11 02:26PM +1300

JiiPee wrote:
> {
> m_x = x;
> }
 
That isn't a getter...
 
--
Ian Collins
Paavo Helde <myfirstname@osa.pri.ee>: Dec 11 01:04AM -0600


> Lets say we have a very large code and we know that the problem is
> that some line is setting x to zero (we cannot divide by zero). We do
> not know who set it to 0.
 
Debugging can be done with a public variable as well, just set up a data
breakpoint on the needed memory address, with a suitable condition.
 
In general, public variables can be used if there are no constraints or
class invariants. With a point class, this would mean that x and y are
independent and can take any values. If zero values are prohibited, this
is already an invariant and instead of a public variable there should be
getters and setters which assert the invariant. Or alternatively, instead
of the plain int the public member variables could be of a user-defined
class like NonZeroInt, which have their own assignment and conversion
operators checking this invariant.
 
For libraries, it is also important to make the usage as simple as
possible, and to avoid any suspicions (unfounded or not) that there might
appear performance problems. So I am not surprised they are using public
members.
 
Cheers
Paavo
JiiPee <no@notvalid.com>: Dec 11 08:09AM

On 11/12/2014 07:04, Paavo Helde wrote:
>> not know who set it to 0.
> Debugging can be done with a public variable as well, just set up a data
> breakpoint on the needed memory address, with a suitable condition.
 
oh, I have never done that myself. I ll have to check that...So why
Sutter and guys then say debugging is easier with functions?Surely they
know what you said...
But lets say you want to print/log to a file also something when x==0,
that would not be possible I guess? For that we would need the setX
-function.
 
"In general, public variables can be used if there are no constraints or
class invariants. With a point class, this would mean that x and y are
independent and can take any values. If zero values are prohibited, this
is already an invariant and instead of a public variable there should be
getters and setters which assert the invariant. Or alternatively,
instead of the plain int the public member variables could be of a
user-defined class like NonZeroInt, which have their own assignment and
conversion operators checking this invariant. For libraries, it is also
important to make the usage as simple as possible, and to avoid any
suspicions (unfounded or not) that there might appear performance
problems. So I am not surprised they are using public members."
 
This makes sense, and I am also taking that route to putting them as
publics. I guess one has to find a balance when to do it and when
not.... plus I do not think there is any definite truth here. Its a bit
a matter of taste as well I guess. But if most of the professionals use
in libs publics here, then I guess its good to follow them...they all
have been thinking about this and did their desisions.
Christopher Pisz <nospam@notanaddress.com>: Dec 11 10:03AM -0600

On 12/10/2014 6:40 PM, JiiPee wrote:
> thinking about this as I need to create Rect and Point to my library :).
> But I do not really like to write pt.X(). Its just pain it the code. And
> pt.x looks even better. But true, pt.X() has its benefits....
 
Debugging x and y is part of what led me to my decision. If there are no
public mutators then there is only one way that m_x and m_y could be
changed after the Point is constructed. So I can either search for .m_x=
and m_x =, or if I have a fancy debugger just tell it to stop when the
contents of the address where m_x lives are changed.
 
On the other hand, If I had made it a class than I break inside the
mutators.
 
As far as extension. If there is a good chance Point is going to be
extended then I make it a class to begin with. I suppose that relies on
some information about the project I am writing the Point for. When I
ask myself, "is this a candidate for being a POD?" the need to extend it
come into play.
 
But to me, this kind of thing isn't a huge decision with the handy dandy
find and replace features of most IDEs, it is simple enough to change
the struct to a class later if need be and change .m_x= and .m_x = to .SetX(
Belloc <jabelloc@gmail.com>: Dec 11 03:33AM -0800

On Wednesday, December 10, 2014 8:45:53 PM UTC-2, Paavo Helde wrote:
> here I am not quite sure.
 
> hth
> Paavo
 
I was struggling with the word "suppressed", as stated in the Standard. But it finally clicked after I read your response. And the reason seems to be so obvious, that I was missing the correct interpretation. In summary, when the Standard says:
 
"A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function. For an ordinary function call, the postfix expression shall be either an lvalue that refers to a function (in which case the function-to-pointer standard conversion (4.3) is suppressed on the postfix expression), or it shall have pointer to function type."
 
it is referring to a function name (postfix expression) followed by parenthesis, that is, a normal function call. In this case, obviously you don't need the function-to-pointer conversion and it should be suppressed, as stated. In §4.3/1 you'll find:
 
"An lvalue of function type T can be converted to a prvalue of type pointer to T."
 
where the lvalue of function type T is just the postfix expression corresponding to the function name. It doesn't include the parenthesis!
 
Thanks for your help Paavo.
Lynn McGuire <lmc@winsim.com>: Dec 10 08:15PM -0600

"Five Popular Myths about C++, Part 1" By Bjarne Stroustrup
http://isocpp.org/blog/2014/12/myths-1
 
"In this three-part series, I will explore, and debunk, five popular myths about C++:"
1. "To understand C++, you must first learn C"
2. "C++ is an Object-Oriented Language"
3. "For reliable software, you need Garbage Collection"
4. "For efficiency, you must write low-level code"
5. "C++ is for large, complicated, programs only"
 
Nice!
 
Lynn
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)