C++, который мы потеряли

держи лайфхак: с - русская. Кстати, почему у тебя с++ в игнорируемых тегах?

Ну рефлексия в цпп - это примерно тоже самое, что если на жигуль поставить бортовой компьютер космического корабля и реактивный двигатель. Это то, что в теории возможно, но практически абсолютно нереализуемо из-за фундаментальных ограничений.

Ты хочешь чтоб прям стандарт ISO?

Дык, спор разве не с этого начался? А «хоть какая-то спека» есть у почти любого языка.

потому что я ненавижу кресты, и не хочу ничего про них читать или принимать участие в обсуждении.

Ну рефлексия в цпп - это примерно тоже самое, что если на жигуль поставить бортовой компьютер космического корабля

Так все новшества в плюсах именно так и выглядят. Чуваки из комитета не зря задвинули эту пачку кулфич, а то совсем уже порнография получается.

в теории возможно, но практически абсолютно нереализуемо из-за фундаментальных ограничений.

Назовешь ограничения?

менять местами выполняемые операции в функции

Это даже стандарт си позволяет.

Тот факт, что какие-то там переменные кешируются в выполняемой ните (Thread) — ещё не обозначает что операции могут происходить РАНЬШЕ, чем об этом поросит программист в своём ява-коде..

И *реализация* OpenJDK вполне-очевидно подтверждает это поведение — ветка кода которая ещё не начала исполяться (по ходу алгоритма) — действительно не начала исполяться...

...а вот мутная спецификация — даёт волю фантазии её теоретиков-трактователей :-)

Хорошо хоть что практика в том что на данный момент (сегодня) кроме OpenJDK — нет других Ява-Запускалок :-) .. Иначе бы кросплатформенность Явы была бы щаз бы всё ещё такая же как и между Adobe Flash Player и GNU Gnash :-)

Хорошо хоть что практика в том что на данный момент (сегодня) кроме OpenJDK — нет других Ява-Запускалок

Шутишь? Этих запускалок как собак нерезаных. IBM J9, Oracle WebLogic (или они его уже закопали?), Azul, gjc это только то, что сходу вспомнилось.

Oracle WebLogic

ты хотел сказать, JRockit.

+ имхо там на первое место надо поставить ExcelsiorJET

Почему в C++ считается ужасным (Страуструп, вроде, переживал), что printf не проверяет при компиляции тип передаваемого ему значения для вывода, а из-за отсутсвия проверки выхода за пределы массива не переживают?

Проверку выхода за пределы массива нельзя сделать во время компиляции. Проверку типов для ввода/вывода - можно.

Проверку выхода за пределы массива нельзя сделать во время компиляции.

В ряде других языков же сделали.

Проверку типов для ввода/вывода - можно.

Подстановка в printf вместо кодов (%) разве не во время выполнения происходит?

Шутишь? Этих запускалок как собак нерезаных. IBM J9, Oracle WebLogic (или они его уже закопали?), Azul, gjc это только то, что сходу вспомнилось.

если на этих запускалках какой-то софт не запустится как-надо — то это даже не будет щитаться багом этого софта :-D :-D ...

точнее говоря — слово «если» надо заменить на что-то другое — так как врядли вообще хоть что-то там можно запустить :-) вменяемое

какие из этих запускалок поддерживают 52-версию class-файлов?

Есть планы потерять, наконец, и остаток языка?

мелкостудии они есть, так что есть девелопишь под один лялих

Как сочетаются мелкостудия и лялих?

stevejobs ★★★★★ (32.03.2016 13:06:05)

Это первоапрельское эхо?

В ряде других языков же сделали.

Примеры языков в студию.

Подстановка в printf вместо кодов (%) разве не во время выполнения происходит?

В каком языке? В C/C++ обработка флагов printf в рантайме происходит.

ещё не обозначает что операции могут происходить РАНЬШЕ, чем об этом поросит программист в своём ява-коде..

При чем тут вообще ява-код, если операции могут переставляться на уровне процессора и вмешаться туда нельзя ни из джавы, ни (даже) из сишки/ассемблера?

Примеры языков в студию

Компилятор Intel Fortran может отслеживать выход за границы; Delphi. Можно ещё поискать среди компилируемых, разумеется.

В C/C++ обработка флагов printf в рантайме происходит.

Вот, вот. Во время выполнения.

Получается, что если дело касается массива, то подход: «ты ж программист», ты должен понимать, что делаешь; если вывода, то: «этому дегенерату нельзя доверять, мало ли что он туда подставит».

Компилятор Intel Fortran может отслеживать выход за границы

Некоторые компиляторы С++ в некоторых случаях тоже: https://godbolt.org/g/UeXwRo

Кроме того, есть туева хуча случаев, когда и размеры массивов, и индексы для доступа к ним, становятся известны только в run-time. Что прикажете делать в этих случаях?

Получается, что если дело касается массива, то подход: «ты ж программист», ты должен понимать, что делаешь; если вывода, то: «этому дегенерату нельзя доверять, мало ли что он туда подставит».

Это разные проблемы и решаются они разными способами.

если на этих запускалках какой-то софт не запустится как-надо — то это даже не будет щитаться багом этого софта :-D :-D ...

Да прям. Вот купил ты корпоративную лицензию жиры за офигион факсов на сто тыщ юзеров, а на твоём IBM сервере оно не пускается. Думаешь не пофиксят? Аж вприпрыжку побегут фиксить, я тебя уверяю. Вопрос в деньгах.

точнее говоря — слово «если» надо заменить на что-то другое — так как врядли вообще хоть что-то там можно запустить :-) вменяемое

Ну вообще на J9 крутятся сотни миллионов строк кода. Сам сталкивался. Нормальная JVM.

какие из этих запускалок поддерживают 52-версию class-файлов?

Не знаю. А кому они нужны? Энтерпрайз сидит на 1.4, особо продвинутые на 1.6 максимум.

Компилятор Intel Fortran может отслеживать выход за границы; Delphi. Можно ещё поискать среди компилируемых, разумеется.

Отслеживает ценой накладных расходов во время выполнения. В каждом обращении по индексу стоит проверка выхода за пределы массива, вот и вся магия. В дельфях даже специальная директива есть, чтобы отключать эту проверку в самых горячих местах.

Отслеживает ценой накладных расходов во время выполнения.

Для Release флаг можно отключить. Никто не говорит, что эти флаги компиляции должны быть включены всегда.

Ну так assert никто не отменял, и все C++ контейнеры имеют 100500 проверок в дебаге, которых нет в релизе. В том числе и проверку выхода за пределы массива.

То есть здесь опять всё отдаётся в руки разработчику, а не компилятору? С динамическими массивами, не спорю, сложнее реализовать проверку компилятором.

Речь, в общем, даже не об этом, а о том, что в одних местах предлагают делать проверки фактически самому, а в других переживают, что разработчик может забыть проверить.

Я из любопытства интересуюсь, почему такой немного двоякий подход.

Я из любопытства интересуюсь

Можно я из любопытства поинтересуюсь, почему вы считаете, что «С динамическими массивами, не спорю, сложнее реализовать проверку компилятором»? Слово «сложнее» подразумевает возможность реализации такой проверки компилятором. Так вот любопытно, почему вы считаете, что такие проверки вообще возможны?

Это традиции C/C++.

Да, хрень вышла. Для динамических такая проверка невозможна, но для статических то почему в компиляторах почти нигде не реализуют (за ссылку спасибо)?

стандарт

Java Standard Edition 7

платформ

oracle, openjdk

например

корпорацией «Яблоко»

И в чём же разница между спецификациями Java и стандартом С++?

нет, не с этого. никто не сказал «стандарт ISO»

Это не стандарт, это документация к языку. Стандарт это когда какие-то левые дяди собираются и решают, что и как должно быть. А документация — это когда ты сделал свой язык и потом написал к нему описание, что куда и как.

а из-за отсутсвия проверки выхода за пределы массива не переживают?

std::array<int, 10> x;
x->at(12);

ЧЯДНТ ?

Стандарт это когда какие-то левые дяди собираются и решают, что и как должно быть.

Внезапно, при разработке любого языка именно так и происходит.

А документация — это когда ты сделал свой язык и потом написал к нему описание, что куда и как.

