如何在 Perl 中表示集合?

发布于 2024-09-18 11:56:40 字数 294 浏览 4 评论 0原文

我想用 Perl 表示一个集合。我通常做的是使用带有一些虚拟值的哈希,例如:

my %hash=();
$hash{"element1"}=1;
$hash{"element5"}=1;

然后使用 if (define $hash{$element_name}) 来确定元素是否在集合中。

这是常见做法吗?有什么改进的建议吗?

另外,我应该使用define还是exists

谢谢

I would like to represent a set in Perl. What I usually do is using a hash with some dummy value, e.g.:

my %hash=();
$hash{"element1"}=1;
$hash{"element5"}=1;

Then use if (defined $hash{$element_name}) to decide whether an element is in the set.

Is this a common practice? Any suggestions on improving this?

Also, should I use defined or exists?

Thank you

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

眸中客 2024-09-25 11:56:40

是的,以这种方式构建哈希集是一种常见的习惯用法。请注意:

my @keys = qw/a b c d/;
my %hash;
@hash{@keys} = ();

优于使用 1 作为值,因为 undef 占用的空间要少得多。这也迫使您使用 exists (无论如何,这是正确的选择)。

Yes, building hash sets that way is a common idiom. Note that:

my @keys = qw/a b c d/;
my %hash;
@hash{@keys} = ();

is preferable to using 1 as the value because undef takes up significantly less space. This also forces you to uses exists (which is the right choice anyway).

﹏雨一样淡蓝的深情 2024-09-25 11:56:40

使用 CPAN 上的众多 Set 模块之一。从您的示例来看, Set::LightSet::Scalar 似乎合适。


我可以用 CPAN 的常用论点来捍卫这一建议(不考虑可能的协同效应)。

  1. 我们如何知道现在和将来所需要的只是查找?经验告诉我们,即使是最简单的程序也会扩展和蔓延。使用模块可以预见到这一点。
  2. API 比临时实现更适合维护,或者需要阅读和理解一般代码的人,因为它允许在不同的抽象级别考虑部分问题。
  3. 与此相关的是,如果事实证明开销是不可取的,则可以通过删除间接或削减数据结构和源代码来轻松地将模块转变为简单模块。但另一方面,如果需要更多功能,则以相反的方式实现会更加困难。
  4. CPAN 模块已经过测试,并且在某种程度上经过彻底调试,也许 API 随着时间的推移也经历了改进步骤,而对于 ad-hoc,程序员通常会实现想到的第一个设计

很少有事实证明一开始就选择一个模块是错误的选择。

Use one of the many Set modules on CPAN. Judging from your example, Set::Light or Set::Scalar seem appropriate.


I can defend this advice with the usual arguments pro CPAN (disregarding possible synergy effects).

  1. How can we know that look-up is all that is needed, both now and in the future? Experience teaches that even the simplest programs expand and sprawl. Using a module would anticipate that.
  2. An API is much nicer for maintenance, or people who need to read and understand the code in general, than an ad-hoc implementation as it allows to think about partial problems at different levels of abstraction.
  3. Related to that, if it turns out that the overhead is undesirable, it is easy to go from a module to a simple by removing indirections or paring data structures and source code. But on the other hand, if one would need more features, it is moderately more difficult to achieve the other way around.
  4. CPAN modules are already tested and to some extent thoroughly debugged, perhaps also the API underwent improvement steps over the time, whereas with ad-hoc, programmers usually implement the first design that comes to mind.

Rarely it turns out that picking a module at the beginning is the wrong choice.

谈情不如逗狗 2024-09-25 11:56:40

我一直都是这样做的。我倾向于使用 exists 而不是 define 但它们都应该在这种情况下工作。

That's how I've always done it. I would tend to use exists rather than defined but they should both work in this context.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文