comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* hash_map and unordered map - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c9f1495ba9d6d1c5?hl=en
* Returning a class instance by value and a naming question - 10 messages, 6
authors
http://groups.google.com/group/comp.lang.c++/t/914a6523b571b0a9?hl=en
* Good way to write integer overflow checks? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/1363de0ff88836cd?hl=en
* including files best practice - 11 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/t/5558ad8b3f50bf41?hl=en
* Available C++ Libraries FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1caaa278cbb03e87?hl=en
==============================================================================
TOPIC: hash_map and unordered map
http://groups.google.com/group/comp.lang.c++/t/c9f1495ba9d6d1c5?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Nov 13 2013 9:17 am
From: Paavo Helde
jashan4235@gmail.com wrote in
news:5c7409af-cc6b-489c-8762-6ab4da754633@googlegroups.com:
>I atcually want to know what is the latest implementation of
> hash_map??
You should use std::unordered_map which comes with your C++ compiler.
Cheers
Paavo
== 2 of 2 ==
Date: Wed, Nov 13 2013 12:20 pm
From: Jorgen Grahn
On Wed, 2013-11-13, Paavo Helde wrote:
> jashan4235@gmail.com wrote in
> news:5c7409af-cc6b-489c-8762-6ab4da754633@googlegroups.com:
>
>>I atcually want to know what is the latest implementation of
>> hash_map??
>
> You should use std::unordered_map which comes with your C++ compiler.
Different answer: the latest version of hash_map is probably from the
mid-1990s when HP and SGI fiddled with it. I doubt anyone else made
any important changes to it.
People used hash_map as a faster but non-standard alternative to
std::map over the decades, until it was finally standardized in a
slightly different form called first std::tr1::unordered_map, and then
in C++11 std::unordered_map.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Returning a class instance by value and a naming question
http://groups.google.com/group/comp.lang.c++/t/914a6523b571b0a9?hl=en
==============================================================================
== 1 of 10 ==
Date: Wed, Nov 13 2013 3:09 pm
From: DSF
Hello,
I have a class I've been writing where I frequently need to return
the class by value so that class members can be changed without
affecting the original. The problem is all of the copying. First,
the class has to be copied into a local instance of the class. Then,
upon return, the local instance is copied into an unnamed instance
that's created before the function is called, and therefore not
destroyed when the function ends. Finally, after the function ends,
the operator= of the target is called, yet again copying the class
(unnamed). Here is an example:
FStringW FStringW::Start(size_t end) const
{
FStringW tfs(*this);
if(end < length)
{
tfs.str[end] = 0;
tfs.length = end;
}
tfs.StartIP(end);
return tfs;
}
StartIP is a member function that alters the string in place.
It returns 'end' number of characters of the start of a wide string.
I tried creating a "global" temp that could be used in place of each
function that used 'tfs'. It was a pointer to FStringW that was
created in each constructor and deleted in the destructor. I managed
to avoid an infinite loop in the constructor, but didn't realize it
created one in the destructor, too. I wasn't able to get around that
one. All the functions that returned FStringW returned a reference to
the global object, so the reference had the lifetime of until another
function uses it. That was acceptable. It would have eliminated one
copy if it worked.
So the question is: Are there any techniques for minimizing the
number of copies that occur when returning by value?
The ideal situation would be if the returned object could become the
unnamed object that's passed to operator=. But I think the compiler
would have to do that. And there's always the chance the function
could return an expression i.e. return tfs1 + tfs2.
My second question relates to the naming of member functions. Most
string-altering functions I've written have two versions, one that
returns by value and leaves the original alone, and one that alters
the string in place. For now, I'm using:
FStringW FStringW::Start(size_t end);
void FStringW::StartIP(size_t end);
But I was thinking maybe something like:
FStringW FStringW::GetStringStart(size_t end);
void FStringW::StringStart(size_t end);
Something like Crop or Cut StringEnd is more descriptive, but uses
start and end as terms for functions that do very similar things. Any
Ideas?
Thanks.
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 2 of 10 ==
Date: Wed, Nov 13 2013 4:17 pm
From: Jorgen Grahn
On Wed, 2013-11-13, DSF wrote:
> Hello,
>
> I have a class I've been writing where I frequently need to return
> the class by value so that class members can be changed without
> affecting the original. The problem is all of the copying.
[...]
Are you saying that doing it the naive, straightforward way causes
performance problems in your application? Because otherwise I'd stop
worrying and just do it that way.
(I'm asking because I myself have an unfortunate tendency to
micro-optimise things, so perhaps others do, too.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 3 of 10 ==
Date: Wed, Nov 13 2013 4:31 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
DSF <notavalid@address.here> writes:
> I have a class I've been writing where I frequently need to return
>the class by value so that class members can be changed without
>affecting the original.
What you return is called »an instance of the class«
or »an object of the class«. It's not the class.
>upon return, the local instance is copied into an unnamed instance
Return values are rvalues, they are moved, not copied.
> So the question is: Are there any techniques for minimizing the
>number of copies that occur when returning by value?
Move members (move constructors and move assignements) are
already generated by the compiler, unless you defined one of
them or copy members or destructors.
I think, you just have to take care to mark non-obvious
rvalues with ::std::move and to have handles to resources
as members (not large members).
== 4 of 10 ==
Date: Wed, Nov 13 2013 10:49 pm
From: Paavo Helde
DSF <notavalid@address.here> wrote in
news:g9g789tnbu5lfsjal0pqg6clcpervqqmth@4ax.com:
> Hello,
>
> I have a class I've been writing where I frequently need to return
> the class by value so that class members can be changed without
> affecting the original. The problem is all of the copying.
How do you know? Have you profiled the code and seen this is a
bottleneck?
> First,
> the class has to be copied into a local instance of the class. Then,
> upon return, the local instance is copied into an unnamed instance
> that's created before the function is called, and therefore not
> destroyed when the function ends. Finally, after the function ends,
> the operator= of the target is called, yet again copying the class
> (unnamed). Here is an example:
>
> FStringW FStringW::Start(size_t end) const
> {
> FStringW tfs(*this);
> if(end < length)
> {
> tfs.str[end] = 0;
> tfs.length = end;
> }
> tfs.StartIP(end);
> return tfs;
> }
>
> StartIP is a member function that alters the string in place.
>
> It returns 'end' number of characters of the start of a wide string.
>
> I tried creating a "global" temp that could be used in place of each
> function that used 'tfs'.
Whatever you do, don't do this. Global (non-const) variables are evil,
they complicate the data flow, make the optimizations harder and will
create lots of troubles in recursive functions or if you ever want to go
multithreaded.
> It was a pointer to FStringW that was
> created in each constructor and deleted in the destructor. I managed
> to avoid an infinite loop in the constructor, but didn't realize it
> created one in the destructor, too. I wasn't able to get around that
> one. All the functions that returned FStringW returned a reference to
> the global object, so the reference had the lifetime of until another
> function uses it. That was acceptable. It would have eliminated one
> copy if it worked.
>
> So the question is: Are there any techniques for minimizing the
> number of copies that occur when returning by value?
This is mostly a job for the optimizer. In your example, the return value
optimization (RVO) might be used by the compiler, eliminating one copy
without any work from your part.
Writing simple and straightforward code often helps the optimizer to do
its work better.
If the profiler still tells you that there is a bottleneck in copy, then
you have to do something about it. One way would be to keep unchanging
parts of the object in shared use, by adding some reference counters and
so on, but this may also cause troubles in multithreading and is actually
not guaranteed to speed things up.
A better way to increase performance is to review your algorithms. The
above method looks a lot like substr(), but still copies the whole string
even if only a tiny portion is going to be used later. It should allocate
space for and copy over only the needed amount of characters.
BTW, what is the reason you are using your own string class and not
something based on std::basic_string?
>
> The ideal situation would be if the returned object could become the
> unnamed object that's passed to operator=. But I think the compiler
> would have to do that. And there's always the chance the function
> could return an expression i.e. return tfs1 + tfs2.
> My second question relates to the naming of member functions. Most
> string-altering functions I've written have two versions, one that
> returns by value and leaves the original alone, and one that alters
> the string in place. For now, I'm using:
>
> FStringW FStringW::Start(size_t end);
> void FStringW::StartIP(size_t end);
The first one should be 'const', this also helps a bit to distinguish it.
For names, I have sometimes used a convention like Foo and ApplyFoo.
But in your example, naming the functions something like Left() and
Truncate() would be much better than Start() and StartIP() ;-) And even
better would be to get rid of your class and use std::wstring or
something else based on std::basic_string instead. Selecting good names
is important for shortening the learning curve of any reader (including
yourself in the future), with std::wstring the learning curve ought to be
zero.
hth
Paavo
== 5 of 10 ==
Date: Thurs, Nov 14 2013 5:44 am
From: "Alf P. Steinbach"
On 14.11.2013 00:09, DSF wrote:
>
> I have a class I've been writing where I frequently need to return
> the class by value so that class members can be changed without
> affecting the original. The problem is all of the copying. First,
> the class has to be copied into a local instance of the class. Then,
> upon return, the local instance is copied into an unnamed instance
> that's created before the function is called, and therefore not
> destroyed when the function ends. Finally, after the function ends,
> the operator= of the target is called, yet again copying the class
> (unnamed).
Most of that copying is eliminated by the compiler.
However, for a simple and naively implemented string or array the
compiler can't get rid of the underlying O(n) element copying, since for
such a class that's the definition of the operation.
The programmer, in control of the class design, can do far better.
In your case, returning and assigning a leftmost substring, the whole
thing -- substring operation, returning, assignment -- can be done
in constant time, O(k) (also known as O(1)), and a very efficient
constant time at that, mainly[1] at the cost of making conversion to
zero-terminated string for the worst case an O(n) operation.
However, I gather you're doing this exercise for learning, and in that
case the O(k) design and implementation may be beyond your current level
of expertise, too hard to tackle. So don't fret about it. But it's worth
knowing that it's THERE, that it's obtainable, and that it's therefore
something to aim for (later) and something to compare against.
What you CAN do right now is to MEASURE.
MEASURE.
And compare to measurement of roughly the same when using e.g. std::string.
If things are too slow you can then, among other things, try to
implement a C++ "move constructor". Or a C++03 equivalent. Just ask
here, but do measure first!
Cheers, & hth.,
- Alf
Notes:
[1] Another possible cost is that the strings then become immutable. But
I see that mainly as an advantage, not a cost. It certainly both speeds
up and simplifies things, in general.
== 6 of 10 ==
Date: Thurs, Nov 14 2013 4:45 pm
From: DSF
On 14 Nov 2013 00:31:03 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:
Please read *all* my answers before replying. (Or at least the last
one. It explains the context of my answers.)
>DSF <notavalid@address.here> writes:
>> I have a class I've been writing where I frequently need to return
>>the class by value so that class members can be changed without
>>affecting the original.
>
> What you return is called »an instance of the class«
> or »an object of the class«. It's not the class.
I used the term "instance" everywhere else, no need to nit pick.
>>upon return, the local instance is copied into an unnamed instance
>
> Return values are rvalues, they are moved, not copied.
That's an issue of semantics. A copy followed by a delete is often
called a move, but there's still a copy involved.
Return by value:
Copy local object to unnamed object created before function call.
Call local object's destructor.
Return from function.
Copy unnamed object to target.
Call unnamed object's destructor.
Call it two "moves," but there's still two copies made.
>
>> So the question is: Are there any techniques for minimizing the
>>number of copies that occur when returning by value?
>
> Move members (move constructors and move assignements) are
> already generated by the compiler, unless you defined one of
> them or copy members or destructors.
I've never heard of a "Move Constructor." A "Copy Constructor,"
yes. Same with assignments.
> I think, you just have to take care to mark non-obvious
> rvalues with ::std::move and to have handles to resources
> as members (not large members).
What would be a "non-obvious rvalue"?
I looked up std::move. I see it's new to C++11. This probably
applies to your two previous answers.
Usenet text can convey the wrong attitude, so please take this in
the friendly manor it's meant. If you are dealing with relatively new
terms, state their context. As in:
In C++11, return values are rvalues, they are moved, not copied.
And please do not assume that everyone is using the latest
technology.
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 7 of 10 ==
Date: Thurs, Nov 14 2013 5:34 pm
From: DSF
On 14 Nov 2013 00:17:25 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:
>On Wed, 2013-11-13, DSF wrote:
>> Hello,
>>
>> I have a class I've been writing where I frequently need to return
>> the class by value so that class members can be changed without
>> affecting the original. The problem is all of the copying.
>[...]
>
>Are you saying that doing it the naive, straightforward way causes
>performance problems in your application? Because otherwise I'd stop
>worrying and just do it that way.
I assume you meant "native?" It fits into the sentence better than
"naive."
>
>(I'm asking because I myself have an unfortunate tendency to
>micro-optimise things, so perhaps others do, too.)
>
>/Jorgen
I was raised (programming-wise) at a time when every byte and every
clock cycle counted. So I tend to still operate that way, whether
it's necessary or not.
In this case, if I had an array of 100,000 FStringWs that needed one
of my string manipulations done to each member and saved in another
array, it would be faster to duplicate the entire array and then use
the "in place" version on each of the destination elements. Which
leads me to consider if I even need the versions that return by value.
One can always create an instance of a class if one doesn't want to
alter the original. Typing aloud here (Same as thinking aloud) we
would have:
FStringW fs1, fs2;
fs1 = L"I don't want to be changed";
fs2 = fs1;
fs2.StartIP(18);
Vs.
FStringW fs1, fs2;
fs1 = L"I don't want to be changed";
fs2 = fs1.Start(18);
Not counting the initial assignment to fs1, the first example copies
the string once, the second example copies the string three times.
I set up a timed loop for each of the two examples. The first
example averaged three times faster than the second.
I'm leaning toward eliminating the functions that return FStringW by
value. Creating a copy and altering it is much faster, even if it
does require a little more typing.
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 8 of 10 ==
Date: Thurs, Nov 14 2013 6:44 pm
From: Ian Collins
DSF wrote:
> On 14 Nov 2013 00:31:03 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
> wrote:
>>
>> Return values are rvalues, they are moved, not copied.
>
> That's an issue of semantics. A copy followed by a delete is often
> called a move, but there's still a copy involved.
> Return by value:
> Copy local object to unnamed object created before function call.
> Call local object's destructor.
> Return from function.
> Copy unnamed object to target.
> Call unnamed object's destructor.
>
> Call it two "moves," but there's still two copies made.
Are you familiar with the concept of Return Value Optimisation? If not,
look it up. In most situations, what you think may be an expensive
operation, such as returning a container by value, isn't.
--
Ian Collins
== 9 of 10 ==
Date: Thurs, Nov 14 2013 9:27 pm
From: DSF
On Thu, 14 Nov 2013 00:49:11 -0600, Paavo Helde
<myfirstname@osa.pri.ee> wrote:
>DSF <notavalid@address.here> wrote in
>news:g9g789tnbu5lfsjal0pqg6clcpervqqmth@4ax.com:
>
>> Hello,
>>
>> I have a class I've been writing where I frequently need to return
>> the class by value so that class members can be changed without
>> affecting the original. The problem is all of the copying.
>
>How do you know? Have you profiled the code and seen this is a
>bottleneck?
Making a copy of the original string object and altering the copy
takes on third the time of the return by value method. The majority
of my coding involves string manipulation, so it will make a
difference. (See my response to Jorgen Grahn for details.)
{snipped my example}
>>
>> I tried creating a "global" temp that could be used in place of each
>> function that used 'tfs'.
>
>Whatever you do, don't do this. Global (non-const) variables are evil,
>they complicate the data flow, make the optimizations harder and will
>create lots of troubles in recursive functions or if you ever want to go
>multithreaded.
In the first place *nothing* in C/C++ programming is evil! Arguably,
the worst that C/C++ has(had) to offer was gets(). And I wouldn't
call it evil. Poor design? Yes. Written that way because perhaps
back at that time an 80-column terminal also had a one line input
limit? Maybe. Could be interesting research if I have some time
sometime.
Note that "global" is in quotations. It wasn't literally a global,
it was merely a class member so it would persist when member function
Start (or any other return by value function) returned. It would be
"global" storage for return by value functions for that particular
instance of the class that would persist until another RBV function is
called.
One could think of class member variables as local to the class but
global to all its members. One thing I like about C++ is that one can
have variables common to a group of functions without having to pass
them around all of the time or make them global.
I had written a database in C, and while there was nothing wrong
with it. I disliked the fact that I had to pass a pointer to a
structure to almost every function. So I re-wrote it in C++ and the
structure's members became members of the class. Quite a few of the
functions no longer required any parameters.
As far as recursive code goes, C++ shines with it as well. My
database had two recursive functions. Each of them required some data
to be available at any depth. In C, those had to be globals. In C++,
they became members of the class, allowing more than one instance of
the database in a program. I maintained both versions for a while,
but found myself "forgetting" to update the C version more and more
often until I stopped.
A directory-traversing class for Windows I've written uses the same
method and takes it one step further. If it encounters a mount point,
It creates an instance of the class and runs it with the mount point
as the starting directory, making the whole class recursive.
{More snipping}
>>
>> So the question is: Are there any techniques for minimizing the
>> number of copies that occur when returning by value?
>
>This is mostly a job for the optimizer. In your example, the return value
>optimization (RVO) might be used by the compiler, eliminating one copy
>without any work from your part.
My compiler is several thousand years old and does very little
optimization. (There's a post of mine in clc on just how literal it
is at producing assembly code that's very close to the C code that
generated it.)
>Writing simple and straightforward code often helps the optimizer to do
>its work better.
See above.
>If the profiler still tells you that there is a bottleneck in copy, then
>you have to do something about it. One way would be to keep unchanging
>parts of the object in shared use, by adding some reference counters and
>so on, but this may also cause troubles in multithreading and is actually
>not guaranteed to speed things up.
The bottleneck is not in the actual copying of the string, but
rather the number of times return by value needs to copy said string.
>A better way to increase performance is to review your algorithms. The
>above method looks a lot like substr(), but still copies the whole string
>even if only a tiny portion is going to be used later. It should allocate
>space for and copy over only the needed amount of characters.
Hmmmm. I don't seem to have a substr() function in my RTL. Must've
been added in the last 500 years or so. :o) The string class that
comes with the compiler (not part of the STL) does have a SubString
that takes a starting position and length.
>BTW, what is the reason you are using your own string class and not
>something based on std::basic_string?
I learn best by doing. I can read about how to do something over
and over and not get it, yet experiment with it and get the concept in
one or two attempts. My main interest is string manipulation, whilst
books concentrate on mathematical examples. So what better way to
learn the ins and outs of an object than to create a string class?
I've put a lot of time and energy into the string class and I'm
currently working on wrapping the 40 or so C string functions I've
written into the string class. As I mentioned in another posting in
this thread, making a copy of the string and performing the alteration
on the copy is ~three times faster than return by value. So I'm
seriously considering dropping the return by value versions and using
only the in place ones.
Oh! And when I started working on the string class, I hadn't heard
of the STL.
>>
>> The ideal situation would be if the returned object could become the
>> unnamed object that's passed to operator=. But I think the compiler
>> would have to do that. And there's always the chance the function
>> could return an expression i.e. return tfs1 + tfs2.
>
>> My second question relates to the naming of member functions. Most
>> string-altering functions I've written have two versions, one that
>> returns by value and leaves the original alone, and one that alters
>> the string in place. For now, I'm using:
>>
>> FStringW FStringW::Start(size_t end);
>> void FStringW::StartIP(size_t end);
>
>The first one should be 'const', this also helps a bit to distinguish it.
It actually is. No typing. Strictly C&P from the header file:
FStringW Start(size_t end) const;
>For names, I have sometimes used a convention like Foo and ApplyFoo.
>
>But in your example, naming the functions something like Left() and
>Truncate() would be much better than Start() and StartIP() ;-) And even
>better would be to get rid of your class and use std::wstring or
>something else based on std::basic_string instead. Selecting good names
>is important for shortening the learning curve of any reader (including
>yourself in the future), with std::wstring the learning curve ought to be
>zero.
Not much chance of me getting rid of my class. I've put too much
time and energy into it. Not to mention that doing so would require a
rewrite of every program I've written that I'm actively maintaining.
Interestingly, Start was originally called Left, but I changed it
because it sounded too "BASICy". Speaking of selecting good names, I
find quite a few of the names in the STL counterintuitive. You "add"
an item to a vector with "push_back." Why not "add"?
And speaking of "vector," is the definition of the word as it's used
here unique to C++ or programming languages in general? Every
definition I can find relates to the position of one object from
another based on the length of a line drawn between the two objects
and the angle of that line from a baseline drawn through the first
object.
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 10 of 10 ==
Date: Thurs, Nov 14 2013 10:55 pm
From: Paavo Helde
DSF <notavalid@address.here> wrote in
news:vv6b89p1ampg8sqggvu309hoi9oseabe3v@4ax.com:
> On Thu, 14 Nov 2013 00:49:11 -0600, Paavo Helde
> <myfirstname@osa.pri.ee> wrote:
>
> Note that "global" is in quotations. It wasn't literally a global,
> it was merely a class member so it would persist when member function
> Start (or any other return by value function) returned. It would be
> "global" storage for return by value functions for that particular
> instance of the class that would persist until another RBV function is
> called.
OK, maybe I misunderstood you. Still, this design seems a bit fragile and
complicated.
[snipping long praise to OOP]
> My compiler is several thousand years old and does very little
> optimization. (There's a post of mine in clc on just how literal it
> is at producing assembly code that's very close to the C code that
> generated it.)
So it seems it's last time to ditch it. I do not follow c.l.c so I don't
know the reasons you are sticking to it, but I hope they are good.
>>BTW, what is the reason you are using your own string class and not
>>something based on std::basic_string?
>
> I learn best by doing. I can read about how to do something over
> and over and not get it, yet experiment with it and get the concept in
> one or two attempts. My main interest is string manipulation, whilst
> books concentrate on mathematical examples. So what better way to
> learn the ins and outs of an object than to create a string class?
> I've put a lot of time and energy into the string class and I'm
> currently working on wrapping the 40 or so C string functions I've
> written into the string class. As I mentioned in another posting in
> this thread, making a copy of the string and performing the alteration
> on the copy is ~three times faster than return by value. So I'm
> seriously considering dropping the return by value versions and using
> only the in place ones.
>
> Oh! And when I started working on the string class, I hadn't heard
> of the STL.
So, are you learning how to write a string class, or how to write your
application? If the former, then you certainly should study the design of
std::basic_string. While the interface is monstrous, it actually provides
the functions you seem to need. An example: instead of your
FStringW a, b;
a = ...
b = a.Start(18); // many copies of the whole string and substring (?)
with standard C++ you could write:
std::wstring a, b;
a = ...
b.assign(a, 0, 18); // 1 copy of substring
This is a bit more verbose than return by value, but has the benefit that
no optimizing skills are required from the compiler.
The assign method is documented e.g. at
http://www.cplusplus.com/reference/string/basic_string/assign/
> Not much chance of me getting rid of my class. I've put too much
> time and energy into it. Not to mention that doing so would require a
> rewrite of every program I've written that I'm actively maintaining.
So add a proper assign() method to it and use that instead of assignment
(which requires temporary objects and a good optimizing compiler).
>
> Interestingly, Start was originally called Left, but I changed it
> because it sounded too "BASICy".
Oh, so your goal seems to obstruct the code ;-) There are many better
ways to do that in C++, for example, you could overload some operators
like + or - to return substrings - much more fun! But "Start" is a good
start, considering that nothing seems to be started here.
> Speaking of selecting good names, I
> find quite a few of the names in the STL counterintuitive. You "add"
> an item to a vector with "push_back." Why not "add"?
Because "add" is too vague. It could be easily minsinterpreted to add a
number to each element of the vector, for example.
>
> And speaking of "vector," is the definition of the word as it's used
> here unique to C++ or programming languages in general? Every
It's for programming in general.
> definition I can find relates to the position of one object from
> another based on the length of a line drawn between the two objects
> and the angle of that line from a baseline drawn through the first
> object.
This is the physics/math term. Basically, it's the same (once one has
invented Cartesian coordinates), only the number of dimensions is
typically much more in programming. But there are also e.g. Hilbert
spaces with infinite number of dimensions, meaning the vectors in such
space would have infinitely many elements.
There is also "vector of attack" which is a bit different again.
But are you aware that the word "string" has even more meanings? From
superstring theory in theoretical physics, to violins and underwear?
Cheers
Paavo
==============================================================================
TOPIC: Good way to write integer overflow checks?
http://groups.google.com/group/comp.lang.c++/t/1363de0ff88836cd?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Nov 14 2013 8:53 am
From: David Harmon
On Mon, 11 Nov 2013 18:47:23 +0000 in comp.lang.c++, Leigh Johnston
<leigh@i42.co.uk> wrote,
>The idiot "plink'd" you which is idiot-speak for blacklisting your
>posts. He has also "plink'd" me as the guy can't handle criticism.
A man's got to know his limitations.
-- Dirty Harry
>
== 2 of 2 ==
Date: Thurs, Nov 14 2013 10:41 pm
From: Öö Tiib
On Thursday, 14 November 2013 18:53:54 UTC+2, David Harmon wrote:
> On Mon, 11 Nov 2013 18:47:23 +0000 in comp.lang.c++, Leigh Johnston
> <leigh@i42.co.uk> wrote,
> >The idiot "plink'd" you which is idiot-speak for blacklisting your
> >posts. He has also "plink'd" me as the guy can't handle criticism.
>
> A man's got to know his limitations.
Got to know what he does not want to see and filter that out. Rational.
==============================================================================
TOPIC: including files best practice
http://groups.google.com/group/comp.lang.c++/t/5558ad8b3f50bf41?hl=en
==============================================================================
== 1 of 11 ==
Date: Thurs, Nov 14 2013 1:34 pm
From: ouroboros84
Please find here below a simple example. I know that a .hpp file has to include or forward declare everything it uses I wonder if it is best practice to include all .hpp files that are used in the .cpp file as well. I am asking this because I recently saw on a new project I am working on, that people tend to avoid including headers in a lot of cpp files.
In this case: is it good to include b.hpp in a.cpp? I know it has already been included by including a.hpp, but I personally feel that if a symbol appears in a .cpp, it should be included (or forward declared if possible)
a.hpp
#pragma once
#include "b.hpp"
class C; //forward declaration of C
class A
{
public:
B get_b();
private:
B _b;
C* _c;
};
a.cpp
#include "a.hpp"
//needed or I can leave it out, since B is included already in a.hpp?
#include "b.hpp"
B A::get_b()
{
return _b;
}
== 2 of 11 ==
Date: Thurs, Nov 14 2013 2:14 pm
From: Jorgen Grahn
On Thu, 2013-11-14, ouroboros84 wrote:
> Please find here below a simple example. I know that a .hpp file has
> to include or forward declare everything it uses
It doesn't /have to/ -- although it can be rather confusing if a file
which just says #include "foo.hpp" doesn't compile.
> I wonder if it is
> best practice to include all .hpp files that are used in the .cpp file
> as well. I am asking this because I recently saw on a new project I am
> working on, that people tend to avoid including headers in a lot of
> cpp files.
No, that's not best practice.
> In this case: is it good to include b.hpp in a.cpp? I know it has
> already been included by including a.hpp, but I personally feel that
> if a symbol appears in a .cpp, it should be included (or forward
> declared if possible)
My personal rule is this: if I have a pair foo.cpp/foo.hpp, I always
do a
#include "foo.hpp"
first in that cpp file. That's an automatic check that foo.hpp is
idempotent. Then you can do almost whatever you want and not end up
with a nasty effects like "I included foo.hpp from a new source file,
and had to spend half an hour finding out which other files I needed
to pull in first".
I try not to have a foo.hpp pull in a /lot/ of other headers which it
doesn't really need, but it's not a big disaster if it it pulls in a
few too many.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 3 of 11 ==
Date: Thurs, Nov 14 2013 2:27 pm
From: Victor Bazarov
On 11/14/2013 4:34 PM, ouroboros84 wrote:
> Please find here below a simple example. I know that a .hpp file has
to include or forward declare everything it uses I wonder if it is best
practice to include all .hpp files that are used in the .cpp file as
well. I am asking this because I recently saw on a new project I am
working on, that people tend to avoid including headers in a lot of cpp
files.
>
> In this case: is it good to include b.hpp in a.cpp? I know it has
already been included by including a.hpp, but I personally feel that if
a symbol appears in a .cpp, it should be included (or forward declared
if possible)
>
> a.hpp
>
> #pragma once
> #include "b.hpp"
>
> class C; //forward declaration of C
>
> class A
> {
> public:
> B get_b();
> private:
> B _b;
> C* _c;
> };
>
> a.cpp
>
> #include "a.hpp"
> //needed or I can leave it out, since B is included already in a.hpp?
> #include "b.hpp"
>
> B A::get_b()
> {
> return _b;
> }
>
I second this.
I would include it since 'B' type is used in a.cpp. Cannot (and should
not) rely on 'b.hpp' being pulled in by 'a.hpp'.
Of course, it's a style question, not a necessity. If it's pulled in
twice, it should contain the double inclusion guards, etc. And if it's
not included after somebody edits 'a.hpp' file, an attempt to compile
'a.cpp' will reveal that. But I still include all those things, myself.
V
--
I do not respond to top-posted replies, please don't ask
== 4 of 11 ==
Date: Thurs, Nov 14 2013 2:29 pm
From: ouroboros84
Il giorno giovedì 14 novembre 2013 23:14:02 UTC+1, Jorgen Grahn ha scritto:
> On Thu, 2013-11-14, ouroboros84 wrote:
>
>
> > I wonder if it is
>
> > best practice to include all .hpp files that are used in the .cpp file
>
> > as well. I am asking this because I recently saw on a new project I am
>
> > working on, that people tend to avoid including headers in a lot of
>
> > cpp files.
>
>
>
> No, that's not best practice.
>
>
>
Imagine though, if now in a.cpp you had this, as you suggest:
#include "a.hpp"
//#include "b.hpp" deleted
B A::get_b()
{
return _b;
}
namespace {
B b; //I can instanciate it
// even if I don't have the header
//thanks to an im[licit inclusion from a.hpp
C = b.get_c() //I can do it as well because a.hpp -> b.hpp -> c.hpp
}
wouldn't that cause problems? imagine if someone deleted c.hpp inclusion from b.hpp, using a forward declare for returning a reference instead of a value.
in that case a.cpp wouldn't compile anymore.
I prefer to be explicit in what I have to include in every class.
for example it is rare that you need to include a <string> header, but you basically do it every time you use a string.
== 5 of 11 ==
Date: Thurs, Nov 14 2013 2:33 pm
From: ouroboros84
Il giorno giovedì 14 novembre 2013 23:27:48 UTC+1, Victor Bazarov ha scritto:
> On 11/14/2013 4:34 PM, ouroboros84 wrote:
>
> > Please find here below a simple example. I know that a .hpp file has
>
> to include or forward declare everything it uses I wonder if it is best
>
> practice to include all .hpp files that are used in the .cpp file as
>
> well. I am asking this because I recently saw on a new project I am
>
> working on, that people tend to avoid including headers in a lot of cpp
>
> files.
>
> >
>
> > In this case: is it good to include b.hpp in a.cpp? I know it has
>
> already been included by including a.hpp, but I personally feel that if
>
> a symbol appears in a .cpp, it should be included (or forward declared
>
> if possible)
>
> >
>
> > a.hpp
>
> >
>
> > #pragma once
>
> > #include "b.hpp"
>
> >
>
> > class C; //forward declaration of C
>
> >
>
> > class A
>
> > {
>
> > public:
>
> > B get_b();
>
> > private:
>
> > B _b;
>
> > C* _c;
>
> > };
>
> >
>
> > a.cpp
>
> >
>
> > #include "a.hpp"
>
> > //needed or I can leave it out, since B is included already in a.hpp?
>
> > #include "b.hpp"
>
> >
>
> > B A::get_b()
>
> > {
>
> > return _b;
>
> > }
>
> >
>
>
>
> I second this.
>
>
>
> I would include it since 'B' type is used in a.cpp. Cannot (and should
>
> not) rely on 'b.hpp' being pulled in by 'a.hpp'.
>
>
>
> Of course, it's a style question, not a necessity. If it's pulled in
>
> twice, it should contain the double inclusion guards, etc. And if it's
>
> not included after somebody edits 'a.hpp' file, an attempt to compile
>
> 'a.cpp' will reveal that. But I still include all those things, myself.
>
>
>
> V
>
> --
>
> I do not respond to top-posted replies, please don't ask
thanks, I prefer to include them myself too. I was just wondering if there was a common agreement in the C++ commmunity, but as usual it seems there isn't one :-)
== 6 of 11 ==
Date: Thurs, Nov 14 2013 2:55 pm
From: Jorgen Grahn
On Thu, 2013-11-14, ouroboros84 wrote:
> Il giorno giovedì 14 novembre 2013 23:14:02 UTC+1, Jorgen Grahn ha scritto:
>> On Thu, 2013-11-14, ouroboros84 wrote:
>>
>>
>> > I wonder if it is
>>
>> > best practice to include all .hpp files that are used in the .cpp file
>>
>> > as well. I am asking this because I recently saw on a new project I am
>>
>> > working on, that people tend to avoid including headers in a lot of
>>
>> > cpp files.
>>
>>
>>
>> No, that's not best practice.
>
> Imagine though, if now in a.cpp you had this, as you suggest:
I'm not sure I suggested that. However ...
>
> #include "a.hpp"
> //#include "b.hpp" deleted
>
> B A::get_b()
> {
> return _b;
> }
>
> namespace {
> B b; //I can instanciate it
> // even if I don't have the header
> //thanks to an im[licit inclusion from a.hpp
> C = b.get_c() //I can do it as well because a.hpp -> b.hpp -> c.hpp
> }
> wouldn't that cause problems? imagine if someone deleted c.hpp
> inclusion from b.hpp, using a forward declare for returning a
> reference instead of a value. in that case a.cpp wouldn't compile
> anymore.
I have a hard time following your examples; I can't remember a c.hpp
in your first posting.
But anyway: ok, so someone removes an #include from some header file,
because it's not strictly needed there. And building something else
fails.
For me that's perfectly fine. I have all the sources; I can rearrange
them as needed. I myself was probably that someone who made the
change, a few seconds earlier -- because noone would change a header
file and commit without checking if it at least built!
I guess this means I'm assuming you're not developing isolated
components or libraries. Things are different and a lot harder if you
do. But (a) very few people need to do that, and (b) there are
several other worries you have in that case.
It /is/ a real problem for library writers and users though: many
times I've upgraded my compiler or standard library and had code stop
building, because #include <iostream> no longer pulls in <ostream>, or
something. I see no way around this.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 7 of 11 ==
Date: Thurs, Nov 14 2013 3:46 pm
From: "Alf P. Steinbach"
On 14.11.2013 22:34, ouroboros84 wrote:
[snip]
> a.cpp
>
> #include "a.hpp"
> //needed or I can leave it out, since B is included already in a.hpp?
> #include "b.hpp"
>
> B A::get_b()
> {
> return _b;
> }
In this case the full class B definition is not needed for class A's
public interface. So there is a possibility that class A will be changed
so that [b.hpp] is not needed for [a.hpp]. However, changing [a.hpp]
will usually be accompanied by a corresponding change of [a.cpp], so
there's problem with THIS file, whatever you decide.
The main problem is with client code. A programmer using [a.hpp] cannot
know whether [b.hpp] is guaranteed made available or is just present as
an implementation aspect that might be changed at any time. That's
because the complete class B definition is not needed for A's /public/
interface, only for its implementation, and so some optimization of
class A (e.g. for build time) might result in [b.hpp]'s removal.
So if I was concerned about this kind of problem then I would document
in some way whether [b.hpp] is present by design or as just an
implementation aspect.
* * *
In some cases you absolutely know that a header will be made available
by some other header. For example, a header that exposes something that
involves Windows API things will, as a rule, guaranteed include
<windows.h>. But that does not mean that client code can avoid including
<windows.h>. On the contrary, that Microsoft header, the "mother of all
headers", provides a set of declarations that depends strongly on
various macro symbols, plus that a great many of the declarations
themselves depend on various macro symbols. Thus to ensure consistent
declarations and a consistent set of declarations, it is a good idea to
include this header before including headers that depend on it. Other
3rd party headers may be similarly badly designed.
* * *
To ensure that headers are free-standing (that they're "idempotent")
it's a good idea to include each header at the top in /some/ [.cpp]
file. For header only modules I use a dummy [.cpp] file. E.g.,
[blahblah.h] is included by [blahblah.h.dummy.cpp], if it isn't included
by a real implementation file [blahblah.cpp].
With some toolsets (in particular Microsoft's) this necessitates turning
off librarian warnings about unused stuff.
Also note that this practice ties in with the previous section, ensuring
that those headers that need some H do include it.
* * *
Microsoft's precompiled header feature, which is on by default in a
Visual Studio project, can make incorrect code compile and can cause
errors with correct code. It's no big deal to adjust the code but it
means that code compiled with this feature may not necessarily work with
some other compiler. I do not know of any good solution.
Cheers & hth.,
- Alf
== 8 of 11 ==
Date: Thurs, Nov 14 2013 11:24 pm
From: Tobias Müller
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
> Microsoft's precompiled header feature, which is on by default in a
> Visual Studio project, can make incorrect code compile and can cause
> errors with correct code. It's no big deal to adjust the code but it
> means that code compiled with this feature may not necessarily work with
> some other compiler. I do not know of any good solution.
I know you are not reading my posts but maybe someone else can explain
that.
I always use precompiled headers and never had problems with them.
Given that they are set up correctly of course.
Tobi
== 9 of 11 ==
Date: Fri, Nov 15 2013 12:53 am
From: Paavo Helde
=?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin@bluewin.ch> wrote in
news:1507027537406192681.376648troplin-bluewin.ch@news.eternal-
september.org:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>> Microsoft's precompiled header feature, which is on by default in a
>> Visual Studio project, can make incorrect code compile and can cause
>> errors with correct code. It's no big deal to adjust the code but it
>> means that code compiled with this feature may not necessarily work with
>> some other compiler. I do not know of any good solution.
>
> I know you are not reading my posts but maybe someone else can explain
> that.
> I always use precompiled headers and never had problems with them.
> Given that they are set up correctly of course.
There is a bug in MSVC that any code before #include "precompiled.h" line
is ignored. For ignored #include lines they issue a warning, but other code
is ignored silently. I guess this is what Alf meant.
Cheers
Paavo
== 10 of 11 ==
Date: Fri, Nov 15 2013 2:14 am
From: Juha Nieminen
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> I try not to have a foo.hpp pull in a /lot/ of other headers which it
> doesn't really need, but it's not a big disaster if it it pulls in a
> few too many.
It's not a disaster, but in general one ought to minimize the number
of #includes (especially when they refer to files inside the same
project, rather than eg. system headers).
In small projects it's mostly inconsequential. However, the larger the
project, the more important it becomes to minimize the number of #include
lines. The more inter-dependency there is between source files and
header files, the longer the building process becomes even from very
small changes. If a change in one header file causes 5 source files to
be recompiled, that's a much nicer result than if it causes 50 source
files to be recompiled (especially when you are developing/debugging
the project and you are doing a lot of test builds frequently.)
Of course one shouldn't go overboard with this and start to make the
program more complex or inefficient just for the sake of avoiding a
few #includes, but in cases where it doesn't otherwise affect the
complexity or efficiency of the program, it's something to keep in mind.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 11 of 11 ==
Date: Fri, Nov 15 2013 4:59 am
From: "Alf P. Steinbach"
On 15.11.2013 09:53, Paavo Helde wrote:
> =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin@bluewin.ch> wrote in
> news:1507027537406192681.376648troplin-bluewin.ch@news.eternal-
> september.org:
>
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>>> Microsoft's precompiled header feature, which is on by default in a
>>> Visual Studio project, can make incorrect code compile and can cause
>>> errors with correct code. It's no big deal to adjust the code but it
>>> means that code compiled with this feature may not necessarily work with
>>> some other compiler. I do not know of any good solution.
>>
>> I know you are not reading my posts but maybe someone else can explain
>> that.
>> I always use precompiled headers and never had problems with them.
>> Given that they are set up correctly of course.
>
> There is a bug in MSVC that any code before #include "precompiled.h" line
> is ignored. For ignored #include lines they issue a warning, but other code
> is ignored silently. I guess this is what Alf meant.
Yep.
Thanks,
- Alf
==============================================================================
TOPIC: Available C++ Libraries FAQ
http://groups.google.com/group/comp.lang.c++/t/1caaa278cbb03e87?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Nov 14 2013 3:23 pm
From: Nikki Locke
Available C++ Libraries FAQ
URL: http://www.trumphurst.com/cpplibs/
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
Maintainer: Nikki Locke cpplibs@trumphurst.com
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment