В фильмах они разные, потому что. В самом первом был только обычный Star Destroyer, который меньше километра в длину. Во втором уже был Super Star Destroyer, который под 20км — и там для масштаба была пара кадров, где его показывали на фоне пары обычных спереди.
>> Все входные и выходные коллекции LINQ-операций имеют базовый тип IEnumerable<>, исходя из ограниченных возможностей которого, многие операции подразумевают лишние затраты: полный последовательный перебор или даже создание промежуточных копий входных коллекций.
На самом деле, в LINQ очень много где встречаются проверки типа входящего IEnumerable, чтобы реализовать операцию более эффективно, если это ICollection или там IList. Например, Enumerable.Count просто вернет ICollection.Count, если он доступен на данном объекте.
Аналогично с промежуточными результатами. Например, Where возвращает IEnumerable, но если его снова передать в Where, то там есть проверка на этот конкретный тип, и она просто добавит дополнительное условие напрямую.
Там несколько криво сказано, но private assemblies совершенно необязательно ставить инсталлером — это обычные файлы, и их можно просто скопировать, лишь бы в манифесте приложения было сказано, где их искать.
В ближайшее время я тоже не верю. В перспективе солнечное вполне может стать таким.
А зачем обязательно «холодный» термояд? Можно и нормальный, просто на него все урезают и урезают бюджеты, а потом удивляются, почему он все время «через двадцать лет».
Насколько я понимаю, проблема не с наличием запасов, а со стоимостью их разработки. Условно говоря, на каждой новой итерации, «свежеоткрытые» запасы (о них зачастую известно и ранее, просто их всерьез не рассматривали) намного сложнее достать, чем предыдущие — если когда-то можно было просто тупо качать из мелкой скважины на земле, сейчас приходится городить огород с платформами в океане и битумными песками.
Да, именно все в одном, чтобы ставить брейкпоинты где угодно, и прозрачно ходить по Step Into из одного языка в другой и обратно. Как в VS поддержка native+managed отладки. Мне кажется, аналог для JNI в частности уже давно напрашивается.
У меня интерес к этой теме на самом деле не столько даже как пользователя, сколько как автора соответствующей фичи в PTVS — узнать, когда основные конкуренты планируют это реализовывать :)
Странные возражения. Да, HTML — декларативный язык. Но и рассмотренные варианты биндингов тоже стопроцентно декларативны. Похоже, что человек путает понятия «декларативность» и «разделение данных и презентации».
Поддержка IDE — это из разряда «пока не сделали», да и то многие уже как раз сделали, а у иных есть расширяемые API, через которые это можно сделать со стороны. В VS, например, можно тривиально написать поддержку подстветки, code completion и всего такого прочего для вложенного в HTML языка биндингов. Аналогично все остальное — например, ничто не мешает IDE поддержать установку брейкпоинтов на такие биндинги, автоматически транслируя это в соответствующие брейкпоины в JS (правда, для этого фреймворк должен быть написан с учетом подобных требований).
Теперь, когда у вас есть плюсовая среда с отладкой, есть ли планы реализации многоязыковой отладки? Т.е. например Java/C++ с JNI, или Python/Cython/C++?
Я для проверки анализа плюсов в IDE пользуюсь таким вот кодом:
template<size_t N = sizeof(void*)> struct a;
template<> struct a<4> {
enum { b };
};
template<> struct a<8> {
template<int> struct b {};
};
enum { c, d };
int main() {
a<>::b<c>d;
d;
}
После чего переключаю target с 32-битного на 64-битный в настройках проекта, и смотрю, что будет в редакторе. Если все реализованно корректно, то первая строка в main должна менять смысл с объявления переменной «d» на выражение с двумя операторами < и >, и обратно. Соответственно, семантическая подсветка должна соответствующим образом подкрашивать «d» либо как как локальную переменную, либо как член enum'а; и всякие там Go to Definition, Find References, и наличные рефакторинги вроде Rename, должны корректно отрабатывать.
Они определенно сделают лучше те части, которые имеют отношение непосредственно к Qt. А вот как, например, там обстоит дело с редактированием кода вообще — подсказки, автокомплит, рефакторинг? В последний раз, когда я его смотрел, там это все было в состоянии, типичном для C++ IDE где-то пятилетней давности — т.е. робкие попытки распарсить плюсы «по-простому», загинающиеся на мало-мальски сложном коде с шаблонами. Для самого Qt этого хватает, а вот когда начинается активное использование STL и Boost — уже нет.
Рано радуетесь — не «невозможна», а «мы пока еще не знаем, как». В принципе, очевидно, что если мыслительные процессы по своей природе электромагнитные, то их вполне можно индуцировать извне. Так что брейнспаму — быть.
D хоть и претендует, но идеологически он имхо ближе к Go. В частности, тем, что в нем есть GC (да, теоретически, его можно отключить — но на практике, на него завязана стандартная библиотека).
Rust — это именно что попытка сделать современный C++ с нуля — по-прежнему максимально близко к железу, никаких там GC, но safe by default.
Rust — это как раз о том, что можно иметь тот самый zero overhead как в плюсах, но со значительно более вменяемыми гарантиями безопасности. Вы вообще приведенное смотрели/читали?
На самом деле, в LINQ очень много где встречаются проверки типа входящего IEnumerable, чтобы реализовать операцию более эффективно, если это ICollection или там IList. Например, Enumerable.Count просто вернет ICollection.Count, если он доступен на данном объекте.
Аналогично с промежуточными результатами. Например, Where возвращает IEnumerable, но если его снова передать в Where, то там есть проверка на этот конкретный тип, и она просто добавит дополнительное условие напрямую.
Все-таки доставать параметры со стека и паковать туда обратно значения — невеликое удовольствие.
А зачем обязательно «холодный» термояд? Можно и нормальный, просто на него все урезают и урезают бюджеты, а потом удивляются, почему он все время «через двадцать лет».
Стоимость ветрового и солнечного электричества (особенно последнего) тоже постепенно падает. Рано или поздно эти два графика пересекутся.
И тогда мы наконец перестанем тупо жечь нефть, и будем использовать её для всего остального, что вы перечислили — пластмассы etc.
У меня интерес к этой теме на самом деле не столько даже как пользователя, сколько как автора соответствующей фичи в PTVS — узнать, когда основные конкуренты планируют это реализовывать :)
Поддержка IDE — это из разряда «пока не сделали», да и то многие уже как раз сделали, а у иных есть расширяемые API, через которые это можно сделать со стороны. В VS, например, можно тривиально написать поддержку подстветки, code completion и всего такого прочего для вложенного в HTML языка биндингов. Аналогично все остальное — например, ничто не мешает IDE поддержать установку брейкпоинтов на такие биндинги, автоматически транслируя это в соответствующие брейкпоины в JS (правда, для этого фреймворк должен быть написан с учетом подобных требований).
После чего переключаю target с 32-битного на 64-битный в настройках проекта, и смотрю, что будет в редакторе. Если все реализованно корректно, то первая строка в main должна менять смысл с объявления переменной «d» на выражение с двумя операторами < и >, и обратно. Соответственно, семантическая подсветка должна соответствующим образом подкрашивать «d» либо как как локальную переменную, либо как член enum'а; и всякие там Go to Definition, Find References, и наличные рефакторинги вроде Rename, должны корректно отрабатывать.
Rust — это именно что попытка сделать современный C++ с нуля — по-прежнему максимально близко к железу, никаких там GC, но safe by default.