Так не бывает: сперва делают документацию, а потом уже по ней язык. Иначе, как вы объясните программисту того же JDK что именно надо реализовать?

Во-первых, потихоньку таки реализуют. Раньше и тех предупреждений, которые сейчас выдают gcc и clang не было. Кстати говоря, потихоньку реализуют и проверки для форматных строк printf-функций (т.е. если написать %s, а передать int, то gcc/clang может и ругнуться).

Во-вторых, вектор развития идет в сторону такого API, чтобы ошибки исключались в принципе. Например, вместо ручной работы с динамическими массивами рекомендуется использовать std::vector, вместо статических массивов — std::array. Эти классы предоставляют begin/end (что автоматически подхватывается в range for), метод at() со встроенной проверкой выхода за границы, кроме того, в vector/array хранится размерность вектора, что так же исключает определенный класс ошибок. Плюс добавляются классы вроде span<T> и string_view.

Что касается printf-like функций, то их уже давно можно рассматривать как низкоуровневые функции, которые не следует использовать без крайней на то необходимости. А вместо них применять другие, более современные инструменты. Скажем, внешние библиотеки (cppformat, tinyformat, boost.format) или даже штатные ostream из стандартной библиотеки C++.

Т.е. в C++ постепенно наслаивается несколько уровней, самые верхние из которых обеспечивают безопасность, но ценой некоторых накладных расходов (хотя и не всегда больших), а внизу — старые небезопасные средства, унаследованные от языка C.

Стандарт это когда какие-то левые дяди собираются и решают, что и как должно быть.

Именно так и происходит в джаве, есть вот такая штука: https://www.jcp.org

Статья про то, откуда в JDK берутся фичи: http://blog.takipi.com/java-9-behind-the-scenes-where-do-new-features-come-from/

Если появилась какая-то фича, недостаточно просто иметь реализацию (осоенно если ты незнаешь как ее реализовать), её еще надо протащить через JCP. (ну или поддерживать свой форк)

Я про джаву не спорю, такой же упоротый язык, как и С++ получился. Нормальный язык может сделать только один человек, но никак не «сообщество».

Это потому, что в C++ есть два уровня кода: системный и пользовательский.

Системный как раз и является С-с-классами. На нем реализуют все контейнеры и прочие потроха. Надо же их на чём то писать, желательно с прямым доступом к памяти.

На пользовательском уровне никакого доступа с сырым данным быть не должно. Поэтому вместо сишных массивов есть std::array, вместо printf - std::out и тд. Но внутри они используют все те же сишные массивы и printf.

В нормальном, современном C++ коде никакой ручной работы с памятью нет, и быть не должно. Увы, но это нельзя физически ограничить.

C++ сильно не хватает блока unsafe, как в современных языка. Вот его принятие в стандарт меня и волнует. Но пока не предвидится.

Кстати, есть какой-нибудь вдумчивый ман, описывающий паттерны и практики современных крестов, состояние на 2016 год? В том числе касательно стека технологий/фреймворков/библиотек. Грубо говоря, если набрать в гугле «C++ smart pointer library», то вывалится более 300 тысяч результатов, и все они когда-то были правильными, но на 2016 год правильный ответ только один. Или например, можно написать паттерн визитор, а можно подпихнуть какой-нибудь генератор паттерн-матчеров, и опять же на 2016 год диапазон рекомендованных решений отличается от миллиона ответов в гугле. Хотелось бы вот такой сборник правильных ответов.

Нет такой вещи, как «правильный C++». Поскольку C++ применяется в широчайшем спектре прикладных областей, начиная от жесткого embedded, где нет ни исключений, ни RTTI, ни new с delete, ни рекурсивных вызовов функций, заканчивая какими-нибудь высокопроизводительными вычислениями, распознаванием образов и т.д.

Даже если взять то, как заставляют программировать на C++ в Google и в Facebook-е — это две очень большие разницы (при этом в Google реально сильно упоротые правила, но зато все про них знают и молятся на Google C++ Style Guide как на икону).

Тем не менее, вменяемый C++ движется куда-то сюда: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md/

