есть такая проблема, как и со скоростью рендера пдф,
А можно расшарить какой-нибудь pdf который у вас медленно открывается?
Просто наиболее быстрый рендер pdf из мне известных (mupdf) изначально под linux разрабатывался, и было бы интересно какая программа "только под windows" работаем быстрее его?
Can a living organism have a setter? Can you "set" a ball to a dog? Not really. But that is exactly what the following piece of software is doing:
Dog dog = new Dog();
dog.setBall(new Ball());
How does that sound?
Can you get a ball from a dog? Well, you probably can, if she ate it and you're doing surgery. In that case, yes, we can "get" a ball from a dog. This is what I'm talking about:
и полагаю что такие обширные области как математика или прикладное программирование требуют всех возможностей интеллекта для разных классов задач
и свести все кто одному фактору типа "быстрая память" будет ошибочным упрощением.
И не связана ли возможность "отличника" быстро щелкать примеры с тем
что он в десятки, а возможно и в сотни раз больше задачек решил, чем троечник (
который например банально не делает домашнее задание) и тем самым просто натренировался как "собака Павлова"?
какой-то ерунды с датами (2003 год — "разгар фиаско Висты", что?!)
Microsoft began work on Windows Vista, known at the time by its codename Longhorn, in May
2001,[22] five months before the release of Windows XP. It was originally expected to ship
sometime late in 2003
Ну как я понимаю 2003 был первым пропущенным deadline'ом,
в чем противоречие?
Да лучше уж С-шные обертки экспортировать, чем этот ужас.
А как сделать-то? Захочешь например чтобы могли наследовать объекты в других языках и вот вместо наследования C++: struct Derive { struct Base base; };
захочешь чтобы виртуальные функции могли переопределять в других языках и вместо virtual у тебя указатели на функции, вместо неявного this передается
явно указатель на структуру, и сколько c++ от c++ останется?
Насколько я понимаю, основное преимущество C (с точки зрения разработчиков gtk+), над остальными языками это ABI.
C C++ проблема даже использовать библиотеку скомпилированную одним компилятором,
из библиотеки/программы собранной другим компилятором C++. А чего уж говорить о взаимодействии с другими языками программирования.
но подозреваю что это совсем не просто — иначе зачем бы его забрасывали?
Наверное потому что на самом деле он мало кому нужен,
ведь все основные платформы поддерживаются, а все остальное нужно очень мало числу людей.
Сишный бэкенд LLVM, насколько я знаю, заброшен очень давно уже
https://github.com/JuliaComputing/llvm-cbe это отдельный от llvm проект.
И куда там развиваться? LLVM IR вроде бы стабильный, если проект обрабатывает
достаточно большое подмножество и делает это правильно, то развиваться дальше практически некуда.
Еще есть мой проект https://github.com/Dushistov/rust_swig для генерации c++ обертки для rust кода. Он как бы в обратную сторону от bindgen, для вызова rust кода из c/c++,
а не для вызова c/c++ из rust что сделано в bindgen. Права в отличии от jni/java backend, c++ backend только в начале развития.
Платформы:
поддержка компиляции в С код
использование GCC в качестве backend'а
Противоречиво выглядит,
во-первых почему два пункта, если мы умеем rust->C, значит финальный
бинарник можно и с помощью gcc сгенерировать, в чем может быть проблема?
во-вторых есть https://github.com/JuliaComputing/llvm-cbe llvm C backend,
если в нем что-то не работает то не проще ли его доработать, чем городить
велосипед для генерации rust->C?
Как-то непонятно в течении статьи пропадает Android разработка.
Сначала упоминается в составе команды Android разработчики,
а потом swift, appstore и остался только iOS. По ходу статьи всех разработчиков под Android уволили?
>если array2 имеет достаточно валидных индексов (не менее k штук), а мы можем снаружи >более-менее прямым способом побудить атакуемую программу его почитать, то на индексе >k операция чтения выполнится быстрее, чем на других индексах, так как он уже закэширован.
Вот это непонятно, ну да в другой программе что-то закэшировано и будет выполняется быстрее.
А как мы измерим время работы другой программы с точностью необходимой для отличия незакэшированных данных от кэешированный?
Нет в жизни счастья, с одной стороны clion с rust плагином, с другой qt creator с поддержкой .ui файлов, qt документации и стилей из clang-format
А можно расшарить какой-нибудь pdf который у вас медленно открывается?
Просто наиболее быстрый рендер pdf из мне известных (mupdf) изначально под linux разрабатывался, и было бы интересно какая программа "только под windows" работаем быстрее его?
Насколько это усложнило установку Linux туда второй системой?
Потому что у PostgreSQL есть еще PL/Python, PL/Tcl и бог знает что еще, кроме PL/pqSQL.
А в чем смысл ревью всей ветки сразу целиком? Слишком лениво разбивать на логические
и завершенные коммиты?
Вообще-то они все гугловские. Просто команда из google их реализовала для gcc и clang в свое время.
В этом контексте есть интересный blog post: getters-and-setters-are-evil,
цитата оттуда:
Есть Цикломатическая сложность некоторые linter'ы ее умеют считать и выдавать предупреждение, например rust-clippy
Есть исследования утверждающие что "общий" интеллект нельзя свести к одному фактору:
http://www.cell.com/neuron/abstract/S0896-6273(12)00584-3
и полагаю что такие обширные области как математика или прикладное программирование требуют всех возможностей интеллекта для разных классов задач
и свести все кто одному фактору типа "быстрая память" будет ошибочным упрощением.
А почему "троечник" не может решить пример в три действия?
И не связана ли возможность "отличника" быстро щелкать примеры с тем
что он в десятки, а возможно и в сотни раз больше задачек решил, чем троечник (
который например банально не делает домашнее задание) и тем самым просто натренировался как "собака Павлова"?
Ну как я понимаю 2003 был первым пропущенным deadline'ом,
в чем противоречие?
А как сделать-то? Захочешь например чтобы могли наследовать объекты в других языках и вот вместо наследования C++:
struct Derive { struct Base base; };захочешь чтобы виртуальные функции могли переопределять в других языках и вместо
virtualу тебя указатели на функции, вместо неявногоthisпередаетсяявно указатель на структуру, и сколько
c++отc++останется?Насколько я понимаю, основное преимущество
C(с точки зрения разработчиковgtk+), над остальными языками это ABI.C
C++проблема даже использовать библиотеку скомпилированную одним компилятором,из библиотеки/программы собранной другим компилятором
C++. А чего уж говорить о взаимодействии с другими языками программирования.Наверное потому что на самом деле он мало кому нужен,
ведь все основные платформы поддерживаются, а все остальное нужно очень мало числу людей.
https://github.com/JuliaComputing/llvm-cbe это отдельный от llvm проект.
И куда там развиваться? LLVM IR вроде бы стабильный, если проект обрабатывает
достаточно большое подмножество и делает это правильно, то развиваться дальше практически некуда.
Еще есть мой проект https://github.com/Dushistov/rust_swig для генерации
c++обертки для rust кода. Он как бы в обратную сторону от bindgen, для вызова rust кода из c/c++,а не для вызова c/c++ из rust что сделано в bindgen. Права в отличии от jni/java backend, c++ backend только в начале развития.
Противоречиво выглядит,
во-первых почему два пункта, если мы умеем rust->C, значит финальный
бинарник можно и с помощью
gccсгенерировать, в чем может быть проблема?во-вторых есть https://github.com/JuliaComputing/llvm-cbe llvm C backend,
если в нем что-то не работает то не проще ли его доработать, чем городить
велосипед для генерации rust->C?
Как-то непонятно в течении статьи пропадает Android разработка.
Сначала упоминается в составе команды Android разработчики,
а потом swift, appstore и остался только iOS. По ходу статьи всех разработчиков под Android уволили?
Ведь явно даже программа предоставляющая COM/dbus интерфейс не подходит так как там «оверхед» в виде инструкций работающих с памятью там присутсвует.
Вот это непонятно, ну да в другой программе что-то закэшировано и будет выполняется быстрее.
А как мы измерим время работы другой программы с точностью необходимой для отличия незакэшированных данных от кэешированный?
Это все еще так? Вроде последнее поколение оперативной памяти всего лишь
раза в 1.5 уступает в частоте написанной на упаковке?