Monday, December 29, 2014

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

"Chris M. Thomasson" <no@spam.invalid>: Dec 29 11:53AM -0800

> >> allocators or other such tricks.
 
> > That is far more complicated than a threadpool within the same process.
 
> But less vulnerable to bugs or malicious code..
 
Great point Ian. If a process dies in a multi-process system, it should not
shutdown the entire system. If you only have a single process comprising
the entire system, well, if a thread dies, the process should die. However,
if
you have multiple, multi-threaded processes, and a thread dies, only that
individual process dies, and you can usually do something about it.
 
So, IMVVHO, a clever mix of multiple processes with multiple threads per-
process, can be a decent solution indeed...
woodbrian77@gmail.com: Dec 29 02:12PM -0800

On Sunday, December 28, 2014 3:09:08 PM UTC-6, Ian Collins wrote:
 
> Which isn't an uncommon model.
 
> Web servers tend to run multiple processes, databases run multiple
> processes with shared memory.
 
That's my approach with my code generator. A web server is
a code generator basically so it makes sense to me to copy
that model.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): Dec 28 11:59PM

[Please do not mail me a copy of your followup]
 
arnuld <sunrise@invalid.address> spake the secret code
>some time on my hands to start C++. Well, I kept on peeking into
>stroustrup from time to time but now I see with C++14 everything has
>changed.
 
C++14 hardly changes "everything". You can view it mostly as a "minor
enhancement" to C++11.
 
If by "changes everything" you mean the changes introduced by C++11/14
compared to C++98, I'd still disagree with that statement. As far as
the core language is concerned, C++11/14 make it easier and less
problematic to write C++ code than C++98. Changes (as opposed to
additions) to the standard library weren't that significant IMO.
 
>Even in C++, I will allocate memory using /new/ and then free it
>using /delete/ but now I see Stroustrup does not seem to agree to that:
 
The only time new or delete (almost the lowest-level mechanism for
managing memory) should appear in your code is in a class designed to
manage the resource acquired by new and released by delete. Since the
standard library already provides two resource managing clases for
this purpose, std::unique_ptr and std::shared_ptr, there isn't any
reason you should be using new or delete directly in your code.
 
Furthermore, since most uses of new/delete have to do with creating
blocks of memory to hold collections of values and the standard
library provides container classes already, there is even less of a
need to use new/delete directly.
 
Need a variable-length buffer of characters to pass to some C style
function? Use std::vector<char>.
 
Need a string? Use std::string.
 
Need a dynamically resizable array of some other type T? Use
std::vector<T>.
 
Need a dictionary to look up values of type T from strings? Use
std::map<std::string, T>.
 
>concerned with simple procedural subset of C++:
 
> X* p = new X;
> X* q = p;
 
Well, this is poor form already. Who "owns" the instance of X? p or q?
 
If you had written:
 
X* p = new X;
X &q = *p;
// ...
delete p;
q.do_something(); // oops, still a problem.
 
Then your code would be revealing your intention instead of confusing
the reader. If we use scoping to limit the use of q to only where it
is intended, then we solve the "oops"
 
X* p = new X;
{
X &q = *p;
// ...
q.do_something();
}
delete p;
 
Now we've used scoping to explicitly reveal that q has a dependency on
p and that p's lifetime should extend beyond the lifetime of q.
However, we still have a problem if do_something() or anything else in
that block can throw an exception. If an exception is thrown, the
stack is unwound and we've leaked the memory pointed to by p.
 
I know this is only code you've written for the purposes of
discussion, but let's talk about another thing shown here. Is the use
of the heap really necessary? Why not write:
 
X p;
X &q = p;
 
...and then we don't have to worry about whether or not q can still be
used -- its lifetime is guaranteed to be shorter than p's lifetime.
We also don't need to worry about who is responsible for destroying p;
it's destroyed when we leave the scope of p. We also get code that is
exception safe.
 
We shouldn't use the heap unless it is really necessary.
 
So how do you get exception-safe use of the heap? First, make sure
you really need the heap (your toy example does not). Second, if you
really must use the heap, consider what you are trying to do with
dynamically allocated memory.
 
Are you trying to make a container? Use one of the standard library
container classes for that.
 
Are you trying to extend the lifetime of some data beyond the scope
of the code that creates it? Try std::unique_ptr.
 
Are you really trying to create shared data structures? Try
std::shared_ptr. (Note: shared data structures can lead to all kinds
of problems and I don't recommend blindly throwing shared_ptr at
everything. Most applications have very few required uses of shared
data, where the data must really be shared.
 
Use <http://cppreference.com> as your reference to the standard
library classes if you don't have a good book. I like Nicolai
Josuttis "The C++ Standard Library" myself.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Dec 29 12:01AM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>Personally I find that 99% of my resource management is done without
>any pointers or smart pointers.
 
Bingo. For me, it's more 9s than that :-), more like 99.99999%.
 
Once you start using the facilities that C++ has been giving you for
over a decade, all those stupid memory leak and pointer bugs just
disappear. Every time I hear someone complaining about memory leaks
or pointer bugs in C++, they keep showing me C code compiled with a
C++ compiler.
 
Please, just stop writing C code in C++!
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Lynn McGuire <lmc@winsim.com>: Dec 29 11:37AM -0600

On 12/26/2014 3:00 PM, Jorgen Grahn wrote:
> and some people need it frequently -- but you can do /a lot/ of
> programming without having to care about such things.
 
> /Jorgen
 
We use new and delete a lot in our base classes since we are memory constrained in the Win32 environment. We rarely use new or
delete in the descendent classes since they are so powerful.
 
Lynn
ram@zedat.fu-berlin.de (Stefan Ram): Dec 29 01:29AM

>terminates and leaves that character in the buffer. The next time cin
>tries to extract an int, it runs into the same "invalid" character.
>Repeat until bored.
 
#include <iostream>
#include <ostream>
#include <limits>
 
int main() { double x; bool ok; do
{ ::std::cout << "Number? ";
if( ok = ::std::cin >> x )::std::cout << x << '\n';
else
{ ::std::cout << "?REDO FROM START\n";
::std::cin.clear();
::std::cin.ignore
( ::std::numeric_limits< std::streamsize >::max(), '\n' ); }}
while( !ok ); }
ram@zedat.fu-berlin.de (Stefan Ram): Dec 29 05:13PM

>>tries to extract an int, it runs into the same "invalid" character.
>>Repeat until bored.
>if( ok = ::std::cin >> x )::std::cout << x << '\n';
 
»Reading input is often the messiest part of a program.«
 
Bjarne Stroustrup
 
»Output is easy, but input is filled with pitfalls that
await the unwary due to the gap between the actual and
the expected types of incoming data.«
 
Jon Pearce
Barry Schwarz <schwarzb@dqel.com>: Dec 28 05:05PM -0800

On Sun, 28 Dec 2014 11:29:20 -0800 (PST), mathewji
>if (cin >> day) day;
>else break; }
 
>Anyone know why this happens?
 
When cin encounters a character that cannot be part of the int, it
terminates and leaves that character in the buffer. The next time cin
tries to extract an int, it runs into the same "invalid" character.
Repeat until bored.
 
--
Remove del for email
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)