Tuesday, November 8, 2016

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

bitrex <bitrex@de.lete.earthlink.net>: Nov 08 01:34PM -0500

I've read that contrary to popular belief, it's quite feasible to write
effective C++ code for small microprocessors without MMUs such as the
low-tier ARMs, and even AVR 8-bits with only say a couple kilobytes of
working memory.
 
That the code size for some constructs using say avr-g++ can actually
end up smaller than attempting to write something equivalent in straight
C, simply due to the more "expressive" syntax.
 
Clearly not all subsets of the language will be feasible to use on such
limited hardware, without a MMU dynamic memory allocation becomes much
more problematic, everything should be instantiated at execution (or at
least appropriate fixed-size buffers should be allocated), stuff like
unique_ptr and other allocation management features of C++11 and later
are certainly out, and the implementations I've seen of the STL for such
architectures are definitely not entirely C++11 compatible.
 
The performance hit of some types of template metaprogramming and
vtables of polymorphism is also a question.
 
My question is, what would you take from say C++11, and what would you
leave?
Popping mad <rainbow@colition.gov>: Nov 08 03:17AM

I want to make a parameter constant for a function that is not a memeber of a class
 
template <class outcost>
std::ostream& operator << ( std::ostream &output, state<outcost> const &p ) const
{
output << "nam => " << p.nam() << "\tcost=> " << p.r() << std::endl;
return output;
}
 
 
This fails
 
|| g++ -Wall -ggdb -c nodes.cpp
nodes.h|171 col 86| error: non-member function 'std::ostream& tree::operator<<(std::ostream&, const tree::state<outcost>&)' cannot have cv-qualifier
|| friend std::ostream& operator << ( std::ostream &output, state<outcost> const &p ) const ;
|| ^~~~~
 
 
If you remove const from the function is also fails..
 
 
 
 
 
 
template <class outcost>
std::ostream& operator << ( std::ostream &output, state<outcost> const &p )
{
output << "nam => " << p.nam() << "\tcost=> " << p.r() << std::endl;
return output;
}
 
:!make 2>&1| tee /tmp/vjvaPl4/171
g++ -Wall -ggdb -c nodes.cpp
g++ -Wall -ggdb -o fitch.o -c fitch.cpp
In file included from fitch.cpp:3:0:
nodes.h: In instantiation of 'std::ostream& tree::operator<<(std::ostream&, const tree::state<cost>&) [with outcost = int; std::ostream = std:
:basic_ostream<char>]':
nodes.h:158:16: required from 'tree::Pstates<cost>::Pstates(std::vector<tree::state<cost> >) [with cost = int]'
fitch.cpp:15:47: required from here
nodes.h:185:24: error: passing 'const tree::state<int>' as 'this' argument discards qualifiers [-fpermissive]
output << "nam => " << p.nam() << "\tcost=> " << p.r() << std::endl;
 
nodes.h:125:15: note: in call to 'std::__cxx11::string tree::state<cost>::nam() [with cost = int; std::__cxx11::string = std::__cxx11::basic
_string<char>]'
std::string nam(){return _nam;};
^~~
nodes.h:185:51: error: passing 'const tree::state<int>' as 'this' argument discards qualifiers [-fpermissive]
output << "nam => " << p.nam() << "\tcost=> " << p.r() << std::endl;
 
nodes.h:126:8: note: in call to 'cost tree::state<cost>::r() [with cost = int]'
 
 
There must be a way to do this.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 08 04:21AM +0100

On 08.11.2016 04:17, Popping mad wrote:
> output << "nam => " << p.nam() << "\tcost=> " << p.r() << std::endl;
> return output;
> }
 
That's the right approach except for the `const` after the function head.
 
The `const` on the formal argument is enough.
 
 
> || friend std::ostream& operator << ( std::ostream &output, state<outcost> const &p ) const ;
> || ^~~~~
 
> If you remove const from the function is also fails..
 
That's a different problem.
 
You need to make the `nam` member function `const`.
 
 
Cheers & hth.,
 
- Alf
ruben safir <ruben@mrbrklyn.com>: Nov 08 03:19AM -0500

On 11/07/2016 10:21 PM, Alf P. Steinbach wrote:
>> }
 
> That's the right approach except for the `const` after the function head.
 
> The `const` on the formal argument is enough.
 
 
that would be an error. You can't use a non-member function on a const
varriable, FWIW. There might not be a means to const this, as long as a
non-member function is working on the variable.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 08 03:48PM +0100

On 08.11.2016 09:19, ruben safir wrote:
 
> that would be an error. You can't use a non-member function on a const
> varriable, FWIW.
 
I'm sorry, but that doesn't make sense to me.
 
 
> There might not be a means to const this, as long as a
> non-member function is working on the variable.
 
Not sure what this means either, sorry.
 
 
Cheers & hth.,
 
- Alf
ruben safir <ruben@mrbrklyn.com>: Nov 08 11:22AM -0500

On 11/08/2016 09:48 AM, Alf P. Steinbach wrote:
 
>> that would be an error. You can't use a non-member function on a const
>> varriable, FWIW.
 
> I'm sorry, but that doesn't make sense to me.
 
A non-member function is one outside of the class.
 
>> There might not be a means to const this, as long as a
>> non-member function is working on the variable.
 
> Not sure what this means either, sorry.
 
Functions from outside of a class can not guarantee through const the
integrity of a function argument.
scott@slp53.sl.home (Scott Lurndal): Nov 08 04:31PM

>>> varriable, FWIW.
 
>> I'm sorry, but that doesn't make sense to me.
 
>A non-member function is one outside of the class.
 
So what? That doesn't preclude the function from using
const arguments, nor does it preclude the function from
using non-member const variables.
 
 
>> Not sure what this means either, sorry.
 
> Functions from outside of a class can not guarantee through const the
>integrity of a function argument.
 
c'est what?
 
static void function(const int& a)
{
a = 10; // ERROR
}
 
/tmp/a.cpp: In function 'void function(const int&)':
/tmp/a.cpp:4: error: assignment of read-only reference 'a'
ruben safir <ruben@mrbrklyn.com>: Nov 08 11:59AM -0500

On 11/08/2016 11:31 AM, Scott Lurndal wrote:
> So what? That doesn't preclude the function from using
> const arguments,
 
actually it does, at least as a parameter
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 08 05:34PM

On 08/11/2016 16:59, ruben safir wrote:
>> So what? That doesn't preclude the function from using
>> const arguments,
 
> actually it does, at least as a parameter
 
What? Either you are not explaining yourself properly or you are totally
wrong.
 
/Flibble
Popping mad <rainbow@colition.gov>: Nov 08 11:44AM

I have a series of data structures that I wanted to display information on using operator overloading for operator<< and it has proven to be impossible!!
 
why is it so broken
 
It can't even decide if a "string" is a *char or a something else and just bombs.
 
It is not usable.
Wouter van Ooijen <wouter@voti.nl>: Nov 08 05:49PM +0100

Op 08-Nov-16 om 12:44 PM schreef Popping mad:
 
> why is it so broken
 
> It can't even decide if a "string" is a *char or a something else and just bombs.
 
> It is not usable.
 
Which is in sharp contrast with your post, which constains a wealth of
details, so now we all know exactly what you exepected of operator<<,
what you observed, and what the cause is.
 
Thank you so much for including all the details!
 
Wouter "Objects? No Thanks!" van Ooijen
Popping mad <rainbow@colition.gov>: Nov 08 02:58AM

On Sun, 06 Nov 2016 23:25:17 -0800, Öö Tiib wrote:
 
 
 
> You lost me right here.
> Why operator is qualified as 'std::operator<<'? Do you want it to be in
> namespace 'std'? Why that operator is friend of 'tree::Pstates<cost>'?
 
I'm a bit perplexed as to why this is causing confusion since overloaded
stream operators are always nonmembers. This is a common problem.
 
 
 
Stream extraction and insertion
 
The overloads of operator>> and operator<< that take a std::istream& or
std::ostream& as the left hand argument are known as insertion and
extraction operators. Since they take the user-defined type as the right
argument (b in a@b), they must be implemented as non-members.
 
std::ostream& operator<<(std::ostream& os, const T& obj)
{
// write obj to stream
return os;
}
std::istream& operator>>(std::istream& is, T& obj)
{
// read obj from stream
if( /* T could not be constructed */ )
is.setstate(std::ios::failbit);
return is;
}
 
These operators are sometimes implemented as friend functions.
 
http://en.cppreference.com/w/cpp/language/operators
 
I don't want it to be in the std namespace, it IS in the std namespace.
Where am I confused here?
Popping mad <rainbow@colition.gov>: Nov 08 03:00AM

On Mon, 07 Nov 2016 12:35:37 -0800, Öö Tiib wrote:
 
 
> Yes but AFAIK we can't have friend functions from different namespaces.
 
is that a fact? I'm ignorant.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 08 04:12AM +0100

On 08.11.2016 03:58, Popping mad wrote:
 
> These operators are sometimes implemented as friend functions.
 
> http://en.cppreference.com/w/cpp/language/operators
 