При чем тут вообще ява-код, если операции могут переставляться на уровне процессора и вмешаться туда нельзя ни из джавы, ни (даже) из сишки/ассемблера?

при чём тут перетурбации процессора, когда я говорю о том что запускалка-кода — поменяла сам алгоритм программы: началось выполняться действие *с-побочным-эфектом* ещё раньше чем проверилось логическое условие на его выполнение..

[при том что референсная OpenJDK — так не делает]

процессор может сгруппировать некоторые операции (и именно на этом основании переставить операции местами).. и конвеер процессора даже может начать выполнять некую-ветку-кода-наперёд-раньше-времени — но не произойдёт ни чего такого чтобы имело бы необратимый побочный эффект от выполнения этой ветки :-)

где пруфы? ссылку, сестра

Чтобы использовать Google Codestyle нужно много нестандартных библиотек написать. Например для жизни без exceptions

внутри

Вот когда так говорят, то подразумевают что есть какая-то обертка, которая занимает ресурсы. Но из-за шаблонов вся лапша стирается и остаются мишный массивы, указатели и тд

Автор статьи на хабре так и не понял суть string_view и думает что это замена референсов и все

где пруфы? ссылку, сестра

вот ссылка — http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ..

вокруг этой статьи — уйма теоретиков уже написало тонны статей :-) в своих блогах...

вот эта самая фраза, показывающая суть мутной спецификации:

When run on a system using the Symantec JIT, it doesn't work. In particular, the Symantec JIT compiles

singletons[i].reference = new Singleton();

to the following (note that the Symantec JIT using a handle-based object allocation system).

0206106A   mov         eax,0F97E78h
0206106F   call        01F6B210                  ; allocate space for
                                                 ; Singleton, return result in eax
02061074   mov         dword ptr [ebp],eax       ; EBP is &singletons[i].reference 
                                                ; store the unconstructed object here.
02061077   mov         ecx,dword ptr [eax]       ; dereference the handle to
                                                 ; get the raw pointer
02061079   mov         dword ptr [ecx],100h      ; Next 4 lines are
0206107F   mov         dword ptr [ecx+4],200h    ; Singleton's inlined constructor
02061086   mov         dword ptr [ecx+8],400h
0206108D   mov         dword ptr [ecx+0Ch],0F84030h

As you can see, the assignment to singletons[i].reference is performed before the constructor for Singleton is called. This is completely legal under the existing Java memory model, and also legal in C and C++ (since neither of them have a memory model). 

вплодь до сегодняшнего года [не смотря на то что уже кучу лет прошло] — вновь и вновь эту фразу пофторяют хабрамакаки...

и какого-либо работающего (на сегодняшний день) доказательства — разумеется в интернетах не существует :-)

Не обязательно.

Хватает индивидов, которые запрещают использовать исключения на уровне местячковых code guide. Но при этом не запрещающих исключения физически на уровне ключей компилятора. А так же не обращающих внимание на то, что любой обычный new в таких условиях может бросить исключение. И что при работе с STL-ем могут быть исключения.

Логика при этом простая и железная: с исключениями сложно, поэтому мы будем без исключений. А если где-то выскочит bad_alloc или еще что-нибудь, то просто упадем и рестартуем.

There exist a number of common but dubious coding idioms, such as the double-checked locking idiom, that are proposed to allow threads to communicate without synchronization. Almost all such idioms are invalid under the existing semantics, and are expected to remain invalid under the proposed semantics.

из комментария к JSR-133 (написанного тем же самым Bill Pugh, благодарность которому есть на первой странице Спеки, кстати)

http://www.cs.umd.edu/~pugh/java/memoryModel/archive/att-0417/02-jsr.txt

забей, этой фичи не существует, как и ее поддержки соответственно

если ты считаешь, что «This is completely legal under the existing Java memory model» неверно, покажи место в JMM которому это поведение противоречит

Я думаю, сейчас многие плюсовики будут поглядывать на rust.

Не будут. Все, кто хотел свалить с плюсов, давно уже с них свалили. В этом-то, наверное, и прелесть современных плюсов: на поляне стало очень просторно и чисто. Ещё бы Страуструпа куда-нибудь спровадить, чтобы своим евангелизмом не отсвечивал.