Inside the mind of the enemy: the community[转]

本文探讨了自由开源软件(FOSS)社区的优势与挑战,指出社区本身既是其发展的动力也是潜在的障碍。文章通过具体案例分析了Bazaar式开发模式下的领导力缺失问题,并提出短期内采取类似Cathedral式的开发管理方式可能有益。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Inside the mind of the enemy: the community

By Patrick McFarland

Online on: 21/11/2006

The path less traveled is still traveled

Now, before I continue, I must mention that, although I write this article for Free Software Magazine, and there is a gulf between ESR and Richard M. Stallman (also known as RMS, the patron saint of the Church of GNU, and the head of the Free Software Foundation), this article does not exist to promote either ESR's or RMS's point of view as the correct one, or even consider them grounded in this reality.

So, two weeks ago, I wrote about how business analysts lie, cheat, and perform dime-store magic tricks to make middle- and upper-management believe in fairy tales. And don't forget the rubber chickens, either.

A friend of mine, after reading that article, said something rather interesting: he said that what I wrote was a subset of ESR's essays. I thought about it for a moment, and I realized that he was right; I really did write about a subset, especially the last sentence: "Linux goes in all directions simultaneously."

ESR effectively wrote the same thing many years ago, and helped inspire hackers everywhere. He even inspired me to hack away at software, although my wizardry skills would make even Gandalf stifle a giggle. I, like ESR, wrote about the Bazaar's modus operandi based on observations.

To state this in a non-verbose way: we seem to have come to the same conclusion on this.

The implied action scene