> I don't want it to be in the std namespace, it IS in the std namespace.
 
The examples you show above are not in the `std` namespace.
 
 
> Where am I confused here?
 
Not sure.
 
The problem is that you're qualifying the operator, as `std::operator>>`.
 
 
Cheers & hth.,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Nov 08 05:16PM +0200

On 8.11.2016 4:58, Popping mad wrote:
 
> These operators are sometimes implemented as friend functions.
 
> http://en.cppreference.com/w/cpp/language/operators
 
> I don't want it to be in the std namespace, it IS in the std namespace.
 
Any function what you write will be in the namespace you put it in. For
example:
 
namespace Bwlchgwyn {
std::ostream& operator<<(std::ostream& os, const T& obj) {/*...*/}
}
 
This operator<< is in a namespace Bwlchgwyn. It's as simple as that.
 
 
> Where am I confused here?
 
Maybe you are confused by the fact that the function return type is
defined in the std namespace? Or maybe you are confused because
sometimes one needs to write specializations for templates defined in
the std namespace. Who knows!
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 07 09:12PM -0600

I am playing catchup on C++11 and 14 still.
 
Once upon a time it was preferred to write a function in which you were
returning a string, in form:
 
void GetString(std::string & out);
 
and it was argued that we did not want to write form:
 
std::string GetString();
 
in order to prevent the extra copy of the temporary that is the return
value.
 
With the introduction of Move Semantics, is this still the case?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 08 04:18AM +0100

On 08.11.2016 04:12, Christopher J. Pisz wrote:
 
> std::string GetString();
 
> in order to prevent the extra copy of the temporary that is the return
> value.
 
No, that was just some incompetent's advice.
 
Before optimizing, MEASURE.
 
Determine if any optimization is needed.
 
For optimization nearly always comes at some cost, such as the added
complexity of the purely procedural notation (it requires extra
variables, more statements, otherwise needless initializations, and so
on, and on).
 
After optimization, MEASURE: check if it actually improved things.
 
In C++03, where this advice could be made to sound plausible, you would
probably have found that the advice was plain wrong, due to factors such
as Return Value Optimization (in general) and COW strings (in g++).
 
 
> With the introduction of Move Semantics, is this still the case?
 
It was never the case, and it's even less the case now; all the standard
library containers are movable. :)
 
 
Cheers & hth.,
 
- Alf
Daniel <danielaparker@gmail.com>: Nov 07 07:21PM -0800

On Monday, November 7, 2016 at 10:12:17 PM UTC-5, Christopher J. Pisz wrote:
 
> in order to prevent the extra copy of the temporary that is the return
> value.
 
> With the introduction of Move Semantics, is this still the case?
 
Copy elision - a compiler optimization that eliminates unnecessary copying of objects - took care of that long before C++11.
 
Daniel
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 07 09:49PM -0600

On 11/7/2016 9:18 PM, Alf P. Steinbach wrote:
> library containers are movable. :)
 
> Cheers & hth.,
 
> - Alf
 
Well, sure, I have argued that the compiler will optimize it away, but
then there has been at least one peer who would argue to the death that
we should not depend on compiler optimizations in the way we code any
more than one would argue to not release memory "because Windows will
clean it up after the process exits"
 
Seemed like a good enough argument, at least a time. Better safe then
sorry after all.
 
When do you reckon we could say that all compilers optimized it away?
somewhere around 2000?
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 07 06:42PM -0600

On 11/6/2016 7:13 PM, JiiPee wrote:
> like in game programming: no printing done in Person class, some other
> function/class asks the values and prints. Obviously we dont want to
> have getters for Person necessary (because it would break OO-idea.).
 
 
Who is "they" and what are "thier" reasons for making such assertions?
I am reading alot about Domain Driven Design recently, and it, afaik,
argues the exact opposite.
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 07 06:51PM -0600

On 11/7/2016 6:42 PM, Christopher J. Pisz wrote:
 
> Who is "they" and what are "thier" reasons for making such assertions?
> I am reading alot about Domain Driven Design recently, and it, afaik,
> argues the exact opposite.
 
I take it back/clarify. Something like printing its values in a string
for logging might belong to the class...possibly... However, something
like generating a webpage that displays the values of the class would be
surely be somewhere else, like a view.
 
In the case that you are providing an ostream operation, it is most
likely for logging, in the real world. Even if your application was
command line only, I'd imagine there is some other component somewhere
for the "UI"
 
Also consider though, that if the data is private, it most likely isn't
meant to be displayed on a webpage and viewed. In your example there is
no method exposing the data for such a purpose. Making a friend and
exposing the private data is surely bad design. If Person wants
something to be seen, it will expose it, in its public methods, although
it might not expose it in such a manner that it is meant to generate
HTML and show a webpage or application tab.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 08 03:36AM +0100

