Программист из Северной Кореи Дэниель Канг (Daniel Kang) представил (https://github.com/d5/node.native) первую экспериментальную реализацию фреймворка node.js (http://nodejs.org) для языка C++, позволяющую создавать высокопроизводительные приложения в стиле оригинального node.js, но ориентированный на выполнение скомпилированного кода на языке С++, без использования JavaScript.
Node.native представляет собой асинхронный I/O-фреймворк, архитектурно и идейно сходный с фреймворком node.js. Однако, в отличие от последнего он не использует JavaScript-движок V8 и предназначен исключительно для программирования на языке C++11, возможности параллельного программирования которого и вдохновили автора на создание проекта. Как и оригинальная реализация, node.native перекладывает работу по обслуживанию запросов ввода-вывода на отдельные потоки, благодаря чему удается достичь высокого уровня производительности приложений.В данный момент проект находится в начальной стадии разработки и п...
URL: http://www.theregister.co.uk/2012/02/17/node_js_native_c_plu.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33130
хорошая новость.
Зачетненько. И ведь как компактно, а? :)
да не только в компактности дело то. посмотрел я код сего поделия и надо признать, что достаточно грамматно написано. правда, проект зависит ещё от двух других: libuv и http-parser. но они малы по объёму и легко вписываются в данный проект. более того, я думаю, что от них, позже, можно будет избавиться, переписав код также на С++11. ну, что добавить? Хорошая тенденция - Viva C++11.
> да не только в компактности дело то. посмотрел я код сего поделия
> и надо признать, что достаточно грамматно написано.Грамотно. Весь код в *.h файлах. *facepalm*
> правда, проект зависит ещё
> от двух других: libuv и http-parser.Зависит? Этот "проект" просто биндинги к libuv и все. *doble facepalm*
>но они малы по объёмуlibuv это, внезапно, движок node.js
> Грамотно. Весь код в *.h файлах. *facepalm*В С++ в библиотеках применяющие templates это естественный метод (по-другому будет сильно извращенно). Минус - это то что код библиотеки всегда компилируется. Плюсы: сгенерированный код всегда получается максимально эффективным для предоставленного типа через шаблоны.
Среди библиотек (что вспомнил) которые от 90% до 100% в *.h файлах: STL, boost, OTL, agg
> по-другому будет сильно извращенноПо другому нельзя. Код шаблона должен быть виден компилятору в момент использования. Иначе он не сможет сгенерировать для него код.
>> по-другому будет сильно извращенно
> По другому нельзя. Код шаблона должен быть виден компилятору в момент использования.
> Иначе он не сможет сгенерировать для него код.Если компилятор не поддерживает extern templates (а таких большинство), то вот пример:
template<typename T> class MyClass {
class MyClassImplementation *impl; //заметьте не шаблонный класс
public:
MyClass() : impl(new MyClassImplementation(sizeof(T))) {}
// ну и т.д.
}Одни задачи достаточно комфортно разрываются на реализацию и шаблонный-интерфейс, для других проще (но не-невозможно) оставить все в *.h-файле
> Минус - это то что код библиотеки всегда компилируется.это филосовский и религиозный вопрос. возможно это будет откровением для Вас, но код на JavaScript, тоже компилируется, правда, в байт код.
пока архитектура современных ПК будет оставаться такой, какая она есть сейчас, идеального решения не будет. а всё остальные, выжившие решения, одинаково "почти" идеальны.
"все в светлое будущее квантовых технологий!" )))
> Грамотно. Весь код в *.h файлах. *facepalm*))) я сказал про сам код. какая разница в какой логической единице он содержиться: cpp или h?
> Зависит? Этот "проект" просто биндинги к libuv и все. *doble facepalm*
))) простите, а биндинги на сторонние проекты, это разве не зависимость от них? )))
> libuv это, внезапно, движок node.js
))) неужели? а мужики то незнают. цитата: "libuv is a new platform layer for Node. Its purpose is to abstract IOCP on Windows and libev on Unix systems. We intend to eventually contain all platform differences in this library."
> ))) я сказал про сам код. какая разница в какой логической единице
> он содержиться: cpp или h?А какая разница между хорошо структурированным читаемым кодом и кашей?
> ))) простите, а биндинги на сторонние проекты, это разве не зависимость от
> них? )))Тогда следуя вашей логике:
>Голова зависит ещё от мозга. Но он малы по объёму и легко вписываются в данный проект. более того, я думаю, что от него, позже, можно будет избавиться.
> ))) неужели? а мужики то незнают.Чего не знают мужики, английского?
> А какая разница между хорошо структурированным читаемым кодом и кашей?Не придумывайте того, чего нет. где Вы там кашу усмотрели?
Понимание кода напрямую зависит от образованности читаемого его.
Если Вы чего-то там усмотрели, не понимаете или не знаете, то это не каша, а RTFM.> Тогда следуя вашей логике:
Вы не правильно провели аналогию. Не голова и мозг одного человека, а МОЯ голова и ЧУЖОЙ мозг. Или более реальная ассоциация: мой друг может взламывать только внешнюю защиту сетей, а я могу взламывать только компьютеры в самой сети. В один прекрасный день мой друг погиб. Я не смогу больше взламывать компьютеры без него, потому что не могу проникнуть через внешний файервол.
Проследуйте моей логике: уберите из Node.native, например, сторонний проект libuv и Вы не сможите скомпилировать Node.native. А убрать проект можно запросто - ОН ЧУЖОЙ, ОН СТОРОННИЙ.
> Чего не знают мужики, английского?
Хорошо, я пререведу: "libuv это новая платформенная прослойка для Node. Её задача остагировать IOCP на Windows и libev на Unix системах. Мы хотим со временем реализовать все платформенные различия в этой библиотеке."
Я больше не хочу с Вами общаться Df232z на эту тему. Разговор получается пустой.
А зачем избавляться и переписывать? они хорошо написаны и хорошо поддерживаются.
Я так понимаю, наконец-то начнут клепать сайты на нормальном Си, а не на интерпретируемых языках? Или что-то путаю?
Drupal на C++...
А что общего между событийно-ориентированным вреймворком и CMS?
> Я так понимаю, наконец-то начнут клепать сайты на нормальном Си, а не на интерпретируемых языках? Или что-то путаю?Есть мнение, что вы слабо представляете себе, что такое node.js и зачем он нужен.
>Я так понимаю, наконец-то начнут клепать сайты на нормальном Си, а не на интерпретируемых языках? Или что-то путаю?
>Drupal на C++...По идее сайты, уже давно можно клепать на С++ посредством Wt: http://www.webtoolkit.eu/wt, только не пойму почему этот тулкит пока так и не стал популярен.
Внезапно сайты можно уже лет 15 клепать на с++ и cgi.
Точно также как можно огород вскапывать вилкой.
Только почему то этот метод не популярен.
Наверное потому что есть более подходящие инструменты?
>Внезапно сайты можно уже лет 15 клепать на с++ и cgi.
>Точно также как можно огород вскапывать вилкой.
>Только почему то этот метод не популярен.
>Наверное потому что есть более подходящие инструменты?В том то и дело что Wt - достаточно удобный фреймворк, очень похож на Qt.
> Внезапно сайты можно уже лет 15 клепать на с++ и cgi.Только вот скорость работы CGI получается как-то не вкусной и не имеющей ничего общего с event-driven конструкциями. Небольшая разница.
> только не пойму почему этот тулкит пока так и не стал популярен.Потому что GPL.
> Потому что GPL.На серваке это вообще до фени если это не AGPL... ;)
А что мешало раньше?
Хорошая вещь - иногда нужно прикрутить к приложению встроенный веб-сервер.
libsoup не?
а также http://code.google.com/p/mongoose/
>Хорошая вещь - иногда нужно прикрутить к приложению встроенный веб-сервер.Не распарсил, уточните что вы имели ввиду: иногда необходимо встроить веб-сервер, или иногда необходимо прикрутить к приложению встроенный в исполняемую среду (чья и что за среда? (думается что операционная система - среда исполнения приложения)) веб-сервер (не тогда вопрос насчет приложения и его начальной формы)?
Не стоят эти "на 80%" того, чтобы связываться с С++
Ещё как стоят.
Не говоря уже об экономии памяти.
Память нынче дешевая. Ей то как раз можно жертвовать ради производительности
http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF25a/15351-15351-42...
Сервачёк вполне себе симпатичненький, но 128Гб оперативки в него не войдут, да и ядер всего два...
> Память нынче дешевая. Ей то как раз можно жертвовать ради производительностиРазработчики ZFS тоже так думали. И теперь для нормальной работы продакшен-стореджа порой требуется столько памяти, что не влезает в стандартный сервак.
Не трынди. Внезапно - на Соляре есть лимиты, позволяющие ограничить ARC - Это раз. Два - систему можно и нужно адекватно тюнить под задачу. И три - в стандартный сервак одноюнитовый можно запихнуть 64 Гб рамы. Если тебе этого мало - значит, у тебя не все в порядке с головой.
> Не стоят эти "на 80%" того, чтобы связываться с С++Кроме случая когда вам надо из своего профита вычесть ценник в 2 раза большего парка серверов и подзатянуть пояса...
А ведь плюсам заметно полегчало после выхода С++11, вполне современный язык получился. Жаль, концепты зарезали
Ждем Сборщика мусора и удаление указателей. До этого момента использовать смысла нет.
> Ждем Сборщика мусора и удаление указателей. До этого момента использовать смысла нет.Не ждём. На ваши запросы полно других языков. Не знаете для чего применять язык программирования "среднего" уровня - юзайте исключительно "высокие".
> Не ждём. На ваши запросы полно других языков. Не знаете для чего
> применять язык программирования "среднего" уровня - юзайте исключительно "высокие".Плохому танцору всегда что-то мешает. У таких IT-таджиков проблемы с любыми языками. Но дело всегда в языке, конечно же.
> Плохому танцору всегда что-то мешает. У таких IT-таджиков проблемы с любыми языками.
> Но дело всегда в языке, конечно же.Тоже самое говорили любители ассемблера пока не исчезли.
Время динозавров прошло. Это эволюция.
> Тоже самое говорили любители ассемблера пока не исчезли.
> Время динозавров прошло. Это эволюция.Вы извините, но мы никуда не исчезли)
А динозавры исчезли не единомоментно. Они просто стали проигрывать конкурентную борьбу, не смогли приспособится к изменившимся условиям и вымерли.
Совсем как программисты на с++.
Простите, а на каком языке вы будете командовать процессору "переслать содержимое регистра А в регистр В"? На Java? На C#?
Как быть со встраиваемыми системами, где у одного МК 8Кб памяти? Что вы туда прикрутите?
Net Framework 2.0SP1?
Вы хорошую предметную область привели для демонстрации применения C/C++, но обсуждается совсем другое - веб-фреймворки. Про пользу высокоуровневых языков хорошо написал Пол Грэм ("Lisp - побеждая посредственность"). Увеличение производительности на 10% бессмысленно, если для этого надо написать в 4 раза больше кода и в 10 раз дольше искать в нем баги, разыменования NULL и утечки памяти. А сэкономленного времени хватит, чтобы оптимизировать алгоритм в целом и добиться производительности на уровне, близком к C
Увеличение производительности имеет смысл, если это увеличение необходимо. Если язык не позволяет увеличить производительность - значит, необходимо применять язык более низкого уровня. Сильная сторона низкоуровневых языков - в оптимальном решении задач, которые более высокоуровневые языки решают неоптимально.
О чем, собственно, спор? О случаях, когда производительность не играет роли? Для таких случаев вполне подходят любые языки. Но если создатель веб-фреймворка не заморачивается производительностью - результат вполне предсказуем...
Увеличить производительность помогает оптимизация главного алгоритма, а не оптимизация на мелочах. На худой конец, это может быть переписывание проблемного участка на C или ассемблере, но не всей программы целиком. Смена языка всей программы на более низкоуровневый - это именно оптимизация в мелочах. Почему сайты не пишут на ассемблере? Ассемблерные программы занимают восхитительно мало памяти и работают как из пушки, так в чем дело?> О случаях, когда производительность не играет роли? Для таких случаев вполне подходят любые языки
Иногда есть кое-что, играющее роль большую, нежели производительность программы - это производительность труда программиста. Если вы пишете код вчетверо быстрее (цифра не с потолка - программы на Эрланге приблизительно настолько компактней аналогов на C++), у вас будет куча свободного времени на выражение своих мыслей (вместо попыток запихать их в ограниченные термины низкоуровневого языка), и на оптимизацию тоже хватит.
> Иногда есть кое-что, играющее роль большую, нежели производительность программы - это производительность труда программистаИногда - да, но веб-сервер, как мне кажется, не относится к таким случаям. Он, однажды написанный, потом работает - возможно, в весьма нагруженном режиме. И производительность кода оказывается куда важнее, чем лишние пара дней, потраченные на разработку. С++ имеет достаточно готового кода в виде библиотек, чтобы по трудоемкости приближаться к более высокоуровневым языкам. Просто не нужно страдать велосипедизмом.
Это был вопрос к комментатору о ненужности ассемблера.
А зачем он нужен в 2012 году?
> А зачем он нужен в 2012 году?Посмотри сырцы x264, VP8, ... погоняй бенчи чисто севой версии и версии с асм-вставками и осознай зачем. Вот гуглу например - нужно, внезапно, в 2012 году. Коммитят, понимаешь, оптом и в розницу асмовые вставки в VP8 и тебя забыли спросить. Лучше скажи честно: ты деревяшка и не знаешь как работает компьютер. Поэтому тебе не судьба изобрести ни 1 эффективного алгоритма и даже просто понять что будет фактически сделано компьютером в ответ на то что ты накорябал в своей поделке и насколько сие (не)оптимально.
Эффективность *алгоритма* не зависит от языка - она зависит от самого алгоритма. Пузырьковая сортировка на достаточно больших массивах всегда медленнее быстрой сортировки независимо от языка реализации.
А эффективные алгоритмы таки существуют и на языках очень высокого уровня
Угу. Сложность - ага, не зависит от языка. Только кроме сложности есть ещё и константа. И константа эта может даже не в разы, а на порядки отличаться, а данные, знаете ли, могут иметь и предсказуемый объём. Это не говоря о том, что компилятор, забывший оптимизировать какой-то кусок в высокоуровневом языке и запихнувший копирование данных куда не надо запросто делает из O(N) O (N^2).
>Эффективность *алгоритма* не зависит от языкаАлгоритм может предполагать оперирование регистрами процессора. Для алгоритма вполне нормальна привязка к особенностям языка.
Друг, не оптимизируй ассемблером. Лучше вообще не оптимизируй. Иди плитку ложить, "программист"
Нет слова "ложить", есть слово "класть".
> не оптимизируй ассемблеромЗаблуждение, крайне распространенное среди специалистов, не работавших близко к микроархитектуре мощного не распределенного железа. (геймдев-кун)
> А зачем он нужен в 2012 году?Компиляторы с языков С и С++ не умеют максимально эффективно использовать
аппаратные возможности процессоров, например, векторные команды.
Да и сами языки не позволяют "намекнуть" компилятору, чтоб использовал
такие и сякие команды. С и С++ сами по себе -- принципиально SISD.
> Вы хорошую предметную область привели для демонстрации применения C/C++, но обсуждается совсем другое - веб-фреймворки.Так в том то и дело: хотелось бы веб-фреймворк и в ардуино тоже иметь.
А вы встраиваемые системы на Java не видели? :))) От вы темный, а! Идет на сайт Атмела и начинаем просвящаться
> Совсем как программисты на с++.Ну я надеюсь что у тебя операционка то на правильном ЯП написана, да? :)
К сожалению нет. Поэтому память течет, приложения крошатся, и эксплоиты лопатой выгребаю.
Но движение в правильном направлении идет.
> Но движение в правильном направлении идет.Ась? Ты уже написал кернель на чем-то правильном? Нет? Тогда срочно за дело. А то что-то медленно движение идет. Уж лет 40 как. Скока еще ждать то пока ты кернел на чем-то другом накорябаешь??? Я конечно не рисукну пользовать систему с кернелом от скриптокида но поржать было бы интересно.
Есть верифицированные микроядра, корректность которых доказана математически. Они конечно мало что умеют, но дело движется в правильном направлении :). Как вы понимаете, их пишут отнюдь не на сях
> Ась? Ты уже написал кернель на чем-то правильном? Нет? Тогда срочно за
> дело. А то что-то медленно движение идет. Уж лет 40 как.К вашему сведению linix ведет свою историю с сентября 1991 года, так что срок в 40 лет указан неверно.
> Скока еще ждать то пока ты кернел на чем-то другом накорябаешь???
> Я конечно не рисукну пользовать систему с кернелом от скриптокида но
> поржать было бы интересно.А почему необходимо сначала переписывать ядро? Логичнее постепенно переносить сначала пользовательское окружение потом все остальное. И тут работа ведется очень интенсивно.
Например Qt5 имеет javascript в качестве основного языка, а с++ рекомендуется использовать только для низкоуровневых задач. GTK 3+ поддерживает программы на javascript, но так же позволяет рендерить интерфейс в html. Windows 8 позволяет создавать нативный приложения используя js и html.
Так же показали свою эффективность системы в которых весь интерфейс использует html и js.
Не говоря о том что веб сервисы вытесняют настольные приложения. Так аудитория Gmail превосходит количество пользователей thunderbird в разы.
наверное имелся в виду Unix, который был первый на Си написан
А, так еще и виндузятник, что ли? Всё сходится - и эксплоиты выгребает, и "движение в правильном направлении" - дотнет, полагаю.
ололо
попробуй напиши сложное приложение под iOS без плюсовых либ
> Тоже самое говорили любители ассемблера пока не исчезли.Они так исчезли, что в 2012 году ВНЕЗАПНО крайне люто комитят в репу кодека VP8. То что они не занимаются гoвнокодингом энтерпрайзных поделок - ну так правильно, для этого есть тупые и дешевые наемные боты типа тебя. Для телег с ломом и лошадей используют, простите, ломовых.
Ананим, а ананим, по твоей логике выходит у всех руки кривые, а языки плохими быть не могут, так? Прапорщик такой прапорщик
> Ждем Сборщика мусора и удаление указателей. До этого момента использовать смысла нет.Ждите. Возможно, эти костыли и исправят чью-то врожденную криворукость...
А квалифицированные разработчики с некривыми руками кодят на сях уже сейчас.
Хм. В соседней новости http://www.opennet.me/opennews/art.shtml?num=33097Зыж
Нда. Чукча (даже со сборщиком мусора) не читатель.
Да и писатель не важнецкий.
Большинство ПО как разрабатывалось на С/С++, так и разрабатывается.
Видимо большинство написанного быдлокодерами сразу уничтожается в gc.
А если всё же выживает, то радует пользователей своими не повторимыми тормозами, глюками и мрсианским интерфейсом.
Сборщиков мусора под C++ полно разных на любой вкус. Но ты об этом не знаешь, поскольку ни строчки кода на нем не написал
Назовите пять работающих.
> Назовите пять работающих.1. JavaScript. Или в нем не работает? Или движок не на си не написан? Ню-ню :)
Чем оно лучше boost.asio?
Ничем. На asio тоже можно заниматься кодосокоращательством, а еще он стабильнее.
> Чем оно лучше boost.asio?Ну это как бы несколько разного уровня проекты и сравнивать их некорректно. Чем wget лучше netcat-а? С другой стороны, было бы логично иметь asio на бакенде. Не знаю, что они там заюзали под это.
Опять теплое с мягким, э?
отлично, лишь бы тут с "лапшой" не переборщили как в node.js.
> У node нет проблем с лапшой. Есть проблемы с программистами с java и с++ головного мозга, которые не могут асинхронный код.Ага. Мы просто назовём лапшу callbackов "The Node Way", а критиков («тяжело разбираться, т.к. нужно держать в уме все вложенные контексты», «мешает отловить утечку памяти» и пр.) — жалкими неасиляторами с C++ головного мозга. Потому как по сути возразить-то и нечего.
Лапша где? Приведите примеры.
> Лапша где? Приведите примеры.на первой же страничке https://github.com/languages/JavaScript/most_watched: &...раскрутите-ка https://github.com/isaacs/npm/blob/master/lib/init.js#L81
страшно подумать, какой ад локалхоста творится в проприетарных проектах на nodejs, которые по очевидным причинам поддерживаются менее опытными (не квалифицированными, разработка под nodejs не имеет ничего общего с квалификацией) разработчиками, чем те, которые ведут популярные проекты на гитхабе.
> на первой же страничке https://github.com/languages/JavaScript/most_watched: &...раскрутите-ка
> https://github.com/isaacs/npm/blob/master/lib/init.js#L81
> страшно подумать, какой ад локалхоста творится в проприетарных проектах на nodejs, которые
> по очевидным причинам поддерживаются менее опытными (не квалифицированными, разработка
> под nodejs не имеет ничего общего с квалификацией) разработчиками, чем те,
> которые ведут популярные проекты на гитхабе.Да не объясняйте вы ему ничего, человек явно упорот до безобразия, коли предлагает выпилить из С++ работу с указателями и кидается во всех какашками из-за мифических утечек (ну не знает он про RAII, бывает такое). У таких, как он, память и в языке "без указателей и с GC" течь будет :)
Мифических? 17 февраля 2017 в Thunderbird закрыто 12 дырок. Это в одной программе.
А 30 страниц утечек, переполнений, форматной строки, не инициализированных указателей и прочих особенностей с/с++, не хотите? И это только с начала года.
Я думаю за использование этих языков, давно пора наказывать, как за распространение вредоносного кода.
> Мифических? 17 февраля 2017 в Thunderbird закрыто 12 дырок. Это в одной программе.
> А 30 страниц утечек, переполнений, форматной строки, не инициализированных указателей и прочих особенностей с/с++, не хотите? И это только с начала года.
> Я думаю за использование этих языков, давно пора наказывать, как за распространение вредоносного кода.Thunderbird? Mozilla Thunderbird? В которой вообще вся бизнес-логика писана на Javascript, а на сишечке/плюсцах только интерпретатор этого самого JS + зависимости вроде libxml?
>Thunderbird? Mozilla Thunderbird? В которой вообще вся бизнес-логика писана на Javascript, а на сишечке/плюсцах только интерпретатор этого самого JS + зависимости вроде libxml?Вот именно! Вся логика на js, а все дырки на с++.
Смотрите сами, вышеупомянутые дырки:
CVE-2011-3659
incorrect AttributeChildRemoved notifications
CVE-2012-0442
memory corruption and application crash
CVE-2012-0443
memory corruption and application crash
CVE-2012-0444
memory corruption and application crash
CVE-2012-0447
do not properly initialize data for image/vnd.microsoft.icon
Продолжать?
вот так и имеют таких спецов во все щели, а он этого даже и не знает.
а если и узнает, то ждёт пока ему более умные заплатку вставят.
Именно поэтому не стоит использовать некачественное программное обеспечение.
Под некачественным, я понимаю, написанное на с/с++.
Ну что ж, вам осталось только выйти из браузера и ждать, пока его напишут на более правильном языке.
А потом еще подождать, когда таким браузером можно будет пользоваться.
Про то, что в продуктах Mozilla практически всё написано на JS (да-да, XUL, etc.) тебе уже сказали. Про то, что в продуктах Mozilla (по крайней мере в Firefox), используется так любимый тобой сборщик мусора ты решил скромно промолчать? И, о сенсация, если статистику расхода памяти посмотреть, то частенько текут именно JS объекты в сайтовых скриптах.Почему же сборщик мусора не помогает-то, а? Может, прежде чем на "высокоуровневом" языке писать, надо всё-таки понимать, что память таки под капотом выделяется где угодно, что циклические ссылки будут создавать утечку и при наличии GC? Кодовая база Firefox кстати тянется со времен Netscape. Ты не поверишь, но за это время в С++ произошли достаточно серьезные изменения, и то, что наблюдается в Firefox, не совсем правильно экстраполировать на новые проекты.
И еще одно, болезный. Как-бы ты тут не распинался, но JS - язык с динамической типизацией. Для "fire and forget" скриптов это хорошо, но есть одно большое но. Попробуй как-нибудь написать на этом node.js несколько десятков а то и сотен тысяч строк асинхронной лапши, да развивай свой проект лет 5-7. Ты потом в психушку попадешь, так как рефакторить код на динамически типизированных языках - это лютое зло, рефакторить же тонну асинхронного динамически типизированного кода - еще большее зло. У тебя юнит тестов будет написано больше, чем кода твоего приложения.
Да он совершенно оголтелый фанат JS,уже в нескольких тредах замечено. И всё убеждал,что статическая типизация не нужна.
> Да он совершенно оголтелый фанат JS,уже в нескольких тредах замечено. И всё
> убеждал,что статическая типизация не нужна.Пусть LZMA сначала на JS портанет, тогда поговорим.
http://lmgtfy.com/?q=LZMA+js
> http://lmgtfy.com/?q=LZMA+jsО, натурально есть. Правда код этой штуки выглядит довольно жутковато - половина кода вышло борьбой с искусственными трудностями, любезно предоставленными JS. Кстати как, не хочешь побенчить скорость работы относительно нативной версии и вместе поржать над тем что получится? :)
>побенчитьПожалейте русский язык.
Если вы хотите сравнить скорость работы реализаций то пожалуйста, только сравнивать нужно в равных условиях. А так как реализация на js по умолчанию безопасна, а реализация на с/с++ нет, то запускать "нативную" реализацию необходимо, хотя бы в контейнере Рутковской. Мы ведь не хотим дарить свой компьютер первому попавшемуся?
"Первый попавшийся" - это код из веба. В отличие от софта из репозиториев, от разработчиков с многолетней репутацией. Поэтому для первого приходится городить параноидальную матрешку из песочниц, а второй моно просто запустить в своей системе. Впрочем, если месье не понимает, что всегда есть tradeoff между удобством/дешевизной (куда и скорость включена, конечно) и безопасностью - то что тут сказать. А в номре надежность линукс-систем вполне достаточна.
Так где лапша?
или стандартная конструкция
promice()
(...)
(...)
(...)
Показалась лапшой?
Лапша это большое количество вложенных конструкций. Например как тут
https://github.com/torvalds/linux/blob/master/kernel/irq/aut...
Лапша - это потеря линейности кода. Когда, взглянув на код, не видишь, в каком порядке он исполняется. А для вложенных конструкций - сюрприз! - этот порядок виден с первого взгляда, хотя бы за счёт отступов. Ну да что с вами спорить, если вы не понимаете, выгодно скоращать количество возможных ошибок в коде за счёт статической типизации.
> Лапша - это потеря линейности кода. Когда, взглянув на код, не видишь,
> в каком порядке он исполняется. А для вложенных конструкций - сюрприз!
> - этот порядок виден с первого взгляда, хотя бы за счёт
> отступов. Ну да что с вами спорить, если вы не понимаете,
> выгодно скоращать количество возможных ошибок в коде за счёт статической типизации.Не надо пытаться совершить подлог. Это старый устоявшийся термин, а совсем не то что вы нафантазировали.
http://lmgtfy.com/?q=Spaghetti+code&l=1
Кхх. Ну вот оттуда цитата: "source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled". Это и относится к тому чуду, которое вы мне показали. Или хотите сказать, что там поток исполнения понятен и прозрачен?
Вам, похоже, требуется перевод?
Могу и сам перевести: Исходный код, имеющий сложную и запутаннуюю структуру, особенно использующий много GOTO, исключений, потоков или других "неструктурированных" конструкций ветвления. Он так назван потому что поток управления имеет склонность выглядеть как куча спагетти, т.е. переплетенным и иискривленным.напомню, речь идет вот об этом: https://github.com/isaacs/npm/blob/master/lib/init.js#L81
Окей, если не понимаете, что там не так - объясняю.
Маоло того, что функцию надо бы разбить на куски просто из соображений размера, так еще и набор странно отформатированных коллбеков там, где хватило бы линейного кода, управляющего последовательностью запросов. Асинхронность (и, соотвественно, promice) там не нужна вообще - это утилита, в данной точке control flow в принципе не способная ничего сделать, пока не получит весь ввод от пользователя.
А еще лучше было бы не просто заменить promiseChain на последовательность циклов ввода, а выделить каждую функцию проверки отдельно (можно внутри основной) и дать ей имя, сделать явный массив со структурами "приглашение + функция проверки", а в основной функции просто сделать цикл по нему. И вместо этого "кто на ком стоял" была бы абсолютно самодокументированная конструкция, понятная с первого взгляда на первой секунде.
Вообще дурацкая джаваскриптовая традиция кучу всего объявлять in place (да еще неименованным) сильно мешает читабельности. Я еще (кое-как) понимаю, когда это делается для браузера с целью уменьшения размера кода, но на сервере такое применять - идиотизм.
> и с++ головного мозга, которые не могут асинхронный код.То-то все кернелы сплошь забиты машинами состояний и асинхронщиной которая на одном проце который физически выполняет 1 поток инструкций умудряется реализовывать иллюзию многозадачности и уж конечно все воспринимают как данность что через сетевку висит 50 соединений хотя проц - один. Ты там кого лечить вздумал, клоун?
>с++
>кернелыЯ совершенно не знаю, что вы называете "кернелами", но подразумевая, что это ядро линукс, хочу отметить что с++ кода в нем нет, вообще нет.
>которая на одном проце который физически выполняет 1 поток инструкций умудряется реализовывать иллюзию многозадачностиТаненбаум молодец, кто спорит. Жаль что дальше пошла деградация.
Плюсов - нет. А асинхронности - причём вменяемой - вагон.
А Танненбаума вы вообще непонятно к чему приплели. Многозадачные операционки появились лет на 15 раньше того же миникса.