Здравствуйте, ., Вы писали:

>> Ну почему же.
>> static bool myCompare(std::string const& s1, std::string const& s2)
>> Здесь разве что проблема — не всякий компилятор заинлайнит вызов функции
>> по указателю.
.>Самая проблема выделена, это уже не функтор.

Ну и что? Главное, что это — локально объявленная функция.

Здравствуйте, Nazik, Вы писали:

N>1. http://openmp.org
N>2. OpenMP вполне можно считать индустриальным стандартом в распараллеливании существующих последовательных приложений приложений
N>3. Опять же, конкуренты конечно есть, но OpenMP поддерживается всеми распространенными компилерами (по крайней мере Microsoft, Intel, GNU), поэтому, вполне можно считать его чем-то очень стандартным.

Так писали уже, что с новым синтаксисом OpenMP и многие другие расширения будут легко и красиво прикручиваться к языку. Это может выглядеть так:

// было
#pragma omp parallel for
for(int i = 0; i < n; ++i)
{
    dst[i] = f(src[i]);
}

// стало
for [[omp::parallel]] (int i = 0; i < n; ++i) // можно сделать макрос
{
    dst[i] = f(src[i]);
}

Джоэл тут при том, что политика его компании — набирать самых лучших сотрудников, пусть они и стоят на порядок дороже. Характерная цитата:

Bottom Line it For Me.

The monthly rent for our offices, when fully occupied, will run about $700 per employee. <…> I suspect that $700 per person is on the high side for software developers throughout the world, but if it means we can hire from the 99.9 percentile instead of the 99 percentile, it'll be worth it.

(«Bionic Office»)

Кто-то спрашивал примерно год назад, что же такое экстраординарное выпускает Fog Creek, что им требуются такие сотрудники. Я не сразу понял, что ответ — ничего. На самом деле Джоэл представляется мне прагматичным человеком, который просто понял раньше других, что качество растет быстрее зарплаты.

В противоположность этому подходу, Егор где-то выше в этой ветке, обсуждая целесообразность использования Boost, противопоставлял профессиональных разработчиков бестолковым студентам, причем мне показалось, что предпочтение в его компании отдается отнюдь не первым. Естественно, если проект пишут за еду индусы™, то им нужно запретить не только Boost.

Хорошим разработчикам не нужно запрещать STL, или рефакторинг, или шаблоны, или исключения — они сами знают, когда и что принесет пользу. Вопрос не в этом, и он даже не связан с C++: на Java, Ruby, C#, Python, Nemerle и т. п. тоже можно писать плохой код, что бы ни говорил Влад. Вопрос в том, оправдано ли (нет, конечно) нанимать разработчиков, которым приходится что-либо запрещать, и до уровня которых должны будут опускаться все остальные.

E>Слабовата, конечно. Серьезная аргументация должна выглядеть иначе. Если для ваших задач необходим весь этот syntactic sugar, то не стоит ли подумать о языке программирования, лучше подходящем для ваших задач? Если же ваши задачи таковы, что вы вынуждены решать их на C++, так ли уж вам нужен весь этот syntactic sugar?

Эй, а зачем вам syntactic sugar существующего С++? Почему бы не писать на асме? А что, все можно реализовать, уже есть библиотеки, все прекрасно работает (ну и прочий бред, который вы там несли). Даже лучше, давайте писать в hex-е. Зачем нам, "суровым сибирским парням", все эти глупости с классами, операторами, да и этим долбанным непонятным и ненужным полиморфизмом, а? Все ведь и так можно написать, вроде?
Но, уважаемый, к счастью помимо абстрактной "возжности" решить задачу, хочется ее решить качественно (к тому же максимально расширяемо при минимальных затратах), удобно и просто.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Джоэл тут при том, что политика его компании — набирать самых лучших сотрудников, пусть они и стоят на порядок дороже.

То что они дороже еще не значит что они лучше
STL. Boost, С# и вся братия делалась что бы как раз удешевить работу программистов и снизить требования к их квалификации, однако пока что это слабо удается

Здравствуйте, Roman Odaisky, Вы писали:

RO>В противоположность этому подходу, Егор где-то выше в этой ветке, обсуждая целесообразность использования Boost, противопоставлял профессиональных разработчиков бестолковым студентам, причем мне показалось, что предпочтение в его компании отдается отнюдь не первым.
Ты понял неверно! В нашу компанию ещё и фиг устроишься

RO>Естественно, если проект пишут за еду индусы™, то им нужно запретить не только Boost.
Не знаю, не пробовал

RO>Хорошим разработчикам не нужно запрещать STL, или рефакторинг, или шаблоны, или исключения — они сами знают, когда и что принесет пользу.
Для этого они должны хнать очень широкий контекст. Кроме того, представлять себе коллективные эффекты от использования той или иной технологии...

С одной стороны, разве везед уже пишут прямой и прекрасный код? Зачем усугублять? ИМХО при коллективной разработке на C++ инстукция просто необходима

А с другой стороны, разве для программирования так уж часто нужны свои шаблоны, например? Если таки они нужны, то ИМХО и не страшно, что их использованию предшествует небольшая бюрократическая процедура обоснования нужды и получения разрешения. Это намного дешевле последующей поддержки/переноса кода написанного из эстетических соображений людей, которые пишут LISP-системы на кофеварках за выходные и для развлечениея

RO>...Вопрос в том, оправдано ли (нет, конечно) нанимать разработчиков, которым приходится что-либо запрещать, и до уровня которых должны будут опускаться все остальные.

Ответ в том, что коллективная работа, особенно работа звёзд, требует согласованности усилий...

Здравствуйте, eao197, Вы писали:

E>Это и сейчас можно. Но с ограничениями -- все что связано с шаблонами не может быть определено внутри функции.

Это ненадолго.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2187.pdf

You will always get what you always got
  If you always do  what you always did

E>Ты понял неверно! В нашу компанию ещё и фиг устроишься

неужто Google?

Здравствуйте, Awaken, Вы писали:

A>неужто Google?
АФАИК в Google STL любят...

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, c-smile, Вы писали:


E>К тому времени, когда появятся компиляторы C++0x на тормоза по разбору новых лексем вряд ли можно будет обращать внимание. Тем более, что шаблоны по любому будут добавлять тормозов больше, чем эти лексемы.

g++ уже поддерживает часть фич новой спецификации. И будет поддерживать всё очень быстро после принятия спеки.

J>Аргументация как-то слабовата, не находите, коллеги?

Конечно слабовата. С другой стороны, что-то в ней есть. Вместо того, чтобы идти по пути упрощения языка, он идет по пути усложнения, например, зачем-то ввели новые литералы — от примера с miles у меня волосы дубом встали.
Лямбда выражения хороши, когда синтаксис их интуитивно прост и понятен. В приведенном примере — нет, не понятен.
А саму статью в Педии я не читал