- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
#include <iostream>
#include <string>
#include <utility>
#include <tuple>
#include <array>
#include <vector>
#include <algorithm>
#include <iterator>
int main() {
const std::array< const std::pair<const int, const std::string>, 3 > a {{{1,"2"}, {3,"4"}, {5,"6"}}};
std::vector<std::string> r;
std::transform(std::begin(a), std::end(a), std::back_inserter(r), static_cast<std::string const& (*)(const std::tuple<const int, const std::string>&)>(std::get<1, const int, const std::string>));
std::copy(std::begin(r), std::end(r), std::ostream_iterator<const std::string>(std::cout, " "));
return 0;
}
У нас новичку на собеседовании предложили продемонстрировать работу (без конкретики) с кортежами и итераторами.
Что вы можете сказать про его умения, характер и состояние психики? А вы бы этого взяли на работу?
http://liveworkspace.org/code/2DW59a$0
Не совсем удачный вопрос, имхо. Не лучше ли задать что-то более конкретное, и посмотреть как он это реализует?
По итогу написанного (написал геттер/конструктор синглтона) задали ровно один вопрос "Табы или пробелы?".
До сих пор задумываюсь, зачем это было?
Ответил: "табы".
Сказали: "ок", и больше этот листочик в руки не брался.
int main() {return 0;}
Да что тут говорить?
Еще одна крестоблядь.
Ничего, потому что непоказательно.
>А вы бы этого взяли на работу?
Если он всегда пишет такой write-only код, то нет. Но опять же непоказательно.
Хуй там.
Если он пытался подавить смех когда демонстрировал - то да. 🙂
Я бы вопросы получше выбирал. Для меня важно что человек способен от начала до конца, через все фазы разработки, задачу самостоятельно сделать. И очень важно способен ли он решение эффективно адаптировать к новым требованиям - и в результате адаптации из оригинала не получается говно. С чистого листа ваять многие умеют - с подстраиванием под новые требования всегда сложнее.
Чего я до сих пор не знаю как определять, это умеет ли человек работать под давлением и выставлять приоритеты. Эти две взаимосвязаные вещи тоже очень часто бывают нужны.
Чистоган тяжело идёт 🙁
Слушай, а сколько сейчас времени, не знаешь? Так, примерно можешь почувствовать?
auto p = new auto(42);
Хрена....
TypeName Demangler из снипетов lws
кто-то побаловался и немного почистил код
а вообще в крестах не хватает car\cdr (Lisp), fst\snd (Haskell) или std::select1st\std::select2nd (STLPort)
а вообще этот стасик_каст и указание всех шаблонов (get<...>) вручную для выбора правильной сигнатуры убивает всю красоту кода.
вот если бы еще можно было auto засунуть в лямбду, вместо ущербного decltype...
C++14
Даже рекурсивный вывод обещали (и без {} ):
auto fac=[](auto i) i*fac(i-1)
чревато
потыкай в него веточкой, а то он только притворяется загруженным и уставшим
абсолютизм в итоге рулит
Нужно время, чтобы приучить людей работать с умом, не оправдываясь нехваткой времени.
В общем не важно.
(Вот потому я за здоровую паранойю).
Накодил неструктурированный код и сдал его.
Ну что с него взять? Правильно, ничего.
Ну с поддержкой С++11 и всего такого.
ВизуалСтудию и другую монструозную проприетарщину не предлагать.
2 oe: IDEA
А что используете вы?
Удивило другое: почему крестоблядям не использовать истинно крестоблядские среды Qt, CodeLite, KDevelop, Code::Block?
Я юзаю православный Emacs, мне пока больше ничего не надо.
Не-не-не. Так нечестно. Тут всё должны предлагать гипернавороченные иде, а потом пришёл бы @wvxvw и сказал бы эту фразу, с таким видом будто все пидарасы.
Но вопрос в другом - какие иде поддерживают больше всякого пиздеца из нового стандарта.
Тут-то emacs, я уверен, аутсайдер. Вообще парсинг нынешнего С++11 - нетривиальнейшая задача.
тратить гиг оперативы и смотреть на тормоза одного_из_редакторов_почти_запиливших_в_ себя_анализатор_шланга - не для слабонервных
разве это не должно быть преимуществом джавы перед заведомо монструозными крестами - упрощенный синтаксис, отсутствие инстанциирования тысяч темплейтов, нет операторов и прочих путанных adl, нет тех же инклюдов - почему анализ джавы потребляет так много?
студия с решением на пару М кода с ассистом, держащим в голове это все + почти весь буст жрет 150-200М
если считать джавопрограммой jvm и кучу библиотек для как ты правильно выразился перекладывания xml в бд, то тогда засчитай за среднюю сишкопрограмму еще рантайм, ядро и оконную среду
отличие крестопроекта в том, что он из сорцов цепляет все эти мегастроки кода, а не шуршит по индексируемым бинарным пакетам, и потому потребление памяти и мощностей на обслуживание такого крестопроекта должно быть выше, что никак не согласуется с поведением лучшей среды для джавы (тм)
ну и то, что ты показал - это нечто уровня project, теперь домножь на 20, чтобы получить solution, о котором я говорю
Твои претензии вполне понятны, не совсем понятны выводы. Идея говно? Возможно. Но опыт жабка+идея vs. сишарпик+вижуалстудия безоговорочно в пользу первого.
Я, как ты понимаешь, вполне терпимо отношусь к инструментам, которые люди используют при разработке. Каждый должен работать с тем, с чем он может быть продуктивен. Тебе удобно со студией - отлично. Я не против.
на дворе 2013 год, а нет идеальной бесплатной полнофункциональной иде
где моё дешево, быстро и качественно?
ну и компиляция обогревает помещение в основном из-за шаблонов - инфа 100%
доконкатенировать файлы, и так лежащие в быстрой памяти (кеш диска + кеш компилятора (в нем файл может быть уже разобран даже)) не очень много времени занимает
Интересно, для плюсцов возможна такая batch компиляция?..
компиляцией всего из какой-нибудь папки должна заниматься система сборки
параллелизацией этого процесса - она же (-j, /MP)
скормить крестокомпилятору список файлов - не видел такого использования
вендорам проще оставить вопросы оптимизации параллельной работы N одинаковых исполняемых файлов операционной системе (там уже пусть горбатится и префетч, и не дублирование страниц параллельных процессов)
при скармливании devenv/msbuild файла проекта (в котором содержится список) скорее всего никак не отличается от вызова компилятора пофайлово
ну а так - в вопросах ускорения крестокомпиляции еще непаханное поле для оптимизации, основной ингибитор - инстанциирование шаблонов, и это ускорить можно только предварительным разбором и переводом шаблонов в специальный индексированный ast-вид (я так понимаю, в прекомпилированном заголовке происходит именно это), так что эволюция зоопарка компиляторов даёт хоть небольшую, но возможность пользователю вручную озаботиться прекомпилированным заголовком (выбешивает, кстати, что в вижуал студии невозможно настроить цепочку прекомпилированных заголовков, это было бы удобно, а так приходится кроссплатформенные вещи ограничивать)
насчет удобного получения результатов компиляции - сильно зависит от конкретного компилятора, в общем случае стоит надеяться только на ручной парсинг stdout/stderr от компилятора - unix way, чо, в частном - чем компилятор современней, тем богаче его возможности - тот же clang в виде положительного примера и старое барахло cl в виде отрицательного
gcc недалеко ушел от cl, но судя по гуглу в нем есть хотя бы какой-нибудь gcc-xml (но не юзал, не знаю насколько удобно)
ЗЫ. В Федоре недавно ее стали по умолчанию устанавливать, если попросить установить gcc / build tools.
судя по их описанию, они кешируют .o файлы, либо -E результат препроцессинга
про .o - накой это надо, когда нормальная система сборки (да тот же gnu make) не будет пересобирать .o файл, если все, от чего он зависит, старше имеющегося результата
разве что ускорить clean+build+clean+build+... - типа ничего не меняем, но постоянно чистим - молотим для красивой таблички
типичная ситуация, при которой билдится лавинным эффектом - изменили хедер, даже тупо пробел, и везде где он включен - собирается вперед и с песней
ну, тут -E может помочь
а может и не помочь - например, добавили один метод в класс, которым должен воспользоваться один объектник из десятка - но все 10 будут пересобираться
так что как обычно всё неидеально и напрямую следует из природы с++
среда in-time может отслеживать радикальность изменений и сообщать об этом компилятору, но это уже совсем хардкор
Многих vi/emacs устраивает. Вообще людям всегда чего-то не хватает.
Вот на дворе 2013 год, а нет удобного полнофункционального говнокода без сумасшедших школьников c единственно, абсолютно верным мнением и раскалённой серебрянной пулей в жопе.
Это как мне недавно попалось описание языка, который изобрели Самсунг для встраиваемых систем (телевизоров), не дословно, но как-то так: "Мы взяли все самое лучшее из наших любмых языков: Сишарпа, Луа и Яваскрипта и создали наш новый язык!" - ну там как бы вообще полный пиздец. На Скале хоть со скрипом писать можно, и в принципе можно понять людей, которые бы ее выбрали вместо Явы. Но если выбирать Камл / Скала... то тут даже вопроса не должно возникнуть...
В мире есть великое множество систем билдов хороших и разных. Нафиг они изобрели еще одну работающую хуже чем всео остальные?
typical
> CodeLite, KDevelop, Code::Block
Фу фу фу. Мне иногда кажется, что создатели этих иде хотели украсть идею у Microsoft Notepad.