Решение интересное но непрактичное. Придётся всех заставить писать std::vector<boost::mpl::_1> чтобы использовать ваш класс, и это прямо скажем неочевидно для тех кто внутрь смотреть и не собирается.
Если мы знаем что контейнер это не массив а контейнер std или boost (да и вообще большинство контейнерописателей value_type не забывают затайпдефить), то можно обойтись так(если конечно архитектура проекта позволяет):
template <typename Container>
struct AA {
typedef Container type;
typedef typename Container::value_type valueType; // то что было T в вашем случае
};
можно добавить enable_if для value_type если надо…
Если речь про gcc то -Wunreachable-code удалили вроде пару лет назад и по-моему он тупо игнориться сейчас.
-Weffc++ полезно иногда включать, но в больших проектах ни у кого не хватает духу его оставить — задалбывают параноидальные ворнинги про необходимую инициализацию всего в конструкторе. Там сейчас собственно есть предложение разделить Weffc++ на несколько отдельных частей, надеюсь к 5-му gcc разделят :).
Ещё кстати -Wshadow полезен.
Есть ещё много флажков но они не одинаково полезны для всех случаев.
Intel наряду с open-source обычно продают и коммерческую версию, ну например тем кого GPL не устраивает или кого на работе вынуждают покупать с поддержкой. В качестве примера сходу — TBB. Ну и полно совсем не open-source продуктов которые делают те же программисты.
В вашем случае open-source вообще не вариант наверное — продукт можно использовать и никто никогда не узнает был использован платный продукт или open-source. А учитывая ваш ценник — многие смогут подавить угрызения совести достаточно легко. :) Но никто вас и не заставляет ваять open source продукт под линукс, как я уже писал тот же интел клепает коммерческие не open-source продукты под linux без проблем.
Вот лично мне вообще трудно понять зачем такой продукт на машине пользователей а не на сервере с jenkins'ом каким-нибудь. Нет я понимаю что кому-то оно нужно, но многих бы устроил и вариант запуска его только на сборочном сервере. Я не поленился зашел на ваш сайт и увидел что в доках описана какая-никакая интеграция с hudson(правда опять под неправославной виндой, но это можно пережить если пишешь мультиплатформенный продукт), но есть одно «но» — цена на 1 и 5 лицензий одна и та же и совсем не демократичная… Хотя не мне вам советовать какую цену назначать, но обычно всё же есть возможность купить одну-единственную лицензию дешевле чем 5.
В частности не совсем согласен, но думаю каждому на шее голова на то и дана чтобы следовать духу, а не букве правил и выбирать оптимальное решение в каждом конкретном случае.
Извиняюсь — огромный ошибочно написал (он огромный визуально по сравнению с численной константой, надо было уточнить что я имел в виду). Я конечно имел в виду небольшой 10-20-ти строчный текстовый дамп не более 80 символов в строку. Так вот я не уверен что копипастить такой кусок в несколько тестов это правильно.
Явность тестовых данных
Правило: Все тестовые данные (как входные, так и выходные), ровно как и данные читаемые из окружения или пишущиеся в окружение, должны присутствовать в теле теста.
Если я правильно понял что тут написано, то если у меня в качестве входных данных например огромный многострочный текстовый дамп который годится для нескольких тестов, мне его всё равно копипастить в тело каждого теста? Это сомнительное правило на мой взгляд.
1. Я думаю тут ожидалась ссылка на главу стандарта c++, но в нём таких слов нет насколько я помню.
2. Если отвлечься от стандарта и вернуться к реальности, то #pragma once это нормально — сейчас сложно найти компилятор который не поддерживает её. Но __declspec это как минимум windows-specific (вообще-то microsoft specific).
Думаю чтобы избежать подобных придирок надо было указать что речь только про MSVC либо чуть усложнить DllSwitch.h добавив поддержку для gcc хотя бы (ссылка для изучения: gcc.gnu.org/wiki/Visibility )
Не надо хоронить gdb просто из-за того что он консольный и из коробки не очень красив на первый взгляд. Но с gdb -tui уже выглядит получше(есть лэйауты с листингом, регистрами и тп), и для тех кто не живет в дебагере каждый день и вообще дизассемблерный код смотрит раз в месяц и реже — вполне уже пригоден. Может пригоден и для тех кто активно дебагит и смотрит ассемблерный листинг каждый день, но так как я к таким не отношусь — судить не возьмусь. Плюс при должной фантазии gdb можно использовать для самых разных целей, как пример: poormansprofiler.org/.
P.S. Осуждать инструмент которым сами и не пытались пользоваться, это как-то не очень хорошо наверное…
Я могу согласиться что C++ не по настоящему высокоуровневый(хотя тут скользкая терминология, формально-то высокоуровневый). Но учитывая задачу(gcc) и все факторы, думаю что он единственная реальная альтернатива C в сегодняшних реалиях. Ну и с учетом принятого но пока не особенно реализованного и тем более грядущего стандартов не так уж там всё и плохо.
Ну не на Java же писать? Чтобы оно заработало с той же скоростью всё равно пришлось бы опускаться до байтиков и вышло бы ещё уродливее чем на C++. Да и неправильно это — яйцо рождающее курицу. :)
P.S. Вы серьёзно думаете что для такого большого проекта как gcc лучше C или вам просто за державу за C обидно? Не слышали отзывов про код gcc от не последних людей пытающихся разобраться в нём? Поверьте там нету восхищения препроцессором и танцами вокруг куцых возможностей C. Да и когда приходится что-то поменять глобально на это уходило о-о-очень много времени потому что там был замечательный препроцессорный C код. Цитату одного из разработчиков gcc что «пытаться заставить бегемота танцевать не так уж и весело» (за дословность не поручусь, но примерно так) тоже не слышали?
P.P.S. Я не против C, но доводы за и против C++ уже минимум два десятилетия вроде как обсуждают — неужели вы их не слышали? Или у вас телевизор только Столлмана показывает? И тот же clang написанный на ненавистном вам C++ и развивающийся с неслабой скоростью тоже мимо вас как-то пролетел незаметно?
Должно хватить. У меня одна цифромолотилка сейчас запущена на бесплатном лимите. Около 50-80К тасков в сутки запускается и при этом используется меньше 90% лимита CPU. Правда пришлось пооптимизировать, но у меня большинство запускаемых тасков пишут/удаляют/изменяют данные, у вас же будет в основном чтение — а оно почти не жрёт CPU.
Не уверен что Namespaces API без особых модификаций кода удастся применить если уже что-то было сделано руками в этом направлении. Да и как я понял там в datastore в «Key» инфа о Namespace будет, соответственно как минимум придётся делать «миграцию» данных. Но в целом это нововведение конечно сильно облегчит жизнь при создании новых приложений.
С примером полёт мысли вроде вполне понятен. Правда глядя на проблему совсем уж сверху, видна довольно узкая ниша этого решения, что впрочем автор и отмечает.
Когда-то я решал похожую(на твой пример) задачу и в итоге пришёл к выводу что в большинстве случаев когда возникают похожие проблемы/вопросы, то надо посмотреть в сторону Guice ну или прочих DI(dependency injection) фреймворков. Конечно не всегда и не каждому это подойдёт(да и не всем дадут менять настолько глобально то что и так работает), но наверное стоит отметить такой вариант тоже где-нибудь в послесловии — пусть люди смотрят уже что им лучше в каждом конкретном случае.
На регистрации дали анкету — там же я сказал что нету ручки и мне её дали. Правда потом я удачно порезался об бумагу(не знаю как мне это удалось) и анкета получила подпись кровью — во избежание сдавать не стал.
Так вот доклад про Gears мне понравился — парень бойко рассказывал и отвечал на вопросы. Так как про gears я знал только общую инфу было интересно.
Больше я ни на что не пошёл. Удивившись как неактивно поедаются запасы еды, на всякий случай есть не стал. :)
Я сходил на один доклад — Gears. Он был после обеда, так что когда я туда приехал мелкософтских диверсантов не было уже. На регистрации действительно выдали гигантский беджик, который при внимательном рассмотрении оказался ещё и картой и расписанием.
Если мы знаем что контейнер это не массив а контейнер std или boost (да и вообще большинство контейнерописателей value_type не забывают затайпдефить), то можно обойтись так(если конечно архитектура проекта позволяет):
template <typename Container>
struct AA {
typedef Container type;
typedef typename Container::value_type valueType; // то что было T в вашем случае
};
можно добавить enable_if для value_type если надо…
Ну и в случае с C++11 тут вторым комментом ответ.
-Weffc++ полезно иногда включать, но в больших проектах ни у кого не хватает духу его оставить — задалбывают параноидальные ворнинги про необходимую инициализацию всего в конструкторе. Там сейчас собственно есть предложение разделить Weffc++ на несколько отдельных частей, надеюсь к 5-му gcc разделят :).
Ещё кстати -Wshadow полезен.
Есть ещё много флажков но они не одинаково полезны для всех случаев.
В вашем случае open-source вообще не вариант наверное — продукт можно использовать и никто никогда не узнает был использован платный продукт или open-source. А учитывая ваш ценник — многие смогут подавить угрызения совести достаточно легко. :) Но никто вас и не заставляет ваять open source продукт под линукс, как я уже писал тот же интел клепает коммерческие не open-source продукты под linux без проблем.
Вот лично мне вообще трудно понять зачем такой продукт на машине пользователей а не на сервере с jenkins'ом каким-нибудь. Нет я понимаю что кому-то оно нужно, но многих бы устроил и вариант запуска его только на сборочном сервере. Я не поленился зашел на ваш сайт и увидел что в доках описана какая-никакая интеграция с hudson(правда опять под неправославной виндой, но это можно пережить если пишешь мультиплатформенный продукт), но есть одно «но» — цена на 1 и 5 лицензий одна и та же и совсем не демократичная… Хотя не мне вам советовать какую цену назначать, но обычно всё же есть возможность купить одну-единственную лицензию дешевле чем 5.
…
создастся o5
деструкторы будут вызваны в обратном порядке: o5, временный объект и o1
…
Вместо o5 должно быть o6.
В частности не совсем согласен, но думаю каждому на шее голова на то и дана чтобы следовать духу, а не букве правил и выбирать оптимальное решение в каждом конкретном случае.
Правило: Все тестовые данные (как входные, так и выходные), ровно как и данные читаемые из окружения или пишущиеся в окружение, должны присутствовать в теле теста.
Если я правильно понял что тут написано, то если у меня в качестве входных данных например огромный многострочный текстовый дамп который годится для нескольких тестов, мне его всё равно копипастить в тело каждого теста? Это сомнительное правило на мой взгляд.
2. Если отвлечься от стандарта и вернуться к реальности, то #pragma once это нормально — сейчас сложно найти компилятор который не поддерживает её. Но __declspec это как минимум windows-specific (вообще-то microsoft specific).
Думаю чтобы избежать подобных придирок надо было указать что речь только про MSVC либо чуть усложнить DllSwitch.h добавив поддержку для gcc хотя бы (ссылка для изучения: gcc.gnu.org/wiki/Visibility )
P.S. Осуждать инструмент которым сами и не пытались пользоваться, это как-то не очень хорошо наверное…
Я могу согласиться что C++ не по настоящему высокоуровневый(хотя тут скользкая терминология, формально-то высокоуровневый). Но учитывая задачу(gcc) и все факторы, думаю что он единственная реальная альтернатива C в сегодняшних реалиях. Ну и с учетом принятого но пока не особенно реализованного и тем более грядущего стандартов не так уж там всё и плохо.
Ну не на Java же писать? Чтобы оно заработало с той же скоростью всё равно пришлось бы опускаться до байтиков и вышло бы ещё уродливее чем на C++. Да и неправильно это — яйцо рождающее курицу. :)
P.S. Вы серьёзно думаете что для такого большого проекта как gcc лучше C или вам просто
за державуза C обидно? Не слышали отзывов про код gcc от не последних людей пытающихся разобраться в нём? Поверьте там нету восхищения препроцессором и танцами вокруг куцых возможностей C. Да и когда приходится что-то поменять глобально на это уходило о-о-очень много времени потому что там был замечательный препроцессорный C код. Цитату одного из разработчиков gcc что «пытаться заставить бегемота танцевать не так уж и весело» (за дословность не поручусь, но примерно так) тоже не слышали?P.P.S. Я не против C, но доводы за и против C++ уже минимум два десятилетия вроде как обсуждают — неужели вы их не слышали? Или у вас телевизор только Столлмана показывает? И тот же clang написанный на ненавистном вам C++ и развивающийся с неслабой скоростью тоже мимо вас как-то пролетел незаметно?
Когда-то я решал похожую(на твой пример) задачу и в итоге пришёл к выводу что в большинстве случаев когда возникают похожие проблемы/вопросы, то надо посмотреть в сторону Guice ну или прочих DI(dependency injection) фреймворков. Конечно не всегда и не каждому это подойдёт(да и не всем дадут менять настолько глобально то что и так работает), но наверное стоит отметить такой вариант тоже где-нибудь в послесловии — пусть люди смотрят уже что им лучше в каждом конкретном случае.
На регистрации дали анкету — там же я сказал что нету ручки и мне её дали. Правда потом я удачно порезался об бумагу(не знаю как мне это удалось) и анкета получила подпись кровью — во избежание сдавать не стал.
Так вот доклад про Gears мне понравился — парень бойко рассказывал и отвечал на вопросы. Так как про gears я знал только общую инфу было интересно.
Больше я ни на что не пошёл. Удивившись как неактивно поедаются запасы еды, на всякий случай есть не стал. :)