Facebook (https://www.facebook.com/notes/facebook-engineering/folly-th...) объявил об открытии под лицензией Apache исходных текстов библиотеки Folly (https://github.com/facebook/folly/tree/master/folly), в рамках которой представлена большая коллекция C++ классов, дополняющих стандартные библиотеки C++ и набор Boost. Примечательной особенностью библиотеки является изначальная ориентация на предоставление максимально возможной производительности.
Код библиотеки является стабильным и уже давно используется в различных подсистемах Facebook. Кроме того, библиотека очень легко интегрируется в сторонние проекты и проста в использовании. По заявлению Facebook, многими компонентами Folly пользоваться значительно проще, чем доступными альтернативными библиотеками. Folly охватывает различные области программирования - от обработки строк и реализации хэшей, до манипуляций с форматом JSON и управления памятью.
URL: https://www.facebook.com/notes/facebook-engineering/folly-th...
Новость: http://www.opennet.me/opennews/art.shtml?num=33999
ещё один ненужный плюсовый мегакомбайн. Когда же закончится этот маразм мегакомбайнов...
я серьезно спрашиваю: расскажите как правильно должно быть?
несколько тематических библиотек, решающих определённый небольшой круг задач. Со своим коммьюнити, заинтересованном хорошо выполнить задачу. А не комньюнити, которому в принципе насрать на все фичи мегакомбайна, но главное чтобы фичь было много.
Интересно, каковы критерии "комбайновости". Тот же Boost - далеко не монолит, это как раз скорее общая крыша для тематических библиотек.
Здесь же, насколько я понимаю, объединяющий фактор - ориентация на веб с его спецификой, вовсе не обязательно плотное взаимодействие классов библиотеки между собой. При чем здесь комбайны и фичи?
> Тот же Boost - далеко не монолит, это как раз скорее общая крыша для тематических библиотек.Что не мешает ему быть еще тем переростком...
В каком смысле переростком? Много разных библиотек, есть большие и сложные, есть маленькие и простые, и все это объединено под названием boost, с единым стилем документации. А по вашему как должно быть? Точнее а как вообще может быть иначе, да ещё так, чтоб было ещё лучше?
> и все это объединено под названием boost, с
> единым стилем документации…и граблями с обратной совместимостью.
Не только единый стиль документации - качество библиотеки, включенной в Boost, не может быть ниже определенного уровня. Отдельные библиотеки, допиливаемые неизвестно кем, такой предварительной гарантии качества не дают.
Очень мешает в отладке возможность, что ошибка, которую ты ищешь, может быть вовсе не в твоем коде. Boost позволяет этот вариант игнорировать до последнего.
по крайней мере, на практике этого не видно. В бусте есть куча библиотек с математической направленностью и на многое из этого откровенно кладуд член. Качество реализации посредственное и всё время из этого сыпятся баги.Это как один из примеров с которыми приходилость сталкиваться мне. Но есть аналогичные реализации в отдельных библиотека совсершенно иного уровня. Иного здесь значит намного лучше. Отдельные библиотеки допиливаются как раз заинтересованными людьми, а подобные мегакомбайны нет.
В оьщем, гарантия буста это какая-то бредовая чушь.
> В каком смысле переростком?В таком что здоровенная либа, которую при случае совершенно задолбаешься пересобрать, например.
> Много разных библиотек, есть большие и сложные, есть
> маленькие и простые, и все это объединено под названием boost,При том большие и сложные - с кучей зависимостей, а пересобирать все это счастье just in case - вообще замахаешься. Кутю пересобрать и то пожалуй проще.
>>Со своим коммьюнити, заинтересованном хорошо выполнить задачу.ты че, это же продукт фейсбука. Их собственный. И ничего переделывать в угоду какого то мифического коммьюнити никто не будет. Я вообще не понимаю, какой им резон открывать.
так я и не говорю про переделки и тоже не понимаю нахрена это ещё кому-то понадобится
Деньги кончились, пора открывать, же!
PR + халявные программисты.
мало нам стандартных либ, встречаем замены:
fbstring (@author: Andrei Alexandrescu)
fbvector
> fbstring (@author: Andrei Alexandrescu)Он обнаружил в стандартной либе фатальный недостаток? :)
стандартный фатальный недостаток!
Если Александреску что-то сотворил на плюсах - я бы не десять, а все сто раз подумал прежде чем критиковать. Он как бы из самых крутых экспертов по ним.
Если Александреску что-то сотворил на плюсах - я бы не десять, а все сто раз подумал прежде чем использовать. Так правильнее.
Если не секрет - на чём пишете?
на опеннете же, очевидно
Вот и я о том же, что он явно болтун а не программист.
Если человек что-то сотворил на плюсах, я бы не десять - сто раз подумал об его адекватности. А уж если задействовал boost..
выкинь тогда половину системы (если не больше). выкинь все браузеры, утилиты etc. Они ведь написаны на плюсах
Да да... снова про миллионы мух. Чем прикажете пользоваться тогда?
Плюсы уметь готовить надо, это да. Так вот Александреску - умеет.
> Плюсы уметь готовить надо, это да. Так вот Александреску - умеет.он, конечно, круто делает из палок и верёвок космолёты. только это не using, а abusing.
В крайностях - да. Но, во-первых, из этих крайностей и появляется понимание "что ещё нужно" (и в новый стандарт хорошую часть этого abusing сделал ненужной), во-вторых часто можно эти извращения оставить автору библиотеки, а пользоваться только красивыми пользовательскими интерфейсами. А в-третьих часть из того что тогда казалось экзотикой стала вполне себе привычными и понятными практиками (стратегии те же, которые в бусте используются направо и налево, особенно для учета особенностей платформы).Я долго в рассылках по D висел - свидетельствую: он очень ценит код без извращений и активно пропихивает в язык средства для этого. Просто он хорошо понимает, что лучше сделать через abusing чем не сделать никак.
на самом деле лучше использовать инструменты, которые позволяют делать то, что хочется, без извращений, а не абузить неподходящий инструмент. то, что он, например, круто умеет изпользовать функциональщину на шаблонах не значит, что это верный подход: это скорее значит, что для решения задачи был выбран не тот инструмент.я не умаляю его крутости, но считаю её применённой не по делу. но плохо не это: плохо то, что его пример вдохновляет других искать зубы в труднодоступных местах. и даже создавать инструменты для поиска зубов в труднодоступных местах — вместо того, чтобы их там не выращивать вовсе.
Ну так сейчас он активно участвует в разработке D, где постарался количество зубов минимизировать, и пишет код времени компиляции почти на том же D, что и выполняется потом. Ну и плюсы и сейчас много где безальтернативны - потому что, предоставляя доступ к низкому уровню, дают реализовать всё что угодно - и при этом предоставляют возможность создания абстракций - хоть классов, хоть шаблонов. А когда Loki писалась - и подавно никаких альтернатив не было. Вот и приходилось крутостью компенсировать. Сейчас - повторюсь - многие из этих извращений становятся анахронизмами по мере реализации C++11.
новый цпп, к сожалению, продолжает дело старого. то есть, идёт не в том направлении. почему хорош C? он *простой*. почему D лучше C++? он *проще*. 11 — *сложнее* предыдущего варианта. да, его пытались упростить, но неверно: вместо выкидывания сущностей в язык досыпали ещё порцию костылей, теперь с моторчиком. это не значит, что в 11 *всё* плохо, но в бочку мёда таки кто-то нагадил. пила, совмещённая с вилкой и граблями, конечно, может использоваться и для еды, и для прополки, и для распилки, но все три действия ней совершать одинаково неудобно.
Не без того, но насколько я понимаю дихотомия такова: либо вы сложную задачу решаете на сложном языке (и его долго и тяжко осваиваете) либо вы её решаете на простом языке но со сложными бибилотеками, которые и берут на себя основную нагрузку либо пишете тонны шаблонного кода. Что не исключает некоторой серьёзной кривизны плюсов - которую не вылечить, не отказавшись от совместимости. Тем не менее если надо что-то сложное и быстрое (а особенно - работающее с железом или ворочающее большие объёмы данных) - выбирать особо и не из чего, если не хотите потратить миллиард.P.S. Кроме случаев отказа от костылей совместимости с С - D ни хрена не проще. Он логичнее, красивее, парсится удобнее - но наворотить там abusing можно ровно с той же лёгкостью, что и в плюсах, и разнообразных (и обычно не идеально согласованных) языковых средств там валом. Строковые миксины, множественные исключения, пачка модификаторов переменных, разница структур и классов, три метода реализации итерируемого объекта, alias this, strong vs weak purity... Хватает (очень интересных и красивых) извратов в общем.
ну, я и не говорил, что D идеален. но в общем случае он лучше C++. впрочем, судя по его развитию, этот недостаток скоро устранят (если уже не — я не особо пристально слежу).
Я уже с год не особо слежу - до этого честно прочел все сообщения в ньюсгруппах с 2008 года (отдельный подвиг - там несколько сот тысяч их было - но кучу интересного узнал). Так вот к тому моменту как я это дело забросил там уже всё было стабилизировано и крупных перемен не ожидалось. И да, он лучше плюсов, намного. на нём можно реально писать почти как на скриптовом языке, всё просто и понятно - причем "почти" лечится библиотеками - но там где нужна работа со сложными исистемами вдруг выясняется что язык громадный. Но на D1 я его в жизни не променял бы :-)
жаль только, что компилятор несвободный (inb4: я не сказал «без исходников») и заточен под интеля. был бы нормальный в составе gcc — я бы, возможно, сильно подумал о том, чтобы кое-какие проекты на D перевести.к сожалению, мне самому не хватает ни времени, ни знаний, чтобы сделать для gcc код. а если будут делать, то ещё и наверняка втащат boehm GC — в этом случае я даже смотреть не буду.
Опять же - нынешнюю ситуацию не знаю, но вроде и llvm-вариант (ldc), и gcc-вариант (gdc) отставали от авторского максимум на месяц и код давали вполне сравнимый. GC находится вdruntime, идущем под boost лицензией и именно он и используется во всех вариантах. Он там довольно плохой был, кстати - считал указателями слишком много. Может и поправили - проекты были.
Насчет кодогенерации - команда gdc в сторону arm смотрела.
Залез в обсуждения - gdc нормально работает на arm минимум с сентября.
> Опять же — нынешнюю ситуацию не знаю, но вроде и llvm-вариант (ldc),
> и gcc-вариант (gdc) отставали от авторского максимум на месяц и код
> давали вполне сравнимый.хм. надо будет опять глянуть.
> GC находится вdruntime, идущем под boost лицензией
я в курсе. но, вроде, в начале boehm использовали. впрочем, может и «ложная память».
> Он там довольно плохой был, кстати
э… а разве ему компилятор не помогал? O_O
Позвольте вмешаться в вашу милую беседу. Насчёт D: неотключаемое автоматическое управление памятью лично для меня напрочь перечёркивает все его преимущества и вкусности. Эх, а ведь мог стать серебряной пулей.
по-моему, GC там вполне отрываем. другое дело, что тогда останешься и без стандартных библиотек.а чем мешает, собственно? если реализацией — так код открыт. на C++ всё равно костылят своё такое же, только менее удобное.
то есть, я не в наезд, просто интересно. embedded, игры (хотя и тут) и ты пы не рассматриваем. чем мешает GC? я вот не отказался бы от GC в новом стандарте.
В C++ далеко не в каждой программе велосипедят GC, во многих случаях от просто не нужен. А я вообще предпочитаю иметь полный контроль над своей программой, не предугадывая, в какой же момент GC соизволит произвести очередной цикл очистки.
> embedded, игры и ты пы не рассматриваем.Ну уж нет, рассматриваем и ещё как! Почему, разрабатывая для embedded, я должен либо отказываться от ООП, либо терпеть корявость и вырвиглазность C++?
И да, наверно дело как раз в том, что мне лично по духу ближе embedded и системное программирование, чем десктоп и web.
> В C++ далеко не в каждой программе велосипедят GC, во многих случаях
> от просто не нужен.автоматические объекты на стеке — это недоGC. неотключаемый, кстати.
> А я вообще предпочитаю иметь полный контроль
> над своей программой, не предугадывая, в какой же момент GC соизволит
> произвести очередной цикл очистки.и кто тебе запрещает? O_O
но интересно даже не это, интересно, что такое «полный контроль». у тебя всё равно его нет, потому что ОС в любой момент может отправить твою софтину в далёкое и долгое путешествие. мантра «предпочитаю полный контроль» в большинстве случаев значит ровно одно: «я где-то прочитал, что GC — это УЖОС-И-ТОРМОЗА».
>> embedded, игры и ты пы не рассматриваем.
> Ну уж нет, рассматриваем и ещё как!нет, не рассматриваем, никак.
> Почему, разрабатывая для embedded, я
> должен либо отказываться от ООП, либо терпеть корявость и вырвиглазность C++?а-а-а-а, хочу машиииинкуууу! ну и что, что машинка не продаётся? ХОЧУУУУУУ!!!111111
> И да, наверно дело как раз в том, что мне лично по
> духу ближе embedded и системное программирование, чем десктоп и web.«embedded и системное программирование» — две разных вещи. второе — более широкая область. например, написание ls — это тоже «системное программирование».
я к чему, собственно? у тебя в голове набор мифов и профдеформация «везде пишем как для эмбедовки». знаешь, чем очень хороший программист отличается от просто хорошего? первый понимает, что человеческое время важней, чем машинное.
> автоматические объекты на стеке — это недоGC. неотключаемый, кстати.Поправка: автоматические объекты на стеке — это не GC. Это четкая система с предсказуемым поведением. В отличие от.
> Поправка: автоматические объекты на стеке — это не GC. Это четкая система
> с предсказуемым поведением. В отличие от.ах, если бы, ах, если бы… точно так же слабо предсказуемо и завязано на реализацию, как и GC. хороший же GC намного более предсказуем: хотя бы потому, что некоторые виды GC можно ограничить в отжираемом времени — что совершенно невозможно для автоматических объектов.
p.s. точнее, возможно — если использовать мегакостыли.
Мне до сих пор казалось, что автоматический объект с неопределенным временем жизни - признак говнокода.
Можете навскидку дать контрпример?
при чём тут «время жизни»? я, вообще-то, намекаю на «время умирания». которое для автоматических объектов тоже ни разу не «мгновенно» (объект с объектами внутри с…). тут, конечно, Профессионалы советуют на стеке держать только самую мелочь (а остальное, что сложнее, чем контейнер для инта — видимо, по-старинке, new и ох-не-забыть-бы-delete) — ну и зачем мне такой костыль?ещё раз: разговор был о том, что «при наличии GC я уже не контролирую программу». как будто с автоматическими объектами не так.
(ну и плюс — человек про GC знает то, что «рабинович напел»)
Удаление объекта, конечно, не мгновенно. Но его деструктор будет выполнен именно тогда, когда ожидается - при сворачивании контекста. А не тогда, когда будет запущен сборщик. Разница все-таки есть. Особенно для отладки.
«особенно для отладки» можно временно включить рефкаунтеровый/гибридный gc или пояснить gc, что надо работать лопатой всегда (улыбается) — как я и делаю, когда тестирую очередную реализацию, где нужен «велосипедный» gc.а освобождать ресурсы в деструкторе не стоит, для этого есть finally. если finally очень раздражает — можно за пол-часа написать простейший препроцессор, который вставит их сам. но я предпочитаю так.
> автоматические объекты на стеке — это недоGC. неотключаемый, кстати.Кроме маленьких уютных временных переменных на стеке ничего больше хранить не надо. Про что вы - непонятно.
> но интересно даже не это, интересно, что такое «полный контроль». у тебя
> всё равно его нет, потому что ОС в любой момент может
> отправить твою софтину в далёкое и долгое путешествие.Идеала не достигают, к нему стремятся. А с таким отношением мы опять приходим к б-гомерзкому Managed code.
> мантра «предпочитаю полный
> контроль» в большинстве случаев значит ровно одно: «я где-то прочитал, что
> GC — это УЖОС-И-ТОРМОЗА».А вы где-то прочитали, что GC - «НАШЕ ВСИО», вещь идеальная и необходимая, ресурсов не потребляет, работает моментально и когда нужно. Дальше что?
>>> embedded, игры и ты пы не рассматриваем.
>> Ну уж нет, рассматриваем и ещё как!
> нет, не рассматриваем, никак.да, рассматривает, как-нибудь.
> а-а-а-а, хочу машиииинкуууу! ну и что, что машинка не продаётся? ХОЧУУУУУУ!!!111111
Аргументы закончились, включаем дразнилку? Good-good.
> «embedded и системное программирование» — две разных вещи. второе —
> более широкая область. например, написание ls — это тоже «системное программирование».И? Мысль продолжайте уж. На D можно полноценно заниматься системным программированием? Кто-то захочет написать ls на D?
> я к чему, собственно? у тебя в голове набор мифов и профдеформация
> «везде пишем как для эмбедовки».Собственно, я и сказал, что это мне ближе, мои же слова мне в укор ставить не надо. Это не профдеформация, а специализация. Профдеформация - это «везде нужет GC».
> знаешь, чем очень хороший программист отличается
> от просто хорошего? первый понимает, что человеческое время важней, чем машинное.Угу, и чегой-то разработчики, например, браузеров постоянно оптимизируют что-то. Может сообщите им эту мудрую мысль, а то, похоже, они не в курсе?
Ладно, к D это всё не особо относится - стек там как был так и есть, сишные аллокаторы тоже, всё это вполне перемешивается с GC и вполне неплохо работает. Я пробовал.
> реально быстрая работа со строками реализована именно за счёт толкового использования GC (и ranges)Реально быстрая работа со строками нудна не всем.
> Ладно, к D это всё не особо относится - стек там как
> был так и есть, сишные аллокаторы тоже, всё это вполне перемешивается
> с GC и вполне неплохо работает. Я пробовал.Хотелось бы верить, но не получается.
Мой основной тезис таков: D не может являться полноценным системным языком программирования, потому что к нему гвоздями прибита автоматическая сборка мусора.>Лечится, понятное дело, ручной работой с памятью и аренами, благо в D с этим проблем никаких
А вот об этом поподробнее можно? Ссылку что ли.
> Мой основной тезис таков: D не может являться полноценным системным языком программирования,
> потому что к нему гвоздями прибита автоматическая сборка мусора.а бедный Вирт об этом не знал, и написал ажно целую ОС с гуями на языке, к которому *действительно* говздями прибита сборка мусора.
только ради всех святых прошу: не отвечай. ещё одну дозу глупости я могу и не выдержать.
> а бедный Вирт об этом не знал, и написал ажно целую ОС
> с гуями на языке, к которому *действительно* говздями прибита сборка мусора.Это поделие никак не относится к реальному миру, оно из раздела «ненормальное программирование».
> только ради всех святых прошу: не отвечай. ещё одну дозу глупости я
> могу и не выдержать.Прошу, пожалуйста, только не захлебнитесь высокомерием, а то ведь я буду чувствовать себя виноватым :-( Умоляю, поберегите себя!
Ссылки искать лень, но идея такова - вся сишная стандартная бибилиотека в D доступна из коробки, в т.ч. malloc/free. Есть определение своего new/delete для класса, если надо - это можно автоматизировать наследованием или миксином. Поиск по обсужениям emplace даст примеры использования, если надо. Есть std.conv.emplace для размещения объекта в выделенном куске памяти.
Предсказуемость вида "я могу пнуть систему чтобы она осводбодила те два гигабайта памяти, что я занял на короткое время" весьма ценна иногда. В той же рассылке по D активно обсуждались такие примеры - когда человек работает с гентическими данными, выгребает их в память (занимая гигабайты), а потом, вроде прибив все ссылки, не может аллоцировать новый кусок на следующую операцию. Лечится, понятное дело, ручной работой с памятью и аренами, благо в D с этим проблем никаких. А путём правки GC в системном языке - не лечится, так как есть куча областей памяти, про которые нельзя точно сказать, указатели там или нет - и, соответственно, с вероятностью получаешь false pointer и gc не отрабатывает.
Там, к примеру, реально быстрая работа со строками реализована именно за счёт толкового использования GC (и ranges). В общем, он там не просто так введен - есть фичи, которые без него не реализуются в принципе.
То, что сотворил Александреску, должно быть круто, и он действительно один из самых серьёзных экспертов, и, более того, один из оказавших очень серьёзное влияние на весь современный C++. Но, ИМХО, ценность его разработок скорее именно во влиянии на современный C++, чем в возможности практического использования. Использовать его разработки напрямую я бы тоже поостерёгся.Вспомним ту же библиотеку Loki. По идеям -- великолепно. Но многие ли используют её, а не возникшие позже аналогичные фичи в boost?
Видимо, потому, что сильно шаблонизированный код хорошо работает, только когда он работает.
А вот отлаживать код с хитро закрученными шаблонами... неприятно. Внезапно оказывается, что от высокоуровневого языка ты должен снова вернуться к машинной логике и эмулировать мозгами компилятор.
> Видимо, потому, что сильно шаблонизированный код хорошо работает, только когда он работает.
> А вот отлаживать код с хитро закрученными шаблонами... неприятно. Внезапно оказывается,
> что от высокоуровневого языка ты должен снова вернуться к машинной логике
> и эмулировать мозгами компилятор.По моему личному опыту, дикие шаблонизмы со списками типов приемлемо отлаживаются только стопроцентным покрытием этих шаблонизмов юнит-тестами. Надо заставить заработать все "ветки" шаблонизации, а потом молиться на результат. :) Как следствие, такие шаблонизмы недёшевы в разработке и непросты в поддержке. Поэтому у серьёзных шаблонизмов есть своя ниша -- "базовые" библиотеки с серьёзным упором на оптимизацию. STL, многое из Boost и т.п. Скажем, я применял для работы с GPIO на 8-битных микроконтроллерах. А за пределами этой ниши увлекаться шаблонизмами не стоит. В прикладном высокоуровневом коде прямое применение шаблонов Александреску (не в виде использования готовых наработок, а именно написание кода, проникнутого соответствующими идеями) крайне редко бывает оправданным. До сих пор ни разу такого не видел, честно говоря.
вообще-то можно ещё механизм формального доказательства использовать. особенно если вспомнить, что шаблоны цпп — это, по сути, функциональный язык с очень уродливым синтаксисом.правда, не уверен, что это будет проще толпы тестов.
Вообще говоря в коммерческом проекте за лихо закрученные шаблоны убивать надо веником. Проще уж сразу выкинуть это г-но вместе с тестами, чтобы не вздрагивать по ночам. Код в больших проектах все-таки должен быть прежде всего читабельным и максимально доступным для понимания.
> То, что сотворил Александреску, должно быть круто, и он действительно один из самых серьёзных экспертов, и, более того, один из оказавших очень серьёзное влияние на весь современный C++.
> ..."Не читайте Александреку" - А. Степанов
У Степанов специфический подход - для него программист это математик а не инженер. Разницу пояснять?
Да. Александреску плодит фенечки ради фенечек на радость "программистам", которые не желают быть математиками и инженерами. Характерный пример --- упоминавшийся где-то здесь vector. Вместо того чтобы взять контейнер с нужными гарантиями под алгоритм (или видоизменить алгоритм под гарантии контейнера) пишем ещё-один-самый-лучший-vector. Конечно, если у тебя vector от Дольче Габбана, тьфу, от Александреску, то ты, без сомнения крутой программист, а не конь педальный, в натуре.
мда. когда Александреску критикую я или Crazy Alex — это можно понять. но когда подобная тебе амёба, вместо чтобы стыдливо молчать, начинает Высказывать Мнение, то Шариков кажется титаном интеллекта.
> мда. когда Александреску критикую я или Crazy Alex — это можно понять. но когда подобная тебе амёба, вместо чтобы стыдливо молчать, начинает Высказывать Мнение, то Шариков кажется титаном интеллекта.Был неправ, врожденное косоглазие не дало мне возможности заметить нереально крутых парней.
Наскольок я помню сам Александреску рекомендует использовать "аналогичные фичи в boost". Время прошло - появились хорошие альтернативы.
> Наскольок я помню сам Александреску рекомендует использовать "аналогичные фичи в boost". Время прошло - появились хорошие альтернативы.Да дело, имхо, даже не втом, что "время прошло". Александреску - это учебник, в каких-то областях/смыслах очень практичный (близкий к практике), но именно - учебник. Множество вариантов, множество тонкостей, универсализм и т. п. Для изучения и понимания особенностей и возможностей - самое то. Boost - чисто практическая реализация конкретных вещей - бери и используй (в идеале, сначала крепко подумав).
Да-да, я как раз об этом. Отчасти это учебник, отчасти -- освоение новых областей, но не основа для промышленного кода.
Сейчас, когда есть лучшие альтернативы (а скорее - продолжатели дела) - разумеется.
> fbstringТак ведь это старая добрая традиция - писать свой велосипед для строк :D
>> fbstring
> Так ведь это старая добрая традиция - писать свой велосипед для строк
> :DСобственно, Страуструп первый и начал )) Но он прав (в этом смысле) - строки это идеальный учебный пример. Все понимают о чем речь, у каждого в голове с ходу есть несколько вариантов реализации (от того и сотни вариантов), а он описывает как можно задействовать возможности языка для того, чтобы сделать реализацию проще в использовании. Сложно найти учебный пример лучше.
> - строки это идеальный учебный пример. Все понимают о чем речь,
> у каждого в голове с ходу есть несколько вариантов реализации (от
> того и сотни вариантов), а он описывает как можно задействовать возможности
> языка для того, чтобы сделать реализацию проще в использовании. Сложно найти
> учебный пример лучше.Построить хороший интерфес для работы со строками + хорошую реализацию --- очень не тривиальная задача. И есть мнение, что эта задача ещё не решена.
Да... ориентировано на скорость :) fbstring копирует данные по-бай-то-во!))) На помойку.
> Да... ориентировано на скорость :) fbstring копирует данные по-бай-то-во!))) На помойку.Ну это как snappy от гугля. Есть например менее распиаренный LZ4. Он умудряется жать и быстрее и лучше. Одновременно. И на сях сразу, вместо каких-то огрызков от си++, притянутых за уши. Которые нафиг не уперлись и ничего кроме добавочного геморроя не создают (например в ядро хрен просто так включишь, etc).
Побайтовое копирование там в одном единственном случае, в больлшинстве мест - memmove. В логике глубоко не копался, так что насчет того, что когда в коде встречается - не знаю. Но вообще из опыта обсуждений в группах по D - Александреску к таким вещам очень аккуратно относится, вряд ли случайно такое сотворил.
То же самое что есть у любой крупной конторы - свой закос под STL, обросший своими же костылями. Такое есть и у Google и у Яндекс, логично что такой же урод родился и у Facebook. Грустно то, что местный менеджмент не пресекает костыли на корню.
> То же самое что есть у любой крупной конторы - свой закос
> под STL, обросший своими же костылями. Такое есть и у Google
> и у Яндекс, логично что такой же урод родился и у
> Facebook. Грустно то, что местный менеджмент не пресекает костыли на
> корню.Грустно, что компаниям ТРЕБУЕТСЯ перепиливать либы вместо использования стандартных для получения высокой скорости.
> Грустно, что компаниям ТРЕБУЕТСЯ перепиливать либы вместо использования стандартных для
> получения высокой скорости.Да вроде как все закономерно - если хочется стандартного (т.е. универсального, чтоб на всех платформах одинаково и без костылей) - то и получится не самый быстрый вариант. А если нужна высокая скорость - то не получится универсальность, поскольку, придется "пилить костыли" под конкретную платформу и под конкретные наборы данных.
Увы, "за все нужно платить" (С)
Под конкретные наборы данных - да.
Под конкретную платформу - нет.Меня не волнует как это реализовано внутри. Пусть даже алгоритм уникален для каждой платформы. Главное, чтобы интерфейс был одинаков.
Вас будет волновать, как оно устроено внутри, когда каждый нюанс умножится на количество информации.
Если вектор из STL, например, несколько неаккуратно ест память (с редко используемым запасом), то при умножении на миллиарды векторов получится лишний датацентр для поддержки этого запаса. Простая замена его на "велосипед", экономящий память, позволит внезапно и безболезненно сократить расходы...
Хоть один что-то понял...Плюс независимость от изменений стандартов и пр. мутотни. Было два параметра, сделали три - не трогает и не колышет.
Итог: прогнозируемое поведение. Когда это твой бизнес и твои деньги - это резко становится очень важным.
Ну, изменение стандартов и параметров в STL - это очень маловероятно.
Но абстрагирование от деталей языка и библиотек обычно здорово облегчает сопровождение программы.
> Хоть один что-то понял...
> Плюс независимость от изменений стандартов и пр. мутотни. Было два параметра, сделали
> три - не трогает и не колышет.
> Итог: прогнозируемое поведение. Когда это твой бизнес и твои деньги - это
> резко становится очень важным.Действительно, это классический аргумент защитников парадигмы NIH (Not Invited Here).
На практике они порождают и поддерживают легенду о том, что их велосипед самый качественный, самый быстрый, самый стабильный, ну и так далее. Ньюанс в маленьком: корректно сравнить этот велосипед с альтернативой не представляется возможным. Эта невозможность и является ключевой для поддержания легенды об исключительных качествах данного конкретного велосипеда.
>> Хоть один что-то понял...
>> Плюс независимость от изменений стандартов и пр. мутотни. Было два параметра, сделали
>> три - не трогает и не колышет.
>> Итог: прогнозируемое поведение. Когда это твой бизнес и твои деньги - это
>> резко становится очень важным.
> Действительно, это классический аргумент защитников парадигмы NIH (Not Invited Here).
> На практике они порождают и поддерживают легенду о том, что их велосипед
> самый качественный, самый быстрый, самый стабильный, ну и так далее.Если возникла реальная потребность и делали не студенты, то, для конкретного случая(!), так оно и получается (быстрее, стабильнее, компактнее - нужное подчеркнуть), к сожалению (а может и к счастью, кто знает).
> Ньюанс в маленьком: корректно сравнить этот велосипед с альтернативой не представляется возможным.
Для конкретного случая (а не для всех возможных вариантов использования!) очень даже возможно. Результирующий ассемблерный листинг не врет, точка. Там все видно, кто сколько тактов (байтов) на что потратил. Я, конечно, смотрю сугубо со своей embedded колокольни, но то, что возможно "не колышет" прикладных программеров (в обмен на удобство и универсальность) для нас очень даже важно (вплоть до переписывания особо нагружаемых вещей на асме, если "прижмет"), тут уж, извините, все "зубры" "правильного" программирования идут нафиг.
> Я, конечно, смотрю сугубо со своей embedded колокольни, но то, что возможно "не колышет" прикладных программеров (в обмен на удобство и универсальность) для нас очень даже важно (вплоть до переписывания особо нагружаемых вещей на асме, если "прижмет"), тут уж, извините, все "зубры" "правильного" программирования идут нафиг.Со своей геймдев-колокольни вижу то же самое. Красивые абстракции - это замечательно, но код который пишется близко к телу и заточен под микроархитектуру - будет уродлив всегда, т.к. уродлива сама микроархитектура. Ну точнее, на нее плохо ложатся абстракции, как-то так.
"У нас" постоянно велосипедят аллокатор и многие другие компоненты, для которых казалось бы есть готовая замена. Однако производительность в случае конкретной игры всегда выше на своем, заточенном под задачу.
> "У нас" постоянно велосипедят аллокатор и многие другие компоненты, для которых казалось
> бы есть готовая замена. Однако производительность в случае конкретной игры всегда
> выше на своем, заточенном под задачу.Вот это как раз "правильно" и "хорошо". Если allocator совместим по интерфейсам, вы имеете возможноть сравнивать несколько allocator'ов и выбирать лучшую стратегию для конкретной задачи.
А вот когда вам суют allocator и говорят, что он самый супер-пупер, вот только интерфейс у него самобытный и скрытых side-эффектов ещё вагон и инфраструктура для него специфичная нужна... Затраты на "попробовать" оказываются столь велики, что отказаться от него не хватает духу. Ну, и лобби, конечно присутствует.
> Если вектор из STL, например, несколько неаккуратно ест память (с редко используемым
> запасом), то при умножении на миллиарды векторов получится лишний датацентр для
> поддержки этого запаса. Простая замена его на "велосипед", экономящий память, позволит
> внезапно и безболезненно сократить расходы...Продолжим пример: этот вектор потребляет на 1% памяти больше. Тогда чтобы набралось издержек на лишний датацентр нужно чтобы у компании уже было 100 ДЦ. Даже Гугл не набрал столько.
С другой стороны - этот же вектор упрощает программирование на 1% (продолжая потреблять на тот же 1% больше памяти). Для компании отдать приложению на 1% больше ОЗУ практически бесплатно - вместо планки 2Гб поставить 4Гб обойдется в 450 руб (сейчас же даже блейды таскают на 16Гб и больше).
С другой стороны 1% от ЗП программиста это примерно 14-16 тыс рублей в месяц (сама ЗП, налоги, выплаты в гс-фонды).
Так что если вы работаете не в гос-структуре (где лучше больше освоить, но меньше сделать), то главные критерий - производительность программиста, а не такты процессора или байты ОЗУ.
Вы неправильно продолжаете пример. Стандартный вектор при добавлении элемента сверх выделенной памяти добавляет себе еще до полстолька памяти про запас, в зависимости от реализации. Это совсем не 1%.
Экономия памяти, конечно, выльется в лишние такты, но в вебе процессор давно уже не узкое место, а вот память... Вместо 2Гб 4Гб - это просто. Но сервера датацентров FB, надо думать, не дураки собирали, и памятью они забиты по максимуму.Программирование же не усложнится вовсе, если вместо std::vector будет использоваться fb::vector. Напротив, может упроститься - за счет ненужности низкоуровневых оптимизаций там, где std::vector был неудачен.
Так что - оба раза мимо.
> Стандартный вектор при добавлении элемента сверх выделенной памяти добавляет себе еще до полстолька памяти про запас, в зависимости от реализации.std::vector::reserve, не?
И так по всему коду, чудом предугадывая, сколько именно памяти понадобится в процессе жизни вектора?
> И так по всему коду, чудом предугадывая, сколько именно памяти понадобится в
> процессе жизни вектора?Большая часть DSP и embedded программирования строится на точном знании чего, сколько и когда именно понадобится. Безо всяких "чудес предугадывания".
Это я сейчас в целом, не касаясь конкретно ни STL, ни чего-либо ещё - просто чтобы немножко снизить чрезмерную категоричность высказываний. Без обид.
Ну, это же совсем другая область. Речь о веб-библиотеке. В которой можно уверенно говорить о непредсказуемости данных. Потому что случаи, когда их пытались предсказать, обычно потом лечились заплатками, устраняющими уязвимости.
Но даже без этого нюанса решение проблем предложенным путем создаст серьезный оверхед для программистов и при этом совершенно не обязательно - реальный выигрыш в производительности и экономии ресурсов. Так что решение со всей очевидностью "не катит".
> И так по всему коду, чудом предугадывая, сколько именно памяти понадобится в процессе
> жизни вектора?Много вставок, последовательный доступ? --- list или single_list
Известны оценки, нужен произвольный доступ --- vector.
Большой разброс по количеству элементов, но добавляем только с концов? --- deque.
Много элементов, нужна упорядоченность? --- map (это красно-черное дерево).
Можете построить хорошую хэш-функцию для ваших данных, упорядоченность не нужна? --- unordered_map.
Т.е. явно сформулированные гарантии для контейнеров, использование контейнеров с нужными свойствами, внимание к алгоритмам.
Представьте себе, с азами STL большинство присутствующих знакомы.
Речь о конкретной нише, в которой важны конкретные факторы. И универсальные контейнеры, внезапно, показывают неоптимальное для этих условий поведение. Поэтому пишется специфический контейнер, заменяющий универсальный и при этом реализующий оптимизации, возможные в этих конкретных условиях.
На лабораторных такие случаи, конечно, не разбирают...
> Представьте себе, с азами STL большинство присутствующих знакомы.
> Речь о конкретной нише, в которой важны конкретные факторы. И универсальные контейнеры,
> внезапно, показывают неоптимальное для этих условий поведение. Поэтому пишется специфический
> контейнер, заменяющий универсальный и при этом реализующий оптимизации, возможные в этих
> конкретных условиях.
> На лабораторных такие случаи, конечно, не разбирают...С азами (т.е. слышали такую аббревиатуру) --- да, похоже Вы _знакомы_. На практике оказывается, что 4/5 считают свой случай совершенно уникальным (мне надо пихать объекты в стек) и стандартные контейнеры для этого совершенно не подходят (использовал vector, получается ужасно).
Тогда вопрос к вам, как к специалисту.
Требуется обрабатывать огромное количество данных, размер которых заранее неизвестен, но никаких особенных функций, кроме произвольного доступа к ним, не требуется.
Какой контейнер и как вы будете использовать?
Требования - минимизация расхода памяти и, во вторую очередь, процессорного времени.
Вектор уже оценен и сочтен неудачным, поскольку предусматривает использование памяти сверх необходисти.
> Тогда вопрос к вам, как к специалисту.Если как к специалисту, то придется потратить определенное время нам обоим на выжимание из Вас адекватной непротиворечивой постановки. Я не Мессинг, чтобы угадывать алгоритм "обрабатывания" (оценка сложности для доступа, оценка сложности для вставки, если она нужна, необходимы ли операции "предыдущий", "следующий", упорядоченность, индексирование, однозначность, etc.), сколько весит "огромное" но "заранее неизвестное", что такое "сверх надобности" и т.д. и т.п.
А вот вилять не надо.
Первое же требование - минимизация расхода памяти - сворачивает ваш список в трубочку.
Потому что любой контейнер STL расходует ее больше, чем вектор (начиная со сколько-нибудь большого содержимого).
Никаких подробностей не требуется.
Если у вас экземпляров кода много - то программист становится дешевле железок. На порядки.
> С другой стороны 1% от ЗП программиста это примерно 14-16 тыс рублей в месяц (сама ЗП, налоги, выплаты в гс-фонды).Программист, обходящийся конторе в полтора ляма ежемесячно? Это наверное очень хороший программист и его наверняка не затруднит помочь конторе сэкономить на железе в пользу своей зарплаты.
Ну а если между цифрами таки должны стоять точки, то видно что при увеличении количества экземпляров кода, расходы на железо действительно стремительно растут выше экономии на программисте.
Значит STL реализация вектора не подходит в данном случае и должна быть подходящая "искаробки".man queue - там почему-то не стесняются указать чего и как лучше использовать:
Linked lists are the simplest of the doubly linked data structures and support only the above functionality over singly-linked lists.
Tail queues add the following functionality:
1. Entries can be added at the end of a list.
2. They may be traversed backwards, from tail to head.
3. They may be concatenated.
However:
1. All list insertions and removals must specify the head of the
list.
2. Each head entry requires two pointers rather than one.
3. Code size is about 15% greater and operations run about 20%
slower than singly-linked lists.И как видите, меня снова не волнует как оно устроено внутри. достаточно знать чем мне грозит использование функциональности.
> Да вроде как все закономерно - если хочется стандартного (т.е. универсального, чтоб на всех платформах одинаково и без костылей) - то и получится не самый быстрый вариант. А если нужна высокая скорость - то не получится универсальность, поскольку, придется "пилить костыли" под конкретную платформу и под конкретные наборы данных.я под стандартным понимаю соответствие внешнему API и идентичное поведение при использовании API. А как оно будет внутри - на самолете, на самокате или окостылено по небалуйся - не волнует. Главное соответствует спеке и работает.
Так что было бы круто, если все либы от Гугла, Яндекса и прочих Мордокниг реализовали стандартное API и таким образом их можно было бы интегрировать в базовые либы.
List list = new List(); // базовая реализация
List list = new ListFromFacebookImprovedForIntegers(); // улучшенная реализация от Мордокниги> Увы, "за все нужно платить" (С)
Вопрос в том кто платит и за что.
Ну вот сразу навскидку - чтобы указанное сделать List должен все свои методы иметь виртуальными. Что для многих случаев будет вести к основательным потерям в производительности.
Это не говоря о том, что в разных фирмах coding guidelines могут капитально отличаться.
> Так что было бы круто, если все либы от Гугла, Яндекса и прочих Мордокниг реализовали стандартное API и таким образом их можно было бы интегрировать в базовые либы.это совершенно не было бы круто, ибо API тоже нужно разрабатывать, точно так же, как и писать сам код и мозговать алгоритмы. Твоия идиллия возможна если это самое API вдруг спустит с небес сам Он и скажет - лучше не придумаете.
Но такого не бывает, пока ещё.
Разнообразие в подходах помогает найти нормальное решение в процессе эволюции и ествественного отбора наиболее удачных реализаций.
Нужно учитывать исторический аспект проблемы. Когда многие проекты начинали расти не было много чего в стандартных библиотеках или поддержка компиляторами была посредственного качества. У меня у самого на руках есть такие проекты с бородатой историей и с аналогичным вагоном уже велосипедных библиотек если смотреть на них сейчас.Хз как это было у мордокниги, мб там всё развивалось похожим образом.
> представлена большая коллекция C++ классов, дополняющих стандартные библиотеки
> C++ и набор Boost.Угу, правда работать будет только с GCC (может быть Clang), ибо GCC __attribute__ syntax встречается, ну и использует фичи нового стандарта типа move semantics. Переносимость на другие платформы хромает. Хотя оно и верно, Мордокниге на другие платформы плевать :)
там же и написано C++11
> Угу, правда работать будет только с GCC (может быть Clang), ибо GCC
> __attribute__ syntax встречается, ну и использует фичи нового стандарта типа move
> semantics. Переносимость на другие платформы хромает. Хотя оно и верно, Мордокниге
> на другие платформы плевать :)Не могу понять, это Вы про aCC, Apogee или (извините, если плохо о Вас подумал) про VS (тьфу)?
Итить. Ну написала челы для себя либы. Ну катаются они в их приложениях у себя в конторе - их устраивает. Ну выложили они их в общий доступ. Спасибо посмотрим? Нет! Срачь на хрен пойми сколько!
> Итить. Ну написала челы для себя либы. Ну катаются они в их
> приложениях у себя в конторе - их устраивает. Ну выложили они
> их в общий доступ. Спасибо посмотрим? Нет! Срачь на хрен пойми
> сколько!+1. Прям с языка снял.
Никто ведь не заставляет ни одних открывать, ни других использовать. Никто не пихает это как "стандарт" (всем делать так) или как "что-то супероригинальное" (смотри как круто я умею). Просто еще одна открытая реализация того, о чем и так все заинтересованные в курсе. Не больше и не меньше.
Однако, товарищ умеет заинтересовать!FBVector.h:521
size_type max_size() {
// good luck gettin' there
return ~size_type(0);
}
>при очень редких операциях удаления.Хе-хе. %)