On 07.11.2016 02:13, JiiPee wrote:
> They say, especially in game programming, that drawing/printing should
> not be done inside the class but some other class should do it (by
> asking the data from the object). Is this the way also with cout?
 
Yes.
 
 
> };
 
> If I want to create a print function which prints all persons details
> what is the best way to do it?
 
As a non-member.
 
E.g. this ensures that all the needed information is accessible to
calling code in general.
 
 
> Person(const string& name, int age, int id) :
> m_name{ name }, m_age{ age }, m_id{ id } {}
> void print(ostream& os) { os<<m_name<<", " << ....};
 
In spite of the name this is not a printing function: it's a function
that converts to string.
 
I think a far better design for this member would be
 
auto to_string() const
-> string
{ ...
 
In particular, when the class is used in a GUI the `<string>` header
will likely be included anyway, but not so `<iosfwd>` or `<iostram>`.
 
Also, standard iostreams are extremely inefficient, possibly due to the
locale stuff that is forced on you, and the modes, both of which makes
robust client code extremely complex in addition to inefficient.
 
 
> };
 
> But now the class is doing two things... printing and holding the data.
> they should be separated, isnt it?
 
No, it's not printing; it's just converting to string.
 
This is the #1 litmus test: can you use the class in various GUI frameworks?
 
If so then it's portable, OK in that respect.
 
But then, there is the #2 test, can you use the class in different
environments in general?
 
For example, since you're involving a stream it may be that the code
will depend on an UTF-8 locale having been imbued in that stream. Then
use the code in Windows and there's no such. Uh oh.
 
 
> like in game programming: no printing done in Person class, some other
> function/class asks the values and prints. Obviously we dont want to
> have getters for Person necessary (because it would break OO-idea.).
 
For conversion to string, try to express that more directly. This is
akin to generally using `++x` instead of `x++`. Don't ask for and
require way more than you actually need for the job.
 
Well, unless it's money, and the person paying is Donald Trump.
 
 
Cheers & hth.,
 
- Alf
Jerry Stuckle <jstucklex@attglobal.net>: Nov 07 10:19PM -0500

On 11/7/2016 9:36 PM, Alf P. Steinbach wrote:
> { ...
 
> In particular, when the class is used in a GUI the `<string>` header
> will likely be included anyway, but not so `<iosfwd>` or `<iostram>`.
 
The problem with this that to_string() generally is considered to
convert the entire object to a string. That's often desired for things
like debugging or even serialization, but not necessarily printing. You
might, for instance, want to print just the name and address, not the
birth date or phone number.
 
> Also, standard iostreams are extremely inefficient, possibly due to the
> locale stuff that is forced on you, and the modes, both of which makes
> robust client code extremely complex in addition to inefficient.
 
No arguments that they are inefficient. Part of that may be the locale
stuff, but they've always been inefficient, even before locales were
added. I think it's more due to the flexibility of the iostreams -
especially formatting options. The code is significantly more complex
than printf() formatting.
<snip>
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Chris M. Thomasson" <invalid@invalid.invalid>: Nov 07 05:15PM -0800

On 11/4/2016 7:48 AM, Mr Flibble wrote:
 
> typedef constrained_integer<age_tag, unsigned int, 0u, 150u> age;
> typedef constrained_integer<order_qty_tag, unsigned int, 0u, 150u>
> order_qty;
 
I personally like this method. Dare I say, +1?
 
;^)
"Chris M. Thomasson" <invalid@invalid.invalid>: Nov 07 04:42PM -0800

On 11/7/2016 3:28 AM, Rick C. Hodgin wrote:
> masquerading as aliens to deceive people so they'll believe
> the lie, remain unforgiven, and enter into Hell for all eternity
> upon their death.
 
IIRC, the Bible says that the first supernatural entities to visit
modern Earth are not good at all. This is why I was worried that you
would not be able to explain the event, simply because the Bible does
not specifically mention aliens. You would be in a catch 22.
 
 
 
> I believe it's schooling unaware to prepare nonbelievers for the
> deception that's coming over the whole Earth, so they will relate to
> and embrace the lie.
 
This is another worry of mine. If they do come here, and you are still
here, well, what about that rapture non-sense? IIRC, God's elect need to
be here during that time.
 
And, what about those hybrid Giants? Are they not intrusive alien
science experiments that God dislikes so much?
 
Ahhh, now you got be talking about the Bible as well!
 
YIKES.
 
;^/
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)