Почему невозможно написать компилятор, который управляет тем, что нужно управлять в коде на С++ (т.е. сделать его "совместимым с CLR" )?
Возможно, с некоторым компромиссом, например, запрет указателей void в некоторых ситуациях и т.д. Но все эти дополнительные ключевые слова и т.д. Какая проблема должна быть решена этими дополнениями?
У меня есть мои мысли о некоторых аспектах и что может быть трудно решить, но хорошее твердое объяснение будет высоко оценено!
Я бы не согласился с ответами до сих пор.
Основная проблема заключается в том, что компилятор С++ создает код, подходящий для очень немой среды. Даже современный процессор не знает о виртуальных функциях, черт, даже функции - это растяжка. ЦП действительно не волнует, что код обработки исключений для разматывания стека находится вне любой функции, например. Процессор обрабатывает последовательности команд, с переходами и возвратами. Функции, безусловно, не имеют имен в отношении процессора.
Следовательно, все, что необходимо для поддержки концепции функции, задается компилятором. Например. vtables - это просто массивы нужного размера, с правильными значениями с точки зрения процессоров. __func__ заканчивается как последовательность байтов в таблице строк, последняя из которых равна 00.
Теперь нет ничего, что говорит о том, что целевая среда должна быть немой. Вы могли бы точно нацелиться на JVM. Опять же, компилятор должен заполнить то, что не предлагается. Нет сырой памяти? Затем выделите большой массив байтов и используйте его вместо этого. Нет сырых указателей? Просто используйте целочисленные индексы в этом большом массиве байтов.
Основная проблема заключается в том, что программа С++ выглядит довольно неузнаваемой из среды хостинга. JVM не глупый, он знает о функциях, но он ожидает, что они будут членами класса. Он не ожидает, что у них будут < и > в их имени. Вы можете обойти это, но то, что вы в конечном итоге, в основном, называется mangling. И, в отличие от названий, которые сегодня используются, этот тип манипуляции не предназначен для C-линкеров, а для умных сред. Таким образом, его движок отражения может убедиться, что существует класс c__plus__plus с функцией-членом __namespace_std__for_each__arguments_int_pointer_int_pointer_function_address, и это еще хороший пример. Я не хочу знать, что произойдет, если у вас есть строка std::map для обратного итератора.
Другим способом на самом деле намного проще, в общем. Практически все абстракции других языков можно массировать в С++. Вывоз мусора? Это уже разрешено на С++ сегодня, поэтому вы можете поддержать это даже для void*.
Одна вещь, к которой я еще не обращался, - это производительность. Эмуляция необработанной памяти в массив большого байта? Это не будет быстрым, особенно если вы поместите в них двойники. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который объединяет худшие части С++ (много необычного поведения, зависящего от реализации) с наихудшими частями виртуальной машины (медленной).
Существующий правильный код, то есть код, написанный в соответствии со стандартом С++, не должен непредсказуемо изменять его поведение.
Ну С++/CLI в основном означает клей между управляемым и неуправляемым кодом. Таким образом, вы должны иметь возможность смешивать управляемые неуправляемые понятия. Вы должны иметь возможность выделять управляемые и неизмененные объекты в одном и том же коде, поэтому между отдельными ключевыми словами нет пути.
Почему вы не можете скомпилировать собственный код С++, нацеленный на CLR?
Да, вы правильно поняли, было бы слишком много компромиссов, что сделало бы это бесполезным. Я бы назвал только три примера...
1.) Шаблоны: С++ поддерживает их, CLR не работает (generics разные). Поэтому вы не можете использовать STL, boost и т.д. В своем коде.
2.) Множественное наследование: поддерживается в С++, а не в CLI. Вы даже не могли использовать стандартный класс iostream и производные (например, stringstream, fstream), которые наследуют оба из istream и ostream.
Практически ни один из кодов не будет компилироваться, вы даже не сможете реализовать стандартную библиотеку.
3.) Сбор мусора: Большинство приложений на С++ управляют своей памятью вручную (используя интеллектуальные указатели и т.д.), CLR имеет автоматическое управление памятью. Таким образом, стиль С++ "new" и "delete" будет несовместимым с "gcnew", что делает существующий код С++ бесполезным для этого нового компилятора.
Если вам нужно будет искоренить все важные функции, даже стандартная библиотека и не будет компилировать существующий код... то какая точка?
Прежде всего, различие между "простым С++" и "управляемым С++" было преднамеренным, поскольку одна из целей MС++ заключалась в том, чтобы обеспечить мост между существующим кодом С++ и CLR.
Далее, слишком много возможностей С++, которые не вписываются в модель CLR. Множественное наследование, шаблоны, арифметика указателей... Без рисования четкой строки программисты будут обречены сталкиваться с загадочными ошибками, как при компиляции, так и во время выполнения.
Qt framework делает почти это. То есть он имеет интеллектуальные указатели, которые автоматически устанавливают на нуль, когда объект, на который они указывают, уничтожается. И все же это родной С++, после разбора moc (мета-компилятор объекта).
Я думаю, это связано с тем, что добавление функций управляемого кода в С++ делало С++ медленнее, а компилятор более сложным. Настолько, что С++ потерял бы то, для чего он предназначался в первую очередь. Одна из приятных вещей С++ заключается в том, что это хороший язык для работы, он достаточно низкоуровневый и в то же время портативный. И, вероятно, это то, что собирается сделать на этом Стандартном комитете С++. В любом случае, я не думаю, что С++ может быть полностью "управляемым", потому что это означало бы, что программы, написанные на С++, требуют выполнения виртуальной машины. Если это так, почему бы просто не использовать С++/CLI?
Да, я полагаю, что С++ может стать управляемым. Но тогда .NET должен был быть переписан для С++, а не с предубеждением по отношению к BASIC. Имея много языков под одной крышей. Некоторые функции должны идти. Это был выбор между VB.NET или С++.NET и VB.NET были выбраны. Смешная вещь, которую я слышу, - это то, что С# более популярен, чем VB.NET(хотя я не использую ни одного!).
CLR.NET требует, чтобы никакая ссылка на управляемый объект никогда не существовала нигде, где время выполнения не знает об этом, за исключением того, что объект привязан; Хорошая производительность требует, чтобы объекты были закреплены как можно меньше. Поскольку .NET CLR не может понять все структуры данных, которые можно использовать в С++, необходимо, чтобы в таких структурах никогда не сохранялось никаких ссылок на управляемые объекты. Было бы возможно, чтобы "обычный" код на С++ взаимодействовал с кодом .NET без каких-либо изменений на языке С++, но единственный способ, которым код С++ мог бы поддерживать любую ссылку на любые объекты .NET, - это иметь некоторый код на стороне .NET присваивает каждому объекту дескриптор некоторого вида и сохраняет статическую таблицу объектов, связанных с дескрипторами. Код С++, который хотел бы манипулировать объектами, тогда должен был попросить оболочку .NET выполнить некоторую операцию над объектом, идентифицированным дескриптором. Добавление нового синтаксиса позволяет компилятору идентифицировать типы объектов, о которых должна знать инфраструктура .NET, и применять к ним необходимые ограничения.
Первое, что нужно рассмотреть
все, что делает c++ "fast", исчезнет.
полная система сбора мусора в С++ почти невозможна.
потому что c++ вы можете иметь указатель почти в любом месте кода.
информация о времени выполнения становится дорогостоящей, если она не встроена непосредственно в
langauge система сама.
вы можете воспользоваться настоящей собственной производительностью.
шаблон исчезнет. истинные указатели исчезнут.
прямой доступ к памяти пропал.
список вещей, которые должны быть соблюдены
1. no direct pointers(pointers will get replace with complex refernces)
2. templates (generics pay for preformance)
3. simple c-style arrays (will get wrapped with array structures)
4. programmer no longer has control of whether data is on the stack or
the heap.
5. garbage collection will be enforced(this will cause the most changes to the syntax)
6. runtime type data will get added extensively to the code.
(larger code size)
7. inlining will become more difficult for the compiler
(no more inline key word)
8. no more inline assembly.
9. the new langauge by now will become incompatible c code.(unless you go through hoops)
Я согласен с 5hammer! Если я оставил Java и другие управляемые языки не зря: для того, чтобы ПОЛНЫЙ контроль над компьютером, сам управлять памятью памяти, контролировать, как компьютер будет запускать мой код, интегрироваться с библиотеками C (такими как Lua). Если бы я потерял эту гибкость, я бы просто оставил С++ и вернусь на C, и если C тоже будет управляться, я бы пошел на ассемблер.
Управляемые языки являются самыми худшими для всех игровых платформ/сложных программ, поскольку они ограничивают вас в некоторых кинедровых песочницах без прямого доступа к аппаратным средствам и намного медленнее, чем скомпилированные языки.
Основная цель С++ всегда была Performence. Это один из лучших языков для больших игр. И без этих языковых характеристик много игр не было бы!