拆分 ICollection带有分隔符序列
这是针对 C# 3.5 的,
我有 ICollection,我试图将其拆分为单独的 ICollection,其中分隔符是一个序列。
例如
ICollection<byte> input = new byte[] { 234, 12, 12, 23, 11, 32, 23, 11 123, 32 };
ICollection<byte> delimiter = new byte[] {23, 11};
List<IICollection<byte>> result = input.splitBy(delimiter);
会导致
result.item(0) = {234, 12, 12};
result.item(1) = {32};
result.item(2) = {123, 32};
This is for C# 3.5
I have ICollection that I'm trying to split into separate ICollections where the delimiter is a sequence.
For example
ICollection<byte> input = new byte[] { 234, 12, 12, 23, 11, 32, 23, 11 123, 32 };
ICollection<byte> delimiter = new byte[] {23, 11};
List<IICollection<byte>> result = input.splitBy(delimiter);
would result in
result.item(0) = {234, 12, 12};
result.item(1) = {32};
result.item(2) = {123, 32};
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
最佳解决方案不是使用 SequenceEqual() 来检查每个子范围,否则您可能会迭代序列中每个项目的分隔符长度,这可能会损害性能,尤其是对于大型分隔符序列。可以在源序列被枚举时对其进行检查。
这是我要写的,但总有改进的空间。我的目标是具有与 String.Split() 类似的语义。
An optimal solution would not be using
SequenceEqual()
to check each subrange, otherwise you could potentially be iterating the length of the delimiter for every item in the sequence which could hurt performance, especially for large delimiter sequences. It could be checked as the source sequence is enumerated instead.Here's what I'd write but there's always room for improvement. I aimed to have similar semantics to
String.Split()
.调用它...
返回
Calling it ...
returns
这是我的看法:
Here is my take on it:
可能有更好的方法,但这是我之前使用过的一种方法:对于相对较小的集合来说它很好:
我目前没有打开 IDE,因此我无法按原样编译,或者可能会有一些漏洞需要插头。但这是我遇到这个问题时开始的地方。再次,正如我之前所说,如果这是针对大型集合,它会很慢 - 因此可能还存在更好的解决方案。
There are probably better methods, but here's one I've used before: it's fine for relatively small collections:
I don't have my IDE open at the moment, so that my not compile as-is, or may have some holes you'll need to plug. But it's where I start when I run into this problem. Again, as I said before, if this is for large collections, it'll be slow- so better solutions may yet exist.