Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What's up with "Large Scale C++"
231 views
Skip to first unread message
Puppet_Sock
Nov 23, 2015, 10:23:24 AM11/23/15
to
So, some time ago (grumble mumble years...) I read John Lakos
_Large Scale C++_. The only thing is, it was mumble years ago,
and some things have changed in the intervening time. I thought
the advice he gave good, and the book is there on my shelf still.
But I did wish he would have done more with the modern features
of the language. I am currently in the very early stages of
what could, potentially, turn into a huge project. (Oh, how I
wish!) So advice that will get me off on the right foot would
be good about now.
So I noticed a few years ago (three? four?) that he had a new
edition listed on Amazon as coming soon. So I started watching
for it to be available. But the release date just keeps getting
pushed back. And pushed back. And pushed back some more.
What's up with that?
And, along the way, any suggestions on sources of good advice
on writing very large C++ programs would be gladly accepted.
If the project I am trying to sell goes ahead, it could easily
become very large.
_Large Scale C++_. The only thing is, it was mumble years ago,
and some things have changed in the intervening time. I thought
the advice he gave good, and the book is there on my shelf still.
But I did wish he would have done more with the modern features
of the language. I am currently in the very early stages of
what could, potentially, turn into a huge project. (Oh, how I
wish!) So advice that will get me off on the right foot would
be good about now.
So I noticed a few years ago (three? four?) that he had a new
edition listed on Amazon as coming soon. So I started watching
for it to be available. But the release date just keeps getting
pushed back. And pushed back. And pushed back some more.
What's up with that?
And, along the way, any suggestions on sources of good advice
on writing very large C++ programs would be gladly accepted.
If the project I am trying to sell goes ahead, it could easily
become very large.
Alf P. Steinbach
Nov 23, 2015, 11:38:32 AM11/23/15
to
On 11/23/2015 4:22 PM, Puppet_Sock wrote:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> [snip]
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
Perhaps the most important thing to note is that a large scale system is
> on writing very large C++ programs would be gladly accepted.
a team effort.
So it's very much about leading a team and dealing with economy and
politics.
* * *
That said, since you mention Lakos, Lakos' external include guards never
did become mainstream, and I suggest you avoid them. Even ordinary
internal include guards can be problematic. I suggest using now de facto
standard "#pragma once".
For this and some other like issues you need clear project coding
guidelines.
You would probably not go very wrong in adopting the coding guidelines
book by Alexandrescu and Sutter, perhaps with some adjustments.
* * *
With a large scale project source files of the same name might yield
conflicting object code file names. So it can be an idea to replicate
the source folder structure for the object code files. This is not the
default for e.g. a Visual Studio project, and one has to configure it
using the folder path macros: there's no simple option for it.
Your project team may need a build server farm. Nowadays there are a
lots of systems for helping with performing builds. I don't know much
about it, except that I know I would have to look into that if I became
involved in some large scale development again.
You might assign one person to deal exclusively with tooling, including
build system.
* * *
You're probably aware that you need a source code control system. But
possibly it's not clear enough that you also need a defect handling
system, that supports bug reporting, assignment of responsibility,
follow-up, and so on. The only free one that I remember is Bugzilla,
it's possibly still around.
Anyway, you will probably need a web server for this, with a domain, and
someone to handle that side of things.
I doubt that Lakos reflected on that (disclaimer: I haven't read the
book) ;-)
Cheers & hth.,
- Alf
Jorgen Grahn
Nov 23, 2015, 11:46:11 AM11/23/15
to
On Mon, 2015-11-23, Puppet_Sock wrote:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> So I noticed a few years ago (three? four?) that he had a new
> edition listed on Amazon as coming soon. So I started watching
> for it to be available. But the release date just keeps getting
> pushed back. And pushed back. And pushed back some more.
>
> What's up with that?
No idea, but I'm interested. I haven't read the book, but it was
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> So I noticed a few years ago (three? four?) that he had a new
> edition listed on Amazon as coming soon. So I started watching
> for it to be available. But the release date just keeps getting
> pushed back. And pushed back. And pushed back some more.
>
> What's up with that?
mentioned here now and then many years ago -- with the warning that it
had aged quite a bit.
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
> If the project I am trying to sell goes ahead, it could easily
> become very large.
warning signal. It's better if you can keep it smaller than "very
large", or split it into smaller parts ...
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Lynn McGuire
Nov 23, 2015, 1:19:14 PM11/23/15
to
Lynn
woodb...@gmail.com
Nov 23, 2015, 1:22:06 PM11/23/15
to
On Monday, November 23, 2015 at 10:46:11 AM UTC-6, Jorgen Grahn wrote:
> On Mon, 2015-11-23, Puppet_Sock wrote:
> > So, some time ago (grumble mumble years...) I read John Lakos
> > _Large Scale C++_. The only thing is, it was mumble years ago,
> > and some things have changed in the intervening time. I thought
> > the advice he gave good, and the book is there on my shelf still.
> > But I did wish he would have done more with the modern features
> > of the language. I am currently in the very early stages of
> > what could, potentially, turn into a huge project. (Oh, how I
> > wish!) So advice that will get me off on the right foot would
> > be good about now.
> >
> > So I noticed a few years ago (three? four?) that he had a new
> > edition listed on Amazon as coming soon. So I started watching
> > for it to be available. But the release date just keeps getting
> > pushed back. And pushed back. And pushed back some more.
> >
> > What's up with that?
>
> No idea, but I'm interested. I haven't read the book, but it was
> mentioned here now and then many years ago -- with the warning that it
> had aged quite a bit.
He has been interviewed a number of times and I've
> On Mon, 2015-11-23, Puppet_Sock wrote:
> > So, some time ago (grumble mumble years...) I read John Lakos
> > _Large Scale C++_. The only thing is, it was mumble years ago,
> > and some things have changed in the intervening time. I thought
> > the advice he gave good, and the book is there on my shelf still.
> > But I did wish he would have done more with the modern features
> > of the language. I am currently in the very early stages of
> > what could, potentially, turn into a huge project. (Oh, how I
> > wish!) So advice that will get me off on the right foot would
> > be good about now.
> >
> > So I noticed a few years ago (three? four?) that he had a new
> > edition listed on Amazon as coming soon. So I started watching
> > for it to be available. But the release date just keeps getting
> > pushed back. And pushed back. And pushed back some more.
> >
> > What's up with that?
>
> No idea, but I'm interested. I haven't read the book, but it was
> mentioned here now and then many years ago -- with the warning that it
> had aged quite a bit.
watched some of them:
https://duckduckgo.com/?q=john+lakos+interview&ia=videos
IIRC, he mentions the book in at least one interview and
he still wants to finish it, but has been delayed by a
number of things.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
woodb...@gmail.com
Nov 23, 2015, 2:04:56 PM11/23/15
to
https://meetingcpp.com/index.php/br/items/an-interview-with-john-lakos.html
and he talks about the original book and how he's working on a
trilogy to follow that book. The last few minutes of that
interview he says he's almost done with the first book of the
trilogy.
Brian
Ebenezer Enterprises - Bless G-d, America.
Psalms 100:4 "Enter His gates with thanksgiving And
His courts with praise. Give thanks to Him, bless His Name."
http://webEbenezer.net
Jorgen Grahn
Nov 23, 2015, 4:48:11 PM11/23/15
to
On Mon, 2015-11-23, Alf P. Steinbach wrote:
...
If you have code in foo/ and bar/ and put object code in obj/, of
course you're gambling on that there are no duplicate file names in
foo and bar!
> This is not the default for e.g. a Visual Studio project, and one
> has to configure it using the folder path macros: there's no simple
> option for it.
Ah, ok. It's pretty natural with make; that's probably why I reacted.
One single Makefile, and remember to treat the directory name as just
part of the file name -- and you're more or less home free.
(Not wishing to slam VS. I'm happy that it can be configured to do
the right thing.)
...
> With a large scale project source files of the same name might yield
> conflicting object code file names. So it can be an idea to replicate
> the source folder structure for the object code files.
That seemed weird to me, but only because it seemed so obvious to me.
> conflicting object code file names. So it can be an idea to replicate
> the source folder structure for the object code files.
If you have code in foo/ and bar/ and put object code in obj/, of
course you're gambling on that there are no duplicate file names in
foo and bar!
> This is not the default for e.g. a Visual Studio project, and one
> has to configure it using the folder path macros: there's no simple
> option for it.
One single Makefile, and remember to treat the directory name as just
part of the file name -- and you're more or less home free.
(Not wishing to slam VS. I'm happy that it can be configured to do
the right thing.)
Öö Tiib
Nov 23, 2015, 5:22:25 PM11/23/15
to
On Monday, 23 November 2015 23:48:11 UTC+2, Jorgen Grahn wrote:
> On Mon, 2015-11-23, Alf P. Steinbach wrote:
> ...
> > With a large scale project source files of the same name might yield
> > conflicting object code file names. So it can be an idea to replicate
> > the source folder structure for the object code files.
>
> That seemed weird to me, but only because it seemed so obvious to me.
> If you have code in foo/ and bar/ and put object code in obj/, of
> course you're gambling on that there are no duplicate file names in
> foo and bar!
On any case the issue of naming deserves attention in large projects.
> On Mon, 2015-11-23, Alf P. Steinbach wrote:
> ...
> > With a large scale project source files of the same name might yield
> > conflicting object code file names. So it can be an idea to replicate
> > the source folder structure for the object code files.
>
> That seemed weird to me, but only because it seemed so obvious to me.
> If you have code in foo/ and bar/ and put object code in obj/, of
> course you're gambling on that there are no duplicate file names in
> foo and bar!
Source files that have same name are typically accompanied with include
files that have same name and that will eventually cause some confusion
for some members of team. It is near hopeless to try to make new
big C++ team out of highly skilled specialists.
>
> > This is not the default for e.g. a Visual Studio project, and one
> > has to configure it using the folder path macros: there's no simple
> > option for it.
>
> Ah, ok. It's pretty natural with make; that's probably why I reacted.
> One single Makefile, and remember to treat the directory name as just
> part of the file name -- and you're more or less home free.
>
> (Not wishing to slam VS. I'm happy that it can be configured to do
> the right thing.)
that are good only for small toy projects. Also (unlike makefiles) its
pile of xml project files are by default awful to look in and painful
to manage. MS own tools are sometimes confused with those. Even in house
MS (or at least several teams of it) use makefiles.
Ian Collins
Nov 23, 2015, 5:41:51 PM11/23/15
to
嘱 Tiib wrote:
>
> VS deserves slamming. It deliberately and automatically generates things
> that are good only for small toy projects. Also (unlike makefiles) its
> pile of xml project files are by default awful to look in and painful
> to manage. MS own tools are sometimes confused with those. Even in house
> MS (or at least several teams of it) use makefiles.
I disagree with you regarding the XML project files. On a recent
>
> VS deserves slamming. It deliberately and automatically generates things
> that are good only for small toy projects. Also (unlike makefiles) its
> pile of xml project files are by default awful to look in and painful
> to manage. MS own tools are sometimes confused with those. Even in house
> MS (or at least several teams of it) use makefiles.
(embedded) project we used VS to build projects and I wrote a tool to
parse the solution and project XML files so we could generate makefiles.
The VS XML file formats are simple and consistent.
--
Ian Collins
Paavo Helde
Nov 23, 2015, 6:47:03 PM11/23/15
to
Puppet_Sock <puppe...@hotmail.com> wrote in news:f75b3dd3-14e1-49e3-
988d-a23...@googlegroups.com:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
IMO, the main issue with large scale projects is that no single person
has a clear overview what the system does. This means that the whole
project must be to some extent regular or modular in the sense that one
can extend or modify it locally without breaking too much stuff
elsewhere. A great way to achieve that is of course, as suggested by
others, to break the project down into smaller components communicating
over well-defined interfaces. The size of a single component is limited
by the brain capacity of the dumbest developer in your team.
To ensure that the pieces work well together one needs to have automated
unit and integration tests. This is because when you combine the pieces
nobody can fully understand the emerging system any more, so dealing with
it must be automated. I would even say that if there is a managable
project without automated tests, then one cannot call it a large-scale
project, more or less by definition.
Disclaimer: I have not read the book either.
hth
Paavo
988d-a23...@googlegroups.com:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
has a clear overview what the system does. This means that the whole
project must be to some extent regular or modular in the sense that one
can extend or modify it locally without breaking too much stuff
elsewhere. A great way to achieve that is of course, as suggested by
others, to break the project down into smaller components communicating
over well-defined interfaces. The size of a single component is limited
by the brain capacity of the dumbest developer in your team.
To ensure that the pieces work well together one needs to have automated
unit and integration tests. This is because when you combine the pieces
nobody can fully understand the emerging system any more, so dealing with
it must be automated. I would even say that if there is a managable
project without automated tests, then one cannot call it a large-scale
project, more or less by definition.
Disclaimer: I have not read the book either.
hth
Paavo
Puppet_Sock
Nov 24, 2015, 2:53:42 PM11/24/15
to
On Monday, November 23, 2015 at 11:38:32 AM UTC-5, Alf P. Steinbach wrote:
> On 11/23/2015 4:22 PM, Puppet_Sock wrote:
> > So, some time ago (grumble mumble years...) I read John Lakos
> > _Large Scale C++_. The only thing is, it was mumble years ago,
> > [snip]
> > And, along the way, any suggestions on sources of good advice
> > on writing very large C++ programs would be gladly accepted.
>
> Perhaps the most important thing to note is that a large scale system is
> a team effort.
>
> So it's very much about leading a team and dealing with economy and
> politics.
[snips]
> On 11/23/2015 4:22 PM, Puppet_Sock wrote:
> > So, some time ago (grumble mumble years...) I read John Lakos
> > _Large Scale C++_. The only thing is, it was mumble years ago,
> > [snip]
> > And, along the way, any suggestions on sources of good advice
> > on writing very large C++ programs would be gladly accepted.
>
> Perhaps the most important thing to note is that a large scale system is
> a team effort.
>
> So it's very much about leading a team and dealing with economy and
> politics.
Any suggestions on good sources for reading on this?
> You would probably not go very wrong in adopting the coding guidelines
> book by Alexandrescu and Sutter, perhaps with some adjustments.
get their book.
[advice on object name collision snipped]
Thanks. It may change my choice of development tools.
Which choice is not made yet since not even the
proof-of-concept study is funded yet.
[advice on need for source code control snipped]
Aware of the need. Bracing myself to have that discussion
on some other forum. Not looking forward to it.
Puppet_Sock
Nov 24, 2015, 3:28:44 PM11/24/15
to
On Monday, November 23, 2015 at 11:46:11 AM UTC-5, Jorgen Grahn wrote:
[snips]
I hope I can split things up into a pile of individually
small objects, each with relatively simple interactions.
Problem is, the physical engineering system I'm trying
to solve has a lot of distinct parts, with a lot of
important interactions. And emperical correlations with
system properties, and so on. So there are going to be
a large number of those small objects, and a large number
of types of them. With rich behaviours. And the user
input is likely to be fairly rich. With a complicated
output for the user to look at.
So, the overall system is likely to be pretty complicated.
Or at least extensive.
This complexity is, by the way, one of the reasons I have
been having a job getting somebody to buy this project.
People agree it would be great to have the tool I suggest,
but nobody wants to pay for it. Even though there have
been three projects to search out what could and should
be done.
[snips]
> My first instinct (which may be wrong in this case) is that that's a
> warning signal. It's better if you can keep it smaller than "very
> large", or split it into smaller parts ...
Some times that isn't possible.
> warning signal. It's better if you can keep it smaller than "very
> large", or split it into smaller parts ...
I hope I can split things up into a pile of individually
small objects, each with relatively simple interactions.
Problem is, the physical engineering system I'm trying
to solve has a lot of distinct parts, with a lot of
important interactions. And emperical correlations with
system properties, and so on. So there are going to be
a large number of those small objects, and a large number
of types of them. With rich behaviours. And the user
input is likely to be fairly rich. With a complicated
output for the user to look at.
So, the overall system is likely to be pretty complicated.
Or at least extensive.
This complexity is, by the way, one of the reasons I have
been having a job getting somebody to buy this project.
People agree it would be great to have the tool I suggest,
but nobody wants to pay for it. Even though there have
been three projects to search out what could and should
be done.
Richard
Nov 24, 2015, 6:58:06 PM11/24/15
to
[Please do not mail me a copy of your followup]
Puppet_Sock <puppe...@hotmail.com> spake the secret code
<177bdf0a-be63-42e3...@googlegroups.com> thusly:
>On Monday, November 23, 2015 at 11:38:32 AM UTC-5, Alf P. Steinbach wrote:
>> So it's very much about leading a team and dealing with economy and
>> politics.
Agreed.
>[snips]
>
>Any suggestions on good sources for reading on this?
IMO, beyond specifics of the language involved, all software
development projects small or large deal with the same problems.
Most of these problems stem from the nature of software development
and aren't really "solved" in any magical sort of way. You can read
Fred Brooks's stories in "Mythical Man Month" <http://amzn.to/1MB5hGb>
and the exact same stuff happens now as happened then in the 1960s/1970s.
Some suggestions in no particular order:
"Domain-Driven Design" by Eric Evans
<http://amzn.to/1HldHCG>
"Implementing Domain-Driven Design" by Vaughn Vernon
<http://amzn.to/1Nr9pfr>
These two books are complementary to each other with Vernon's
coming 10 years after Evans' important contribution to OO
architecture thinking.
"Extreme Programming Explained", 2nd ed., by Kent Beck
<http://amzn.to/1HldSxP>
"Agile Software Development: The Cooperative Game" by Alistair Cockburn
<http://amzn.to/1MB4NA0>
A good exploration of agile software development. Beck's is more
tactical and Cockburn's is more strategic.
Kent Beck and Alistair Cockburn are both signers of the Agile
Manifesto.
<https://en.wikipedia.org/wiki/Agile_software_development#cite_note-12>
"Modern C++ Programming with Test-Driven Development" by Jeff Langr
<http://amzn.to/1T1I1D2>
Excellent treatment of TDD using modern C++ for all the examples.
"User Story Mapping" by Jeff Patton
<http://amzn.to/1T1IOnj>
Excellent discussion on how to make sure you are not just building
something, but building the *right* thing.
Disclaimer: I've known Jeff Patton and Alistair Cockburn for years.
I recommend their books because they are full of great stuff.
--
"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>
Puppet_Sock <puppe...@hotmail.com> spake the secret code
<177bdf0a-be63-42e3...@googlegroups.com> thusly:
>On Monday, November 23, 2015 at 11:38:32 AM UTC-5, Alf P. Steinbach wrote:
>> So it's very much about leading a team and dealing with economy and
>> politics.
>[snips]
>
>Any suggestions on good sources for reading on this?
development projects small or large deal with the same problems.
Most of these problems stem from the nature of software development
and aren't really "solved" in any magical sort of way. You can read
Fred Brooks's stories in "Mythical Man Month" <http://amzn.to/1MB5hGb>
and the exact same stuff happens now as happened then in the 1960s/1970s.
Some suggestions in no particular order:
"Domain-Driven Design" by Eric Evans
<http://amzn.to/1HldHCG>
"Implementing Domain-Driven Design" by Vaughn Vernon
<http://amzn.to/1Nr9pfr>
These two books are complementary to each other with Vernon's
coming 10 years after Evans' important contribution to OO
architecture thinking.
"Extreme Programming Explained", 2nd ed., by Kent Beck
<http://amzn.to/1HldSxP>
"Agile Software Development: The Cooperative Game" by Alistair Cockburn
<http://amzn.to/1MB4NA0>
A good exploration of agile software development. Beck's is more
tactical and Cockburn's is more strategic.
Kent Beck and Alistair Cockburn are both signers of the Agile
Manifesto.
<https://en.wikipedia.org/wiki/Agile_software_development#cite_note-12>
"Modern C++ Programming with Test-Driven Development" by Jeff Langr
<http://amzn.to/1T1I1D2>
Excellent treatment of TDD using modern C++ for all the examples.
"User Story Mapping" by Jeff Patton
<http://amzn.to/1T1IOnj>
Excellent discussion on how to make sure you are not just building
something, but building the *right* thing.
Disclaimer: I've known Jeff Patton and Alistair Cockburn for years.
I recommend their books because they are full of great stuff.
--
"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>
Robert Wessel
Nov 24, 2015, 7:05:51 PM11/24/15
to
that the only form of payment for that expense is money), and large
projects are *very* expensive, and have a very high risk of failure.
And given how many times people have been burned, it's no wonder that
they're shy about committing financially to a big project, especially
if you don't have a track record, or the project definition includes a
bunch of hand waving, not to mention the risk that the long
development time itself poses (the world may just move on from the
requirement).
Anyway, you might consider trying to structure this incrementally. So
you can build a reasonable sized thing that can demonstrate that the
project is on the right track. For a sufficiently large project, you
may end up planning several milestones. At some point you have
shippable product, but again, you may want to get there before you can
do everything. At each milestone the investors can evaluate where
things are, how the marketing is changing, and how the system is
starting to shape up, not to mention your performance. But basically
some reasonable sized bites may be an easier sell than one big
project. OTOH, that's certainly worse for you - the investors might
just lose interest at some point, and you've got little recourse.
seeplus
Nov 25, 2015, 3:04:55 AM11/25/15
to
On Tuesday, November 24, 2015 at 2:23:24 AM UTC+11, Puppet_Sock wrote:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
InformIT have a new livelessons vid by John Lakos
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
on getting into large scale C++.
You can look at a couple of episodes free.
List of topics in the vid is fairly arduous going.
Also old books, including his, there.
There is a BF sale at present.
Paavo Helde
Nov 25, 2015, 3:39:12 AM11/25/15
to
legaliz...@mail.xmission.com (Richard) wrote in
news:n32ti1$4nh$1...@news.xmission.com:
>
> "Extreme Programming Explained", 2nd ed., by Kent Beck
> <http://amzn.to/1HldSxP>
> "Agile Software Development: The Cooperative Game" by Alistair
> Cockburn
> <http://amzn.to/1MB4NA0>
>
> A good exploration of agile software development. Beck's is more
> tactical and Cockburn's is more strategic.
A word of caution about things called "agile". When implemented wrongly,
the agile approach may be interpreted to prescribe that all of the team has
about the same overview of the whole system so each member can replace any
other. With large projects, this is just not possible.
(When done right, the agile approach seems to become a synonym with "use
some common sense and do whatever works well for your project", which is
great of course but I am not sure why a buzzword is needed for doing that.)
Cheers
Paavo
news:n32ti1$4nh$1...@news.xmission.com:
>
> "Extreme Programming Explained", 2nd ed., by Kent Beck
> <http://amzn.to/1HldSxP>
> "Agile Software Development: The Cooperative Game" by Alistair
> Cockburn
> <http://amzn.to/1MB4NA0>
>
> A good exploration of agile software development. Beck's is more
> tactical and Cockburn's is more strategic.
the agile approach may be interpreted to prescribe that all of the team has
about the same overview of the whole system so each member can replace any
other. With large projects, this is just not possible.
(When done right, the agile approach seems to become a synonym with "use
some common sense and do whatever works well for your project", which is
great of course but I am not sure why a buzzword is needed for doing that.)
Cheers
Paavo
Puppet_Sock
Nov 25, 2015, 9:43:01 AM11/25/15
to
On Tuesday, November 24, 2015 at 6:58:06 PM UTC-5, Richard wrote:
[good suggestions on books about the development process snipped]
Thanks Richard. Some of these I have already read and
thought very good. Most of them are new to me, and look
to be very helpful.
[good suggestions on books about the development process snipped]
Thanks Richard. Some of these I have already read and
thought very good. Most of them are new to me, and look
to be very helpful.
Puppet_Sock
Nov 25, 2015, 9:55:58 AM11/25/15
to
On Tuesday, November 24, 2015 at 7:05:51 PM UTC-5, robert...@yahoo.com wrote:
[snips]
is room for incremental improvements. Mostly I want to be
sure that any small part of the solution I manage to sell
will provide a good stepping stone to a larger solution.
This is why I want to "swatt up" on large projects. I want
to try to avoid pitfalls in my early stages. I want to be
able to add lots of new stuff onto the starting parts and
not have the expanding system collapse.
The reason I persist trying to sell this project is the
nature of my industry. Mistakes in design and construction
tend to be grossly expensive to correct. It is not unknown
for $billion projects to get cancelled after spending the
$billion, because design or construction errors were made
and detected later. Or for a $billion project to be 100%
over budget, or more. So if I can make software that will
save even a few such things, a huge software budget can
be justified.
Heh. But my personal motivation is mostly that I hate
using the existing software when I know I could write
better software if given the chance. Because I have
written better for several smaller things.
[snips]
> Well, software development is expensive (and I don't mean to imply
> that the only form of payment for that expense is money), and large
> projects are *very* expensive, and have a very high risk of failure.
> And given how many times people have been burned, it's no wonder that
> they're shy about committing financially to a big project, especially
> if you don't have a track record, or the project definition includes a
> bunch of hand waving, not to mention the risk that the long
> development time itself poses (the world may just move on from the
> requirement).
>
> Anyway, you might consider trying to structure this incrementally. So
> you can build a reasonable sized thing that can demonstrate that the
> project is on the right track. For a sufficiently large project, you
> may end up planning several milestones. At some point you have
> shippable product, but again, you may want to get there before you can
> do everything. At each milestone the investors can evaluate where
> things are, how the marketing is changing, and how the system is
> starting to shape up, not to mention your performance. But basically
> some reasonable sized bites may be an easier sell than one big
> project. OTOH, that's certainly worse for you - the investors might
> just lose interest at some point, and you've got little recourse.
I agree with the general ideas of your post. There certainly
> that the only form of payment for that expense is money), and large
> projects are *very* expensive, and have a very high risk of failure.
> And given how many times people have been burned, it's no wonder that
> they're shy about committing financially to a big project, especially
> if you don't have a track record, or the project definition includes a
> bunch of hand waving, not to mention the risk that the long
> development time itself poses (the world may just move on from the
> requirement).
>
> Anyway, you might consider trying to structure this incrementally. So
> you can build a reasonable sized thing that can demonstrate that the
> project is on the right track. For a sufficiently large project, you
> may end up planning several milestones. At some point you have
> shippable product, but again, you may want to get there before you can
> do everything. At each milestone the investors can evaluate where
> things are, how the marketing is changing, and how the system is
> starting to shape up, not to mention your performance. But basically
> some reasonable sized bites may be an easier sell than one big
> project. OTOH, that's certainly worse for you - the investors might
> just lose interest at some point, and you've got little recourse.
is room for incremental improvements. Mostly I want to be
sure that any small part of the solution I manage to sell
will provide a good stepping stone to a larger solution.
This is why I want to "swatt up" on large projects. I want
to try to avoid pitfalls in my early stages. I want to be
able to add lots of new stuff onto the starting parts and
not have the expanding system collapse.
The reason I persist trying to sell this project is the
nature of my industry. Mistakes in design and construction
tend to be grossly expensive to correct. It is not unknown
for $billion projects to get cancelled after spending the
$billion, because design or construction errors were made
and detected later. Or for a $billion project to be 100%
over budget, or more. So if I can make software that will
save even a few such things, a huge software budget can
be justified.
Heh. But my personal motivation is mostly that I hate
using the existing software when I know I could write
better software if given the chance. Because I have
written better for several smaller things.
Richard
Nov 25, 2015, 1:42:37 PM11/25/15
to
[Please do not mail me a copy of your followup]
Paavo Helde <myfir...@osa.pri.ee> spake the secret code
<XnsA55D6C54BE41Em...@216.166.105.131> thusly:
presented as exactly that.
The reason that the folks signing the agile manifesto didn't prescrive
a set of specific practices is because they couldn't agree on the best
practices to use universally. That's why the agile manifesto is a
series of value propositions instead of a series of specific "do this"
prescriptions.
You may think that the value propositions are "common sense", but
clearly they aren't so common or making so much sense to many people
otherwise the manifesto wouldn't be worth writing. I worked on a team
where everyone claimed they were working in an agile manner, but when
I looked at the value propositions in the manifesto, my team was
literally taking the exact opposite stance on all of them.
If your team already has the values expressed in the manifesto, then
it's going to feel like common sense to work in an agile manner. If
your team is objecting to, or remains unconvinced of, the value
propositions in the manifesto, then you're going to have difficulty
operating in an agile manner.
Sometimes it just boils down to hiring the right people.
Öö Tiib
Nov 25, 2015, 2:58:12 PM11/25/15
to
On Wednesday, 25 November 2015 20:42:37 UTC+2, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> [Please do not mail me a copy of your followup]
>
> Sometimes it just boils down to hiring the right people.
Why you did hire wrong people? However not everything is lost
yet ... bears can be taught to bicycle and software developers (most
bovine and dense of people) can be also sometimes taught. :D
Wouter van Ooijen
Nov 25, 2015, 3:11:49 PM11/25/15
to
Op 25-Nov-15 om 7:42 PM schreef Richard:
*sometimes* ??
Wouter
Wouter
Richard
Nov 25, 2015, 4:46:34 PM11/25/15
to
[Please do not mail me a copy of your followup]
Wouter van Ooijen <wou...@voti.nl> spake the secret code
<565615ca$0$9691$e4fe...@newszilla.xs4all.nl> thusly:
>Op 25-Nov-15 om 7:42 PM schreef Richard:
>>
>> If your team already has the values expressed in the manifesto, then
>> it's going to feel like common sense to work in an agile manner. If
>> your team is objecting to, or remains unconvinced of, the value
>> propositions in the manifesto, then you're going to have difficulty
>> operating in an agile manner.
>>
>> Sometimes it just boils down to hiring the right people.
>
>*sometimes* ??
Heh heh :).
>> it's going to feel like common sense to work in an agile manner. If
>> your team is objecting to, or remains unconvinced of, the value
>> propositions in the manifesto, then you're going to have difficulty
>> operating in an agile manner.
>>
>> Sometimes it just boils down to hiring the right people.
>
>*sometimes* ??
I was thinking along the lines of attempts to introduce agile practices
to an existing team. Sometimes you luck out and the people on the
team already agree with the value propositions in the agile manifesto.
In such a situation, introducing TDD, extreme programming, story
mapping and so-on can be all you need to make a difference on your team.
If your team doesn't agree with the values in the agile manifesto,
then you have a tougher time of it. Sometimes you can transform a
team from inside, sometimes not.
Paavo Helde
Nov 25, 2015, 6:20:03 PM11/25/15
to
Puppet_Sock <puppe...@hotmail.com> wrote in
news:2110a336-58eb-460a...@googlegroups.com:
> Heh. But my personal motivation is mostly that I hate
> using the existing software when I know I could write
> better software if given the chance.
Unless you can't. There is some pretty good stuff out there, including most
of the C++ standard library and Boost, plus some other decent libraries
like Crypto++ and many de-facto standard-defining C libraries. I am pretty
sure you as a single person would have hard time to reproduce e.g. Boost
asio library, with all the platform-specific low-level socket handling
tricks all over the various platforms, etc.
It's also true that not all libraries are good and in many cases one needs
to write their own. Sometimes the defects and problems would come out only
after some years of usage. It is more like an art to know when to reuse the
existing and when exactly the wheel needs reinventing.
Cheers
Paavo
news:2110a336-58eb-460a...@googlegroups.com:
> Heh. But my personal motivation is mostly that I hate
> using the existing software when I know I could write
> better software if given the chance.
of the C++ standard library and Boost, plus some other decent libraries
like Crypto++ and many de-facto standard-defining C libraries. I am pretty
sure you as a single person would have hard time to reproduce e.g. Boost
asio library, with all the platform-specific low-level socket handling
tricks all over the various platforms, etc.
It's also true that not all libraries are good and in many cases one needs
to write their own. Sometimes the defects and problems would come out only
after some years of usage. It is more like an art to know when to reuse the
existing and when exactly the wheel needs reinventing.
Cheers
Paavo
Ian Collins
Nov 25, 2015, 6:45:47 PM11/25/15
to
Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <565615ca$0$9691$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 25-Nov-15 om 7:42 PM schreef Richard:
>>>
>>> If your team already has the values expressed in the manifesto, then
>>> it's going to feel like common sense to work in an agile manner. If
>>> your team is objecting to, or remains unconvinced of, the value
>>> propositions in the manifesto, then you're going to have difficulty
>>> operating in an agile manner.
>>>
>>> Sometimes it just boils down to hiring the right people.
>>
>> *sometimes* ??
>
> Heh heh :).
>
> I was thinking along the lines of attempts to introduce agile practices
> to an existing team. Sometimes you luck out and the people on the
> team already agree with the value propositions in the agile manifesto.
> In such a situation, introducing TDD, extreme programming, story
> mapping and so-on can be all you need to make a difference on your team.
>
> If your team doesn't agree with the values in the agile manifesto,
> then you have a tougher time of it. Sometimes you can transform a
> team from inside, sometimes not.
I've had a mixed experience introducing agile into teams. Two
> [Please do not mail me a copy of your followup]
>
> Wouter van Ooijen <wou...@voti.nl> spake the secret code
> <565615ca$0$9691$e4fe...@newszilla.xs4all.nl> thusly:
>
>> Op 25-Nov-15 om 7:42 PM schreef Richard:
>>>
>>> If your team already has the values expressed in the manifesto, then
>>> it's going to feel like common sense to work in an agile manner. If
>>> your team is objecting to, or remains unconvinced of, the value
>>> propositions in the manifesto, then you're going to have difficulty
>>> operating in an agile manner.
>>>
>>> Sometimes it just boils down to hiring the right people.
>>
>> *sometimes* ??
>
> Heh heh :).
>
> I was thinking along the lines of attempts to introduce agile practices
> to an existing team. Sometimes you luck out and the people on the
> team already agree with the value propositions in the agile manifesto.
> In such a situation, introducing TDD, extreme programming, story
> mapping and so-on can be all you need to make a difference on your team.
>
> If your team doesn't agree with the values in the agile manifesto,
> then you have a tougher time of it. Sometimes you can transform a
> team from inside, sometimes not.
successful, one not for the reasons you cite above.
As the old Meatloaf song goes, two out of three ain't bad!
--
Ian Collins
woodb...@gmail.com
Nov 25, 2015, 10:47:22 PM11/25/15
to
On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote:
>
> IMO, the main issue with large scale projects is that no single person
> has a clear overview what the system does.
Sorry, but I have to disagree.
>
> IMO, the main issue with large scale projects is that no single person
> has a clear overview what the system does.
"The L-rd looks from heaven;
He sees all the sons of men;
From His dwelling place He looks out
On all the inhabitants of the earth,
He who fashions the hearts of them all,
He who understands all their works." Psalms 33:13-15
"For who has known the mind of the L-rd, that he will
instruct Him? But we have the mind of Christ." First Corinthians 2:16
"Unless the L-rd builds the house, they labor in vain
that build it." Psalms 127:1
"And we know that G-d causes all things to work together
for good to those who love G-d, to those who are called
according to His purpose." Romans 8:28
G-d leads us through difficulties. He uses the difficulties
to draw us closer to Him.
Brian
Ebenezer Enterprises
http://webEbenezer.net
Ian Collins
Nov 25, 2015, 10:56:38 PM11/25/15
to
woodb...@gmail.com wrote:
> On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote:
>>
>> IMO, the main issue with large scale projects is that no single person
>> has a clear overview what the system does.
>
> Sorry, but I have to disagree.
There's a time and a place for proselytising, c.l.c++ isn't it.
> On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote:
>>
>> IMO, the main issue with large scale projects is that no single person
>> has a clear overview what the system does.
>
> Sorry, but I have to disagree.
--
Ian Collins
Bo Persson
Nov 26, 2015, 11:00:04 AM11/26/15
to
On 2015-11-26 04:46, woodb...@gmail.com wrote:
> On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote:
>>
>> IMO, the main issue with large scale projects is that no single person
>> has a clear overview what the system does.
>
> Sorry, but I have to disagree.
>
> "The L-rd looks from heaven;
> He sees all the sons of men;
> From His dwelling place He looks out
> On all the inhabitants of the earth,
> He who fashions the hearts of them all,
> He who understands all their works." Psalms 33:13-15
>
> "For who has known the mind of the L-rd, that he will
> instruct Him? But we have the mind of Christ." First Corinthians 2:16
>
> "Unless the L-rd builds the house, they labor in vain
> that build it." Psalms 127:1
>
> "And we know that G-d causes all things to work together
> for good to those who love G-d, to those who are called
> according to His purpose." Romans 8:28
>
> G-d leads us through difficulties. He uses the difficulties
> to draw us closer to Him.
Easy on the sausages.
> On Monday, November 23, 2015 at 5:47:03 PM UTC-6, Paavo Helde wrote:
>>
>> IMO, the main issue with large scale projects is that no single person
>> has a clear overview what the system does.
>
> Sorry, but I have to disagree.
>
> "The L-rd looks from heaven;
> He sees all the sons of men;
> From His dwelling place He looks out
> On all the inhabitants of the earth,
> He who fashions the hearts of them all,
> He who understands all their works." Psalms 33:13-15
>
> "For who has known the mind of the L-rd, that he will
> instruct Him? But we have the mind of Christ." First Corinthians 2:16
>
> "Unless the L-rd builds the house, they labor in vain
> that build it." Psalms 127:1
>
> "And we know that G-d causes all things to work together
> for good to those who love G-d, to those who are called
> according to His purpose." Romans 8:28
>
> G-d leads us through difficulties. He uses the difficulties
> to draw us closer to Him.
woodb...@gmail.com
Nov 26, 2015, 11:33:44 AM11/26/15
to
able to do more with less. The way that others have
been discussing will do less with more. It has
diminishing returns.
Puppet_Sock
Nov 26, 2015, 12:09:06 PM11/26/15
to
One of my big complaints about the existing tools is
that they don't use standard libraries, nor even
commercial code base that is widely available. Standard
stuff like a matrix inversion routine has been done
from scratch. Often three or four different ways in
one code. And sadly often in an obfuscated way such
that verifying it is correct is a total pain.
So, for example, one code I have flattened my forhead
on the terminal over has a matrix inversion routine
with a fixed size matrix. So the code can only
analyze one size array. Indeed, it would not be
straightforward to change that size in the source
code and re-compile, because the size appears in
a bunch of places. So when the manager wanted to
explore the consequences of changing the number of
things this matrix represented, I had to tell him no.
At least, not in the budget he suggested.
This is FORTRAN from the 1970s in many cases.
It started life when punch cards were the rage.
I've even found Hollerith codes in there. It is
really difficult to use, to understand, to maintain,
and to verify as correct. And moving it to another
platform is an Odyssey level task.
I'm quite sure I could do better.
Öö Tiib
Nov 26, 2015, 4:43:31 PM11/26/15
to
and if code-base inverts matrices a lot then things are likely bad with
it. Majority (likely all) of the problems solved with matrix inversion
can be solved with cheaper methods. We can use use a variety of direct
(like LU, QR, SVD or Cholesky decomposition), semi-direct (like conjugate
gradients), or iterative (like multi-grid or over-relaxation) methods.
The methods tend to make solution way cheaper than inverting matrices.
It is possible that there are problems where inverting matrices can
not be avoided or is more optimal but it is hard to find such examples.
>
> So, for example, one code I have flattened my forhead
> on the terminal over has a matrix inversion routine
> with a fixed size matrix. So the code can only
> analyze one size array. Indeed, it would not be
> straightforward to change that size in the source
> code and re-compile, because the size appears in
> a bunch of places. So when the manager wanted to
> explore the consequences of changing the number of
> things this matrix represented, I had to tell him no.
> At least, not in the budget he suggested.
>
> This is FORTRAN from the 1970s in many cases.
> It started life when punch cards were the rage.
> I've even found Hollerith codes in there. It is
> really difficult to use, to understand, to maintain,
> and to verify as correct. And moving it to another
> platform is an Odyssey level task.
>
> I'm quite sure I could do better.
even in FORTRAN. ;) The only trouble might be to find a team of people
proficient with both math and C++.
Öö Tiib
Nov 27, 2015, 12:26:36 AM11/27/15
to
On Thursday, 26 November 2015 19:09:06 UTC+2, Puppet_Sock wrote:
> On Wednesday, November 25, 2015 at 6:20:03 PM UTC-5, Paavo Helde wrote:
> > Puppet_Sock <puppe...@hotmail.com> wrote in
> > news:2110a336-58eb-460a...@googlegroups.com:
> >
> > > Heh. But my personal motivation is mostly that I hate
> > > using the existing software when I know I could write
> > > better software if given the chance.
> >
> > Unless you can't. There is some pretty good stuff out there, including most
> > of the C++ standard library and Boost, plus some other decent libraries
> > like Crypto++ and many de-facto standard-defining C libraries. I am pretty
> > sure you as a single person would have hard time to reproduce e.g. Boost
> > asio library, with all the platform-specific low-level socket handling
> > tricks all over the various platforms, etc.
> >
> > It's also true that not all libraries are good and in many cases one needs
> > to write their own. Sometimes the defects and problems would come out only
> > after some years of usage. It is more like an art to know when to reuse the
> > existing and when exactly the wheel needs reinventing.
>
> I'm not talking about reinventing.
Forgot to reply to that one. If your program involves lot of linear algebra
> > Puppet_Sock <puppe...@hotmail.com> wrote in
> > news:2110a336-58eb-460a...@googlegroups.com:
> >
> > > Heh. But my personal motivation is mostly that I hate
> > > using the existing software when I know I could write
> > > better software if given the chance.
> >
> > Unless you can't. There is some pretty good stuff out there, including most
> > of the C++ standard library and Boost, plus some other decent libraries
> > like Crypto++ and many de-facto standard-defining C libraries. I am pretty
> > sure you as a single person would have hard time to reproduce e.g. Boost
> > asio library, with all the platform-specific low-level socket handling
> > tricks all over the various platforms, etc.
> >
> > It's also true that not all libraries are good and in many cases one needs
> > to write their own. Sometimes the defects and problems would come out only
> > after some years of usage. It is more like an art to know when to reuse the
> > existing and when exactly the wheel needs reinventing.
>
> I'm not talking about reinventing.
and matrices then it seems that currently the winner open source C++
library for that is Eigen3. It uses OpenMP. It uses explicit vectorization
instructions of most popular processors. It is licensed MPL2 that means
with weak copyleft. Eigen is popular and used so you may find people who
are already familiar with it.
Brian Wood
Dec 21, 2020, 3:27:04 PM12/21/20
to
On Monday, November 23, 2015 at 9:23:24 AM UTC-6, Puppet_Sock wrote:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> So I noticed a few years ago (three? four?) that he had a new
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> edition listed on Amazon as coming soon. So I started watching
> for it to be available. But the release date just keeps getting
> pushed back. And pushed back. And pushed back some more.
>
> What's up with that?
>
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
> If the project I am trying to sell goes ahead, it could easily
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
> become very large.
I don't remember seeing this poster recently, but the book
arrived a year or so ago. I bought a copy of it and in a
nutshell: I don't like how big and heavy it is, but have found
a number of ideas that have been helpful to me and am not
finished reading it.
Also appreciate John for taking some stands that are
contrary to the prevailing wisdom. He writes:
"In our methodology, we have chosen to treat the valid
identifier-character underscore (_) specially, reserving
it's use for a higher purpose than mere word separation,
for which we use camelCase or CamelCase in most
logical names as appropriate."
I'm heading in that direction also with my library for
a few years now.
Brian
Ebenezer Enterprises
https://webEbenezer.net
Brian Wood
Dec 21, 2020, 3:30:19 PM12/21/20
to
Bonita Montero
Dec 21, 2020, 3:38:26 PM12/21/20
to
The major issue I have with writing large scale C++-applications is that
exceptions that might be trown in C++ musst be carefully documented.
I wish I'd have checked exceptions like in Java - that's the coronation
of clean error-handling (although there are Java application developer
hogs that derive exception that should be declared or packaged inside
another exception (chaining) from RuntimeException).
exceptions that might be trown in C++ musst be carefully documented.
I wish I'd have checked exceptions like in Java - that's the coronation
of clean error-handling (although there are Java application developer
hogs that derive exception that should be declared or packaged inside
another exception (chaining) from RuntimeException).
Christian Hanné
Dec 22, 2020, 10:46:16 AM12/22/20
to
Brian Wood
Dec 22, 2020, 2:30:28 PM12/22/20
to
On Tuesday, December 22, 2020 at 9:46:16 AM UTC-6, Christian Hanné wrote:
The author gave a talk about the book that is a legal
and ethical way to get more info:
https://duckduckgo.com/?q=cppcon+2020+lakos&page=1&adx=artexpa&sexp=%7B%22cdrexp%22%3A%22b%22%2C%22artexp%22%3A%22a%22%2C%22prodexp%22%3A%22b%22%2C%22prdsdexp%22%3A%22c%22%2C%22biaexp%22%3A%22b%22%2C%22msvrtexp%22%3A%22b%22%2C%22bltexp%22%3A%22b%22%7D&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dd3zMfMC8l5U
The author gave a talk about the book that is a legal
and ethical way to get more info:
https://duckduckgo.com/?q=cppcon+2020+lakos&page=1&adx=artexpa&sexp=%7B%22cdrexp%22%3A%22b%22%2C%22artexp%22%3A%22a%22%2C%22prodexp%22%3A%22b%22%2C%22prdsdexp%22%3A%22c%22%2C%22biaexp%22%3A%22b%22%2C%22msvrtexp%22%3A%22b%22%2C%22bltexp%22%3A%22b%22%7D&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dd3zMfMC8l5U
Keith Thompson
Dec 22, 2020, 3:22:21 PM12/22/20
to
Puppet_Sock <puppe...@hotmail.com> writes:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> So I noticed a few years ago (three? four?) that he had a new
> edition listed on Amazon as coming soon. So I started watching
> for it to be available. But the release date just keeps getting
> pushed back. And pushed back. And pushed back some more.
>
> What's up with that?
>
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
> If the project I am trying to sell goes ahead, it could easily
> become very large.
On amazon.com, I see:
> So, some time ago (grumble mumble years...) I read John Lakos
> _Large Scale C++_. The only thing is, it was mumble years ago,
> and some things have changed in the intervening time. I thought
> the advice he gave good, and the book is there on my shelf still.
> But I did wish he would have done more with the modern features
> of the language. I am currently in the very early stages of
> what could, potentially, turn into a huge project. (Oh, how I
> wish!) So advice that will get me off on the right foot would
> be good about now.
>
> So I noticed a few years ago (three? four?) that he had a new
> edition listed on Amazon as coming soon. So I started watching
> for it to be available. But the release date just keeps getting
> pushed back. And pushed back. And pushed back some more.
>
> What's up with that?
>
> And, along the way, any suggestions on sources of good advice
> on writing very large C++ programs would be gladly accepted.
> If the project I am trying to sell goes ahead, it could easily
> become very large.
Large-Scale C++ Volume I: Process and Architecture Dec 17, 2019
Large-Scale C++ Volume II: Design and Implementation Mar 14, 2021
--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Jorgen Grahn
Dec 23, 2020, 11:50:12 AM12/23/20
to
On Tue, 2020-12-22, Keith Thompson wrote:
> Puppet_Sock <puppe...@hotmail.com> writes:
>> So, some time ago (grumble mumble years...) I read John Lakos
>> _Large Scale C++_. The only thing is, it was mumble years ago,
>> and some things have changed in the intervening time. I thought
>> the advice he gave good, and the book is there on my shelf still.
>> But I did wish he would have done more with the modern features
>> of the language. I am currently in the very early stages of
>> what could, potentially, turn into a huge project. (Oh, how I
>> wish!) So advice that will get me off on the right foot would
>> be good about now.
>>
>> So I noticed a few years ago (three? four?) that he had a new
>> edition listed on Amazon as coming soon. So I started watching
>> for it to be available. But the release date just keeps getting
>> pushed back. And pushed back. And pushed back some more.
>>
>> What's up with that?
>>
>> And, along the way, any suggestions on sources of good advice
>> on writing very large C++ programs would be gladly accepted.
>> If the project I am trying to sell goes ahead, it could easily
>> become very large.
>
> On amazon.com, I see:
>
> Large-Scale C++ Volume I: Process and Architecture Dec 17, 2019
> Large-Scale C++ Volume II: Design and Implementation Mar 14, 2021
And I hear he's been talking at conferences recently. My coworkers who
> Puppet_Sock <puppe...@hotmail.com> writes:
>> So, some time ago (grumble mumble years...) I read John Lakos
>> _Large Scale C++_. The only thing is, it was mumble years ago,
>> and some things have changed in the intervening time. I thought
>> the advice he gave good, and the book is there on my shelf still.
>> But I did wish he would have done more with the modern features
>> of the language. I am currently in the very early stages of
>> what could, potentially, turn into a huge project. (Oh, how I
>> wish!) So advice that will get me off on the right foot would
>> be good about now.
>>
>> So I noticed a few years ago (three? four?) that he had a new
>> edition listed on Amazon as coming soon. So I started watching
>> for it to be available. But the release date just keeps getting
>> pushed back. And pushed back. And pushed back some more.
>>
>> What's up with that?
>>
>> And, along the way, any suggestions on sources of good advice
>> on writing very large C++ programs would be gladly accepted.
>> If the project I am trying to sell goes ahead, it could easily
>> become very large.
>
> On amazon.com, I see:
>
> Large-Scale C++ Volume I: Process and Architecture Dec 17, 2019
> Large-Scale C++ Volume II: Design and Implementation Mar 14, 2021
follow such things talked about it -- not because he was a name from
the distant past of C++, but because they found him interesting.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
0 new messages