异常处理(EH)似乎是当前的标准,并且通过搜索网络,我找不到任何试图改进或替换它的新颖想法或方法(好吧,存在一些变化,但没有新颖的).
虽然大多数人似乎忽略它或只是接受它,但EH 有一些巨大的缺点:代码看不到异常,它会创建许多可能的退出点.乔尔在软件上写了一篇关于它的文章.比较goto完美,它让我再次思考EH.
我尽量避免使用EH,只使用返回值,回调或任何适合目的的东西.但是当你必须编写可靠的代码时,你现在就无法忽略EH:它从new可能抛出异常开始,而不是仅仅返回0(就像过去一样).这使得任何C++代码行都容易受到异常的影响.然后C++基础代码中的更多地方抛出异常...... std lib执行它,依此类推.
这感觉就像走在摇摇欲坠的地面上.所以,现在我们被迫关注异常!
但它很难,真的很难.你必须学会编写异常安全代码,即使你有一些经验,它仍然需要仔细检查任何一行代码是安全的!或者你开始在任何地方放置try/catch块,这会使代码混乱,直到它达到不可读状态.
EH取代了旧的干净确定性方法(返回值..),它只有一些但可以理解且易于解决的缺点,在您的代码中创建许多可能的退出点的方法,以及如果您开始编写捕获异常的代码(您是什么的)在某些时候被迫做某事),然后它甚至通过你的代码创建了许多路径(catch块中的代码,考虑一个服务器程序,你需要除了std :: cerr之外的日志工具..).EH有优势,但这不是重点.
我的实际问题:
以下代码工作正常,但为什么这是正确的代码？为什么foo()返回的临时的"c_str()"指针有效？我想,当输入bar()时,这个临时性已经被破坏了 - 但它似乎不是这样的.那么,现在我假设foo()返回的临时值将在调用bar()之后被销毁 - 这是正确的吗？为什么？
std::string foo() {
std::string out = something...;
return out;
}
void bar( const char* ccp ) {
// do something with the string..
}
bar( foo().c_str() );
我使用的协议基本上是TCP上的请求和响应协议,类似于其他基于行的协议(SMTP,HTTP等).
该协议有大约130种不同的请求方法(例如登录,用户添加,用户更新,日志获取,文件信息,文件信息......).所有这些方法都没有很好地映射到HTTP(GET,POST,PUT,...)中使用的广泛方法.这种广泛的方法会引入一些实际含义的后续曲折.
但协议方法可以按类型分组(例如用户管理,文件管理,会话管理......).
当前服务器端实现使用class Workerwith方法ReadRequest()(读取请求,由方法加参数列表组成),HandleRequest()(见下文)和WriteResponse()(写入响应代码和实际响应数据).
HandleRequest() 将为实际请求方法调用一个函数 - 使用方法名称的哈希映射到成员函数指向实际处理程序的指针.
实际的处理程序是一个普通的成员函数,每个协议方法有一个:每个都验证它的输入参数,做它必须做的事情并设置响应代码(成功是/否)和响应数据.
示例代码:
class Worker {
typedef bool (Worker::*CommandHandler)();
typedef std::map<UTF8String,CommandHandler> CommandHandlerMap;
// handlers will be initialized once
// e.g. m_CommandHandlers["login"] = &Worker::Handle_LOGIN;
static CommandHandlerMap m_CommandHandlers;
bool HandleRequest() {
CommandHandlerMap::const_iterator ihandler;
if( (ihandler=m_CommandHandlers.find(m_CurRequest.instruction)) != m_CommandHandler.end() ) {
// call actual handler
return (this->*(ihandler->second))();
}
// error case:
m_CurResponse.success = false;
m_CurResponse.info = "unknown or invalid instruction";
return true;
}
//...
bool Handle_LOGIN() {
const …我的问题更多的是历史性而非实际性:
theory language-features exception-handling language-design exception
谷歌+1按钮嵌入代码可以具有配置的javascript对象(例如" {lang:'de'}").
在普通的javascript中,这个对象将被创建并立即销毁,因为它没有被任何东西引用.
我想知道google脚本如何访问这个对象？
<script type="text/javascript" src="https://apis.google.com/js/plusone.js">
{lang: 'de'}
</script>
它似乎有效 - 除非您动态地将包含配置对象的脚本标记写入DOM.
不要误解我的意思 - OOP目前是构建大型代码库的最佳选择.
但是为什么人们会尝试将任何内容填入OO视图？
例如:每本关于OOP的教科书都包含一个"介绍示例",试图在OO继承和组合和聚合构造中表达我们现实世界的一个小视图.并且 - 同时 - 我们都知道它永远不会导致OO模型本身承诺的全能OO结构!作者刚刚创造了一种幻觉.
我个人认为,OO很适合构造代码,但它不适合代表真实世界的数据及其关系.恕我直言,关系模型是优越的,可能任何其他模型都是优越的.
在OO设计中,尽可能推荐构图而不是继承.因此,一流图书所暗示的基于全继承的世界对象的强大外观模型只是一种幻觉.那么,OO本身可能是一种幻觉？目前以组成为中心的OO模型只不过是具有一些标准化语法糖的普通数据结构 - 与OOP前方法没有太大区别.
另一个例子:想象一下真实复杂的现实世界模型.除了其他任何东西,还有石块和人类.在OO模型中,人类是哺乳动物,动物是有机生命形式等等(严格的刚性继承等级OO强加,你知道......).石块是非有机的东西,也许它们是刚体或其他什么,无关紧要.
如果你是一个艺术家,你必须找到一个石块,为一个给定宽度,高度和厚度的人类雕像制作一个好的"模板"(？),那么你必须写一堆特殊情况的OO代码到从人体模型和石块模型中检索这些属性.或者,您的整个世界模型都是为了支持几何查询而构建的 - 那么它很容易!但这导致得出的结论是,OOP以一种允许我们在不同用例中使用它的方式来表示数据.OOP只允许我们准确地表示我们事先设计的用例数据.不多了.除了那些预先确定的情况之外的任何使用只能通过大量的小问题来完成.关系模型至少试图以可重用的方式表示数据. (可重复使用:OOP曾经占用过那个词)
为什么那么讨厌？
我正在开发一个使用ORM的项目 - 它很糟糕.它是在对数据库进行建模时开始的(由于ORM限制),然后是时候学习ORM的来龙去脉(以及它的错误和进一步的限制),然后害怕隐含发生的东西(新东西();东西 - > save()创建了一个新行,但是"thing"的根源在哪里？为什么人们试图让对象尽可能"独立",但在后面创建更加根深蒂固的依赖于每个表单个怪物,与连接单身人士沟通..哦,我的上帝..我离题了).
在几行SQL和一个甜蜜的小查询API中可以完成的许多事情都是在数百甚至数千行"业务逻辑"代码中完成的(当然在应用程序层,而不是数据库中的数据)是,以及像count()或sum()这样的聚合函数便宜的地方.我认为人们在OOP工作时感觉更好.但这只是愚蠢的.
ORM的创建者只是想让用户远离"脏东西".但正是这些人不应该写ORM - 完美的例子:我坚信ORM创建者类型的人甚至不知道数据库表可以包含复合主键!;-)
那么,为什么OOP如此占领？这只是一个半生不熟的抽象,但是人们会为一切发誓,如果你问一些,他们甚至可能会告诉你,OOP将创造世界和平.
为什么OOP如此占领/垄断呢？
我不确定它在JavaScript中是否可行,所以我想我会问.:)
假设我们有100个要求要完成并希望加快速度.
我想做的是:
考虑到浏览器JavaScript不支持线程,我们可以"利用"这个async功能吗？你认为它会起作用,或者在JavaScript中存在固有的问题吗？
我正在尝试使用公钥加密签名并稍后验证文件.该文件是一个简单的纯文本文件,其中包含用于创作目的的用户信息.
我为公钥加密算法的C实现尝试了不同的站点,但我没有找到任何东西.许多站点都指向使用证书(x.509等),但这远远超出我的需要.我只是在寻找一种生成公钥和私钥的方法,并使用一种相对众所周知的算法来签名和验证文件.
有没有指向纯C实现的指针？重点是我可以重用的代码,而不是外部库.主要问题是我不想链接完整的lib及其依赖关系,以便拥有一个非常基本的公钥系统.
谢谢.