Ответы пользователя по тегу C#
  • Объявление пространств имен в c#?

    Ведь c# - это компилируемый язык а не интерпретируемый, а значит код не читается строчка за строчкой а строится синтаксическое дерево. И поэтому мне интересно не все ли равно где объявлять пространства имен?

    Думаю так сделано чтобы открыв файл, можно было сразу понять, какие пространства имён используются. Потому что выискивать все using'и по всему файлу - такое себе развлечение, даже если бы язык это позволял, за такое нужно было бы бить по рукам.
    Ответ написан
    Комментировать
  • Нуборазмышления по поводу интерпретируемых Java\python\c# и компилируемых с++\с итп?

    Интерпретируемый язык - проходит 2 стадии вместо одной ( интерпретация в байт код и компиляция), компилируемый язык - 1 стадия( компиляция).


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

    На деле реализации ЯП можно поделить примерно следующим образом:

    • Трансляторы
      • Трансляторы в низкоуровневые языки (компиляторы)
        • Ahead-of-Time компиляторы (компилируют один раз, заранее)
        • Just-in-Time компиляторы (компилируют прямо во время выполнения программы, «на лету»)
      • Трансляторы в высокоуровневые языки
    • Интерпретаторы


    Так, например, GCC — статический компилятор, OpenJDK — транслятор в байт-код + JIT-компилятор байт-кода, CPython — транслятор в байт-код + интерпретатор байт-кода.

    Для языков со статической типизацией и ручным управлением памятью (C, C++, Rust etc) наиболее эффективными оказываются статические (AOT) компиляторы. Для динамических же языков со сборщиком мусора зачастую эффективнее оказывается компиляция «на лету» (just-in-time), поскольку это позволяет компилятору использовать статистику запусков для сложных оптимизаций. «Настоящие» интерпретаторы (т. е. не являющиеся на самом деле JIT-компиляторами) обычно оказываются медленнее компиляторов.

    То значит откомпилированная игра на Java, может не уступать по производительности игре написанной на с++?


    Может, если реализация на C++ низкого качества. В общем случае код на Java будет медленнее аналогичного на C++, из-за сборщика мусора и type erasure.
    Ответ написан
    Комментировать