Почему C++ нужны модификации языка, которые будут “управляться”?

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

9
задан Deduplicator 9 March 2015 в 14:50
поделиться

7 ответов

До сих пор я не соглашался с ответами.

Основная проблема, которую нужно понять, состоит в том, что компилятор C ++ создает код, подходящий для очень тупой среды , Даже современный процессор не знает о виртуальных функциях, черт возьми, даже функции растягиваются. Процессору действительно все равно, например, что код обработки исключений для разматывания стека находится вне какой-либо функции. Работа процессора в последовательностях команд, с переходами и возвратами. Функции, конечно же, не имеют имен в отношении процессора.

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

Теперь нет ничего, что говорит, что целевая среда должна быть тупой . Вы могли определенно предназначаться для JVM. Опять же, компилятор должен заполнить то, что не предлагается изначально. Нет сырой памяти? Затем выделите большой байтовый массив и используйте его вместо этого. Нет сырых указателей? Просто используйте целочисленные индексы в этом большом байтовом массиве.

Основная проблема заключается в том, что программа C ++ выглядит совершенно неузнаваемой из среды хостинга. JVM не глупая, она знает о функциях, но ожидает, что они будут членами класса. Он не ожидает, что в их имени будут < и > . Вы можете обойти это, но то, что вы в конечном итоге, это в основном искажение имени. И в отличие от искажения имен сегодня, такое искажение имен предназначено не для линкеров C, а для интеллектуальных сред. Таким образом, его механизм отражения может быть убежден, что существует класс c__plus__plus с функцией-членом __ namespace_std__for_each__arguments_int_pointer_int_pointer_function_address , и это все еще хороший пример. Я не Я не хочу знать, что произойдет, если у вас есть std :: map строк для обращения итераторов.

На самом деле, наоборот, намного проще. Практически все абстракции других языков могут быть удалены в C ++. Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

отобразите строк для обращения к итераторам.

В действительности, наоборот, намного проще. Практически все абстракции других языков могут быть удалены в C ++. Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

отобразите строк для обращения к итераторам.

В действительности, наоборот, намного проще. Практически все абстракции других языков могут быть удалены в C ++. Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

В действительности, наоборот, намного проще. Практически все абстракции других языков могут быть удалены в C ++. Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

В действительности, наоборот, намного проще. Практически все абстракции других языков могут быть удалены в C ++. Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

Вывоз мусора? Это уже разрешено в C ++ сегодня, так что вы можете поддерживать это даже для void * .

Одна вещь, о которой я еще не говорил, это производительность. Эмуляция необработанной памяти в большом байтовом массиве? Это не будет быстрым, особенно если вы положите в них двойные числа. Вы можете сыграть много трюков, чтобы сделать это быстрее, но по какой цене? Вы, вероятно, не собираетесь получать коммерчески жизнеспособный продукт. Фактически, вы можете использовать язык, который сочетает в себе худшие части C ++ (много необычного поведения, зависящего от реализации) с худшими частями виртуальной машины (медленный).

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

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

12
ответ дан 4 December 2019 в 08:52
поделиться

Existing correct code, i.e. code written according to the C++ standard, must not change its behaviour inadvertently.

4
ответ дан 4 December 2019 в 08:52
поделиться

I think this is because adding managed code features into C++ would made C++ slower and the compiler more complex. So much so that C++ would lose what it's designed for in the first place. One of the nice things of C++ is that it's a nice language to work with, it's low-level enough and yet somewhat portable. And probably that's what the C++ Standard Committee plans to made it stay that way. Anyway I do not think C++ can ever be fully "managed", because that would mean programs written in C++ needs a VM to execute. If that's the case, why not just use C++/CLI?

1
ответ дан 4 December 2019 в 08:52
поделиться

Qt framework делает почти это. Т.е. у него есть умные указатели, которые автоматически устанавливаются в нуль, когда объект, на который они указывают, уничтожен. И все же это родной C ++, после анализа moc (мета-объектный компилятор).

1
ответ дан 4 December 2019 в 08:52
поделиться

Что ж, C ++ / CLI в основном предназначен для соединения управляемого и неуправляемого кода. Таким образом, вы должны иметь возможность смешивать управляемые и неуправляемые концепции. Вы должны иметь возможность размещать управляемые и неуправляемые объекты в одном и том же коде, чтобы обходить отдельные ключевые слова невозможно.

3
ответ дан 4 December 2019 в 08:52
поделиться

Почему вы не можете скомпилировать нативный Код C ++, нацеленный на CLR?

Да, вы правильно догадались, слишком много компромиссов сделало бы его бесполезным. Я хотел бы назвать только три примера ...

1.) Шаблоны: C ++ поддерживает их, CLR - нет (универсальные значения различны). Таким образом, вы не можете использовать STL, boost и т. Д. В своем коде.

2.) Множественное наследование: поддерживается в C ++, а не в CLI. Вы даже не могли использовать стандартный класс iostream и его производные (такие как stringstream, fstream), которые наследуют как от istream, так и от ostream.

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

3.) Сборка мусора: Большинство приложений C ++ управляют своей памятью вручную (с помощью интеллектуальных указателей и т. Д.), CLR имеет автоматическое управление памятью. Таким образом, стиль «new» и «delete» в C ++ будет несовместим с «gcnew», что сделает существующий код C ++ бесполезным для этого нового компилятора.

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

3
ответ дан 4 December 2019 в 08:52
поделиться

Прежде всего, различие между «простым C ++» и «управляемым C ++» было преднамеренным, потому что одной из целей MC ++ было обеспечение моста между существующим кодом C ++ и CLR.

Далее, слишком много функций C ++, которые не вписываются в модель CLR. Множественное наследование, шаблоны, арифметика указателей ... Без четкой линии программисты были бы обречены сталкиваться с загадочными ошибками как во время компиляции, так и во время выполнения.

2
ответ дан 4 December 2019 в 08:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: