我正在看Don Clugston的FastDelegate迷你库,并注意到一个奇怪的语法技巧,具有以下结构:
TemplateClass< void( int, int ) > Object;
几乎看起来好像函数签名被用作模板实例声明的参数.
这种技术(其在FastDelegate中的存在显然是由于一个Jody Hagins)被用于简化模板实例的声明,其具有半任意数量的模板参数.
也就是说,它允许这样的事情如下:
// A template with one parameter
template<typename _T1>
struct Object1
{
_T1 m_member1;
};
// A template with two parameters
template<typename _T1, typename _T2>
struct Object2
{
_T1 m_member1;
_T2 m_member2;
};
// A forward declaration
template<typename _Signature>
struct Object;
// Some derived types using "function signature"-style template parameters
template<typename _Dummy, typename _T1>
struct Object<_Dummy(_T1)> : public Object1<_T1> {};
template<typename _Dummy, typename _T1, typename _T2> …我正在尝试为PHP中的名称编写一个合理宽松的验证器,我的第一次尝试包含以下模式:
// unicode letters, apostrophe, hyphen, space
$namePattern = "/^([\\p{L}'\\- ])+$/";
这最终传递给了一个电话preg_match().据我所知,这适用于你的vanilla ASCII字母表,但似乎惹上像Ă或张这样的尖锐字符.
这个模式本身有什么问题吗？也许我期待\p{L}比我想的更多的工作？
或者它与传入输入的方式有关？我不确定它是否相关,但我确实确保在表单页面上指定UTF8编码.
我从Foursquare的场地搜索API得到了一些不稳定的结果,我想知道是否有人有关于如何处理输入参数以获得最"直观"结果的任何提示.
例如,假设我正在使用Google Maps API在"纽约,纽约"周围搜索名为"Ise Sushi"的场所,该场地相当于(lat:40.7143528,lon:-74.00597309999999).插入Foursquare Venue API,我们得到:
https://api.foursquare.com/v2/venues/search?query=ise%20sushi&ll=40.7143528%2C-74.00597309999999
这会产生相当令人沮丧的结果:我正在寻找的场地最终位于列表的第11位.有趣的是,降低坐标的精度似乎会产生更好的结果.例如,假设我们将坐标舍入为3位有效数字:
https://api.foursquare.com/v2/venues/search?query=ise%20sushi&ll=40.7%2C-74.0
这一次,我正在寻找的场地最终排在第二位,即使它实际上离搜索中心更远(1072米,使用第一个查询时为833米).
另一个似乎有助于提高搜索质量的修改是用下划线代替空格来分隔我们的搜索词.例如,这是带下划线的原始查询:
https://api.foursquare.com/v2/venues/search?query=ise_sushi&ll=40.7143528%2C-74.00597309999999
这产生了最直观的结果:我正在寻找的场地首先出现,并伴随着另一个结果,"伊势餐厅"(被标记为"寿司餐厅").对于它的价值,这实际上似乎是在Foursquare自己的网站上进行的相同搜索的结果集.
我很好奇我应该从中吸取哪些教训.我应该降低坐标的精度吗？我是否应该使用下划线连接我的搜索字词,如果是,那是否会限制用户订购搜索字词的方式？
这或多或少是过去Stack Overflow问题的以框架为中心的版本,该问题是关于MVC应用程序的大多数介绍性材料如何在模型,视图和控制器之间呈现紧密耦合.例如,您将拥有一个由用户控制器修改的用户表,用户控制器又将过滤后的数据推送到用户视图.我的印象是很多MVC框架也倾向于反映这种模式.这一切都很好,很好,但除了用HTML表单构建和显示单调的事物列表之外,它从来没有真正引导我.
现在正在研究的MVC框架是Lithium,它作为巧妙的PHP5.3编码技术的案例研究似乎非常有趣.一方面,Lithium有一个Model类,它在各个表周围提供包装器对象,并抽象出一些简单的查询.另一方面,它有一个很好的约定,即路由URL到控制器对象上的方法调用,然后呈现给显示模板.
但是在这期间,我发现自己不知道将表A中的数据与表B到Z中的数据相关联的所有有趣逻辑放在哪里.或者至少,我不知道在哪里放置这样的逻辑的方式与框架的设计一致.根据我的理解,Lithium的Model抽象除了消除一些行级插入/更新/删除样板外没什么作用,控制器/视图架构似乎主要是关于用户界面.我不想在Controller从URL请求接收路由函数调用的同一个类中放入大量业务逻辑.
我的直觉是用一堆我自己的代码填补空白,这些代码或多或少完全存在于框架之外.我不确定我是否应该期待更多,但考虑到Lithium中其他所有内容的结构是如何严格的,它感觉某种程度上不令人满意,就像我刚刚推出了自己的样板减少代码而没有花费很多资源来解决这个问题.一个大框架.
我在这里错过了什么？是否有推荐的架构或哲学来使用这种类型的框架？
Eclipse 的 Open Resource 对话框允许您根据键入的查询搜索项目文件，但默认行为是仅返回以给定查询开头的那些文件名。*如果您希望将查询解释为任意文件名子字符串，则必须在前面加上通配符。
我会说 95% 的情况下，我想在前面加上通配符。类似对话框（例如 Visual Assist 或 Komodo 中的对话框）的默认行为是假设查询可以是文件名的任何部分。我想知道是否有办法强制 Eclipse 以相同的方式工作。
当在双引号字符串插值中引用对象时,既to_s不会也不会to_str被调用.例如:
# UPDATE: This example actually works as expected. See update below.
class Foo
def to_s
'foo'
end
def to_str
to_s
end
end
"#{Foo.new}" # result: "#<Foo:0x007fb115c512a0>"
我不认为我可以做些什么来赚取回报价值"foo"？
UPDATE
道歉,但这段代码确实有效.另一段代码中的错误.