So, where else does the FOSS community get tripped up? If business analysts are simply the ugly hunch-backed minions of the Bad Guy then who is next on the list? IP lawyers? No. Bill Gates and his vast Olympic-sized wallet? No (although this recent Novell thing isn't helping). RMS and ESR? No.

The next bad guy on the list is us. Yup, us: the community. The FOSS community itself is its own enemy. Not the worst enemy, mind you, but an enemy that still has to be dealt with. Before, I said that Linux goes in all directions simultaneously; this is both a strength and a weakness.

As a strength, this allows any individual to hack on any feature, any program, any anything and scratch his/her proverbial itch on whatever is bothering him. In this way, we often get interesting solutions to interesting problems. The worst bugs are fixed, the most wanted features are added, and the most annoying of either are dealt with in a quick and painful hacking session that often involves swearing like a drunken pirate.

However, as a weakness, this also means that leadership in some projects is non-existant or ineffectual. In Cathedral-style projects, your not-so-friendly neighborhood PHB (fueled by the lies from various ugly hunch-backed minions), although wrong 120% of the time, says what goes in a project. The PHB's vision is corrupt; but none-the-less, it still is a vision.

Now, some Bazaar-style projects do manage to wing it fine. The Linux Kernel itself is a good example, with Linus Torvalds acting as a benevolent overlord. He allows just the right amount of free-form hacking to go into the kernel, and refuses to commit patches that don't provide 100% useful content.

Other projects, however, are glowing examples of what not to do. GNOME, sadly, is one of those projects. Backed by the Free Software Foundation and the FOSS community as a whole, the GNOME project for many years just added lots and lots of feature creep and otherwise unnamed bloat. They seem to be digging themselves out from under that, but they have a long road ahead of themselves.

The GNOME project lacked true vision for those years, and feature creep and other long term development problems rushed in to fill that hole. Problem is, many projects are just like GNOME. Incidentally, few Cathedral-style projects suffer from lack of vision: those that do simply die off and are never heard from again. Bazaar-style development allows projects to be in a zombie state for long periods of time, where it is vastly expensive for a Cathedral-style project to do the same.

Another example: for years, XFree86 languished under the control of David Dawes (who also proved earlier on that a benevolent overlord actually has to be a benevolent), and Keith Packard had to go ahead and fork XFree86 (producing X.org, the now de facto X server for most Linux distributions) to solve this issue. Not only did Dawes lack vision, he got in the way of everyone who did have vision.

The Solution?

I hate to say this, but there may be no easy solution. Unlike in the Cathedral, the Bazaar has no official leadership. Linus, as did Dawes, as do the core development team of GNOME, only have limited control over their small section of the Bazaar; and even then, it is only for a limited time.

Someday Linux will be replaced, someday X will be replaced, someday GNOME will be replaced. In the Cathedral, nothing is ever thrown away, nothing is ever replaced, but here in the Bazaar something better always comes along. This is a strength, not a weakness.

Due to the fact that there are more people like Dawes than people like Linus running projects, the only solution would be to act like the Cathedral. For short periods of time, I believe Cathedral-style development can be beneficial to the FOSS community; someone with vision (corrupt or not) would control a project, driving development behind it, and have the project reach goals in specific time frames.

The future may prove that hybrids of both styles will provide better frameworks to deal with large projects.

内容概要:本文详细探讨了基于阻尼连续可调减振器(CDC)的半主动悬架系统的控制策略。首先建立了CDC减振器的动力学模型,验证了其阻尼特性,并通过实验确认了模型的准确性。接着,搭建了1/4车辆悬架模型,分析了不同阻尼系数对悬架性能的影响。随后,引入了PID、自适应模糊PID和模糊-PID并联三种控制策略,通过仿真比较它们的性能提升效果。研究表明,模糊-PID并联控制能最优地提升悬架综合性能,在平顺性和稳定性间取得最佳平衡。此外,还深入分析了CDC减振器的特性,优化了控制策略,并进行了系统级验证。 适用人群:从事汽车工程、机械工程及相关领域的研究人员和技术人员,尤其是对车辆悬架系统和控制策略感兴趣的读者。 使用场景及目标:①适用于研究和开发基于CDC减振器的半主动悬架系统的工程师;②帮助理解不同控制策略(如PID、模糊PID、模糊-PID并联)在悬架系统中的应用及其性能差异;③为优化车辆行驶舒适性和稳定性提供理论依据和技术支持。 其他说明:本文不仅提供了详细的数学模型和仿真代码,还通过实验数据验证了模型的准确性。对于希望深入了解CDC减振器工作原理及其控制策略的读者来说,本文是一份极具价值的参考资料。同时,文中还介绍了多种控制策略的具体实现方法及其优缺点,为后续的研究和实际应用提供了有益的借鉴。
<think>好的,我现在要解决用户的问题:如何在C++或Java中使用基于范围的for循环遍历enemy_list指针对象,并对每个Enemy对象进行操作。首先,我需要分清楚两种语言的语法差异,因为用户提到了C++或Java两种选项。 首先,用户提到enemy_list是一个指针对象的列表,所以需要明确在两种语言中,容器存储的是对象还是指针/引用。例如,在C++中,如果enemy_list是一个包含指针的容器(比如vector<Enemy*>),那么基于范围的for循环需要正确处理指针的解引用。而Java中,列表存储的是对象的引用,所以处理方式可能不同。 对于C++部分,假设enemy_list是类似vector<Enemy*>这样的类型。使用基于范围的for循环时,每个元素都是Enemy*类型。所以,在循环中,需要解引用指针来访问对象。例如: for (Enemy* enemy : enemy_list) { enemy->doSomething(); // 直接通过指针调用方法 } 但用户可能想操作对象本身,比如修改或访问成员。这时候如果列表里存的是指针,直接使用指针即可。但需要注意的是,如果列表是const或者需要拷贝,可能需要不同的处理。另外,在C++11及以后版本中,基于范围的for循环支持自动类型推导,所以写法应该是直接的。 而Java方面,假设enemy_list是List<Enemy>类型,那么基于范围的for循环(增强for循环)可以直接遍历对象引用: for (Enemy enemy : enemy_list) { enemy.doSomething(); } 但是,如果enemy_list里存储的是指针的类似物,比如在Java中实际上存储的是对象的引用,所以不需要特别处理,直接操作即可。Java中没有指针的概念,所有对象都是通过引用访问的。因此,用户在Java中的遍历应该没有问题。 不过,用户提到的是“指针对象”,可能在Java中可能是指某种包含指针的结构,但Java本身没有指针,所以可能用户是想处理对象引用。或者用户可能在C++中处理指针容器。需要进一步确认,但根据问题描述,用户可能是在C++中使用指针容器。 另外,用户提供的引用代码是Java的,所以可能更倾向于Java的解决方案。但问题明确询问C++或Java两种,所以需要分别说明。 总结: 对于C++,如果列表存储的是指针(如vector<Enemy*>),遍历时直接使用指针,并通过箭头运算符访问成员。如果需要修改指针指向的对象,同样可以直接操作。例如: for (Enemy* enemy : enemy_list) { enemy->attack(); // 假设Enemy有attack方法 } 对于Java,列表存储的是Enemy对象的引用,所以增强for循环可以直接遍历: for (Enemy enemy : enemy_list) { enemy.attack(); } 但需要注意,如果列表是List<Enemy>类型,并且enemy_list是有效的,否则可能抛出NullPointerException。 可能用户的问题是,如何在基于范围的循环中正确处理指针或引用,特别是当容器中的元素是指针时,如何避免拷贝对象或正确访问其成员。此时,C++中的处理需要注意指针的解引用,而Java则自动处理引用,无需特别操作。 另外,可能需要考虑在C++中使用const引用或引用来避免拷贝,但如果是指针的话,本身就不会拷贝对象。例如,如果容器是vector<Enemy*>&,那么循环中的enemy已经是Enemy*类型,无需额外处理。 最后,需要确保在两种语言中的语法正确性,并给出示例代码。同时,提醒用户注意空指针或悬垂指针的问题,尤其是在C++中操作指针容器时,需要确保指针有效。</think>在C++和Java中使用基于范围的for循环遍历指针/引用对象列表的实现方式如下: ### C++实现 当列表存储的是指针时(如$vector<Enemy*>$): ```cpp for (Enemy* enemy : enemy_list) { // 自动推导指针类型 enemy->takeDamage(10); // 使用箭头运算符访问成员 enemy->updateStatus(); // 指针直接操作对象 } ``` 注意事项: 1. 需确保指针有效性(避免空指针或野指针) 2. 修改操作直接影响原对象(指针访问的是原始数据) 3. 使用$auto$关键字可简写为:$for (auto enemy : enemy_list)$ ### Java实现 当列表存储对象引用时(如$List<Enemy>$): ```java for (Enemy enemy : enemy_list) { // 增强for循环 enemy.takeDamage(10); // 直接调用方法 enemy.updateStatus(); // 修改直接影响原对象 } ``` 注意事项: 1. Java集合只能存储对象引用(相当于自动处理指针) 2. 循环变量是对原对象的引用(不是拷贝) 3. 需要处理可能的$null$值(建议使用Optional处理)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值