大规模C ++软件设计

本文介绍了大规模C ++软件设计的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！问题描述 29岁程序员，3月因学历无情被辞！我终于开始阅读大规模C ++ 软件设计一书了。作者：John Lakos。有没有人记录这本书的哪些部分现在已经过时了，原因是？ C ++语言变化如命名空间？或者现在一般来说被认为是错误的建议？欢迎在这里回答书中讨论的特定主题。我还注意到John Lakos准备了一本书，名为 Scalable C ++：Component-Based Development。也许这是第二版需要的很多。谢谢马克 [见 http://www.gotw.ca/resources/clcm.htm 有关的信息] [comp.lang.c ++。moderated。第一次海报：做到这一点！ ] 解决方案 marktxx写道：我终于开始阅读了书大规模C ++ 软件设计作者：John Lakos。是否有人记录了由于名称空间等C ++语言变化而导致本书的哪些部分已经过时？这些建议在撰写本书时已经过时了。或者现在通常被视为不好的建议？这里有一个不好的建议存储库： http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign 要阅读LSCSD，想象一下将每个指南纳入你的拥有的习惯。有些地方，例如放置#include线的地方，很棒，至关重要，和容易。有些，比如单元测试，是关键任务但很难。有些如注册包前缀仍然普遍有效，但是不应盲目适用。这本书仍然完全相关因为Lakos并不只是说做这个，他解释了自己的研究得出每个结论。画出你自己的结果，然后质疑你读的 _everything_ 。即使是符合标准的东西。我也注意到John Lakos有一本准备书，名为Scalable C ++：Component-Based Development。也许这就是第二版所需要的。也许它会涵盖CORBA，这是一个过度研究和低于/ / 记录组件系统似乎有很大潜力。 - Phlip http://c2.com/cgi/wiki?ZeekLand < - NOT a博客!!! [见 http：// www.gotw.ca/resources/clcm.htm 有关的信息] [comp.lang.c ++。moderated。第一次海报：做到这一点！ ] Phlip写道： marktxx写道：我终于开始阅读大规模的C ++软件设计一书了。约翰拉科斯是否有人记录了由于C ++语言等命名空间的变化，本书的哪些部分现已过时？这些建议在编写本书时已经过时了。你在开玩笑吧？在我第一次看到这本书的时候，我没有使用支持名称空间的编译器。即使在今天，我发现命名空间引入了如此多的额外混淆就像函数重载一样（开始并不简单），我倾向于避免它们，除非是在最高级别。（我很高兴标准库在命名空间中，对于示例。）或现在通常被认为是不好的建议？这里有一个很好的不良建议存储库： http ：//c2.com/cgi/wiki？LargeScaleCppSoftwareDesign 我快速浏览了一眼，但似乎并没有真正的价值。有用的信息。（有很多不合理的意见，但没有具体的内容。）要阅读LSCSD，想象一下将每个指南纳入自己的习惯。一些，例如放置#include线的位置，是非常棒的，关键的和简单的。一些例如单元测试是关键任务，但很难。某些（例如注册包装前缀）仍然有效，但不应盲目应用。这本书仍然完全相关，因为Lakos并不只是说做这个，他解释了自己的研究以得出每个结论。绘制自己的结果和问题_everything_你读了。即使是跟上标准的东西。听起来就像我会说的那样。所有基本的原则仍然适用。你如何在任何给定的项目中实际应用它们会有所不同。我还注意到John Lakos有一本准备好的书叫做可扩展的C ++：组件 -Based Development"也许这是非常需要的第二版。也许它将涵盖CORBA，这是一个过度研究和未充分记录的组件系统似乎有很大的潜力。我同意。 Corba似乎几乎是一种感觉，但对于我看到的大多数应用程序来说，这将是一个比XML更好的解决方案，因为它们正在被使用是在...。 - James Kanze GABI软件 Conseils eninformatiqueorientéeobjet/ Beratung in objektorientierter Datenverarbeitung 9placeSémard，78210 St.-Cyr-l''coco，France，+ 33（0）1 30 23 00 34 [见 http://www.gotw.ca/resources/clcm.htm 有关的信息] [comp.lang.c ++。审核。第一次海报：做到这一点！ ] kanze写道：你在开玩笑吗？不，我只是没有注意到我发布到了经过审核的小组。当我第一次看到这本书的时候，没有一个编译器我使用支持的命名空间。即便在今天，我发现名称空间引入了诸如函数重载之类的额外混淆（开始并不简单）我倾向于避免使用它们，除非是在最高级别。（我很高兴标准库位于命名空间中，例如。） OP问到了什么变成了从那以后就过时了。所以也许我们同意关于注册包前缀的建议现在已经过时了，因为它当时是。 http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign 我快速浏览了一下，但似乎并没有真正有用的信息。（有很多不合理的意见，但没有具体的。）随意编辑它。这个页面 - 模糊地 - 尝试揭示了前缀和命名空间之间的紧张和争论，以及这本书在辩论中的作用。当然这很快就会变成一个"侧"尖叫这本书是邪恶的化身，而另一个侧面是试图理性。我同意。 Corba似乎几乎是不可思议的，但对于我看到的大多数应用程序来说，这将是一个更好的解决方案，而不是像XML这样的东西，因为它们是in而被使用。我目前正在学习CORBA组件模型，它可能值得所有英亩的PDF专用于它有多棒...... - Phlip http://c2.com/cgi/wiki?ZeekLand < - 不是博客!!! [见 http://www.gotw.ca/resources/clcm.htm 有关的信息] [comp.lang.c ++。moderated。第一次海报：做到这一点！ ] I''ve finally gotten around to reading the book "Large-Scale C++Software Design" by John Lakos.Has anyone documented what parts of this book are now obsolete due toC++ language changes such as namespaces? or are now generallyconsidered bad advice?Feel free to reply here on a particular topic discussed in the book.I also noticed that John Lakos has a book in preparation called"Scalable C++: Component-Based Development" maybe this is the muchneeded 2nd edition.thanksMark[ See http://www.gotw.ca/resources/clcm.htm for info about ][ comp.lang.c++.moderated. First time posters: Do this! ] 解决方案 marktxx wrote: I''ve finally gotten around to reading the book "Large-Scale C++ Software Design" by John Lakos. Has anyone documented what parts of this book are now obsolete due to C++ language changes such as namespaces?Those recommendations were obsolete at the time the book was written. or are now generally considered bad advice?There''s a good repository of bad advise here: http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesignTo read LSCSD, imagine incorporating each guideline into your ownhabits.Some, such as where to put #include lines, are brilliant, crucial,and easy.Some, such as unit tests, are mission critical but hard.Some, such as Registered Package Prefixes, are still generally valid butshould not be slavishly applied. The book is still completely relevantbecause Lakos doesn''t just say "do this", he explains his ownresearch toarrive at each conclusion. Draw your own results, and question_everything_you read. Even the stuff that keeps up with the Standard. I also noticed that John Lakos has a book in preparation called "Scalable C++: Component-Based Development" maybe this is the much needed 2nd edition.Maybe it will cover CORBA, which is an over-researched and under-documentedcomponent system that appears to have much potential.--Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!![ See http://www.gotw.ca/resources/clcm.htm for info about ][ comp.lang.c++.moderated. First time posters: Do this! ] Phlip wrote: marktxx wrote: I''ve finally gotten around to reading the book "Large-Scale C++ Software Design" by John Lakos. Has anyone documented what parts of this book are now obsolete due to C++ language changes such as namespaces? Those recommendations were obsolete at the time the book was written.Are you kidding? At the time I first saw the book, none of thecompilers I was using supported namespaces. Even today, I findthat namespaces introduce so much additional confusion in thingslike function overloading (which isn''t simple to begin with)that I tend to avoid them, except maybe at the highest level.(I''m glad that the standard library is in a namespace, forexample.) or are now generally considered bad advice? There''s a good repository of bad advise here: http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesignI gave it a quick glance, but there didn''t really seem to bemuch useful information there. (There were a lot of unjustifiedopinions, but nothing concrete.) To read LSCSD, imagine incorporating each guideline into your own habits. Some, such as where to put #include lines, are brilliant, crucial, and easy. Some, such as unit tests, are mission critical but hard. Some, such as Registered Package Prefixes, are still generally valid but should not be slavishly applied. The book is still completely relevant because Lakos doesn''t just say "do this", he explains his own research to arrive at each conclusion. Draw your own results, and question _everything_ you read. Even the stuff that keeps up with the Standard.That sounds about like what I would say. All of the basicprinciples still apply. How you actually apply them in anygiven project will vary. I also noticed that John Lakos has a book in preparation called "Scalable C++: Component-Based Development" maybe this is the much needed 2nd edition. Maybe it will cover CORBA, which is an over-researched and under-documented component system that appears to have much potential.I agree. Corba seems to be almost moribond, but for most of theapplications I see, it would be a far better solution thanthings like XML, which are being used because they are "in".--James Kanze GABI SoftwareConseils en informatique orientée objet/Beratung in objektorientierter Datenverarbeitung9 place Sémard, 78210 St.-Cyr-l''école, France, +33 (0)1 30 23 00 34[ See http://www.gotw.ca/resources/clcm.htm for info about ][ comp.lang.c++.moderated. First time posters: Do this! ] kanze wrote: Are you kidding?No, I just didn''t notice I was posting to the moderated group. At the time I first saw the book, none of the compilers I was using supported namespaces. Even today, I find that namespaces introduce so much additional confusion in things like function overloading (which isn''t simple to begin with) that I tend to avoid them, except maybe at the highest level. (I''m glad that the standard library is in a namespace, for example.)The OP asked about what had become obsolete since. So maybe we agree thatthe advice about Registered Package Prefixes is as obsolete now as it wasback then. http://c2.com/cgi/wiki?LargeScaleCppSoftwareDesign I gave it a quick glance, but there didn''t really seem to be much useful information there. (There were a lot of unjustified opinions, but nothing concrete.)Feel free to edit it. The page - vaguely - attempts reveal the tension anddebate between prefixes and namespaces, and the book''s role in the debate.Of course this rapidly devolves to one "side" screaming the book is evilincarnate, and the other "side" trying to be rational. I agree. Corba seems to be almost moribond, but for most of the applications I see, it would be a far better solution than things like XML, which are being used because they are "in".I am currently learning CORBA Component Model, which might be worth all theacres of PDF devoted to how awesome it is...--Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!![ See http://www.gotw.ca/resources/clcm.htm for info about ][ comp.lang.c++.moderated. First time posters: Do this! ] 这篇关于大规模C ++软件设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！上岸，阿里云！