我最近看到,logic_error如果命令行输入不可解析,boost program_options库会抛出一个.这挑战了我对logic_errorvs.的假设runtime_error.
我认为逻辑错误(logic_error及其派生类)是由于内部无法遵守程序不变量而导致的问题,通常是以内部API的非法参数形式出现的.从这个意义上讲,它们大部分相当于ASSERT,但意味着在已发布的代码中使用(与ASSERT不同,它通常不会编译成已发布的代码.)它们在调试/测试版本中集成单独的软件组件是不可行的情况下非常有用.或者失败的后果使得向用户提供关于无效不变条件的运行时反馈是很重要的.
类似地,我认为runtime_errors仅由程序员控制之外的运行时条件产生:I/O错误,无效的用户输入等.
但是,program_options显然(主要是？)被用作解析最终用户输入的一种方法,所以在我的心理模型中它肯定应该runtime_error在输入错误的情况下抛出.
我哪里错了？你是否同意异常打字的提升模型？
我正在对我开发的软件进行一些性能分析,并且我发现URL的全局字典上的查找大约占应用程序"加载"阶段时间的10%.该字典实现为C++ STL std :: map,它具有O(lg n)查找.我要将它移动到hash_map,它具有大致固定的时间查找.stl字符串类没有哈希代码属性,它肯定不会缓存哈希代码.这意味着每次查找都需要重新生成哈希码.
我怀疑缓存哈希码是值得的.这将意味着更改许多代码行以使用具有缓存哈希代码属性的新字符串类.鉴于当前实现在每次查找时都会记录(n)完整的字符串比较,我认为每次查找将其减少到基本上一次字符串遍历(通过散列函数)是一个很大的胜利.
有没有人有缓存字符串哈希码的经验？有没有证明值得付出努力？
得墨忒耳定律(确实应该是德米特的建议)说你不应该"穿过"一个物体来获取它们的子物体.如果您作为客户端需要执行一些非平凡的操作,那么大多数情况下您正在使用的域模型应该支持该操作.
REST原则上是一个愚蠢的对象层次结构.它就像资源/对象的文件系统,其中每个对象都可以有子对象.您几乎总能通过REST实现目标.您可以选择使用REST技术构建按惯例复合对象类型,只要提供者和客户端就更高级别的操作达成一致,您就可以避免覆盖范围.
那么,你如何平衡REST和Demeter？在我看来,它们并没有发生冲突,因为REST完全是关于超松散耦合的,因为提供商试图预测客户端的所有需求是没有意义的,而Demeter认为逻辑可以迁移到它的通过重构最自然的地方.
但是,您可以认为REST只是一个止损,直到您更好地了解您的客户.REST只是一个黑客？Demeter在任何服务器/客户端场景中都不现实吗？
我想使用依赖注入,但我必须在应用程序启动时设置自定义配置,就像在内存数据库中使用一样.
我做不到这一点.我想这必须在guice构建器中完成,但我不知道如何.
有没有where-object比使用父范围变量更好的方法将信息传递到过滤器脚本中的脚本块？
背景:
我有一个脚本,查找未签入和/或修改的源文件与源代码控制,并有一个参数,允许它进行更详尽的搜索.我where-object在一些地方使用脚本块对象包含在脚本范围的变量中,我根据脚本的输入参数自定义该变量.
因此,如果您要求彻底搜索,过滤器会将候选文件与所有TFS文件进行比较,以查看该文件是否不在源代码控制中,如果您选择不太彻底的搜索,则过滤器只会与已检查的内容进行比较 - 输出文件以查看文件是否已修改但未检出.
自定义脚本块指的是包含对源控件执行查询的结果的脚本范围变量.
所以我的问题是我想摆脱一个全局(脚本级)变量,并将所有必要的信息作为脚本块的参数传递给脚本块.如果我正在使用invoke-command,我会使用ArgumentList参数来执行此操作. Where-Object似乎没有那个.在脚本块中使用父范围变量引用的一个缺点是我无法更改这些变量,所以我不能进行延迟初始化(或者至少我还没弄清楚如何,不是一个专家Powershell的范围规则.)
有没有办法抑制PowerShell喜欢生成的每个命令行参数周围的括号引号,然后传递给包含空格的命令行参数的外部可执行文件？
情况如下:
解压许多安装程序的一种方法是使用以下形式的命令:
msiexec /a <packagename> /qn TARGETDIR="<path to folder with spaces>"
尝试从PowerShell执行此操作已经证明非常困难.PowerShell喜欢用双引号括起空格参数.以下行:
msiexec /a somepackage.msi /qn 'TARGETDIR="c:\some path"'
msiexec /a somepackage.msi /qn $('TARGETDIR="c:\some path"')
$td = '"c:\some path"'
msiexec /a somepackage.msi /qn TARGETDIR=$td
所有结果都生成以下命令行(由Win32 GetCommandLine()API报告):
"msiexec" /a somepackage.msi /qn "TARGETDIR="c:\some path""
这个命令行:
msiexec /a somepackage.msi TARGETDIR="c:\some path" /qn
结果是
"msiexec" /a fooinstaller.msi "TARGETDIR=c:\some path" /qn
似乎PowerShell在将表达式传递给外部可执行文件时,希望将表达式的结果用于表示引号中的一个参数.这适用于大多数可执行文件.但是,MsiExec非常关注它想要的引用规则,并且不接受PowerShell为路径生成的任何命令行.
有没有办法抑制这种行为？