Охрана не имеет полномочий запрашивать какие-либо документы в принципе, даже полиция может попросить у вас документы только при наличии основания. Таким образом, те кто требует у вас QR и ограничивает ваше передвижение(на данный момент нет ни одного закона, который обязывает вас иметь код и тем более демонстрировать 3м лицам),нарушает кучу законов, начиная от конституции и заканчивая УК. Но, к сожалению, большинство людей опасается возразить даже охраннику. Как говорится, за Державу обидно.
В статье Великой корпорации, видимо, нельзя оставить никакого комментария/мнения, кроме хвалебного. Более низкосортною маркетинговую статью еще поискать нужно, замените Edge на любое другое название и смысл не поменяется. Что-то сродни: «С нашей технологией ваша производительность резко подскочит», «Наш продукт позволит вам сделать в сто раз больше», «Будущее уже сегодня» и т.д. и т.п. Я уж, решил, наивный, что при Сатье Наделла MS избрала политику открытости и всякое такое, но видимо не совсем.
Ну, ни разу не видел, что ООП применяется так, как оно задумывалось + категоричное высказывание в статье, насчет парадигмы написания чистого кода. Так же, как методология более направленная на удобство восприятия «человеками» (дописывание большого количества кода, не нужного самой программе для работы) должна была внести порядок в проекты, на деле же, может больше запутать в хаосе абстракций и искажать восприятие логики работы программы.
bla-bla-bla-bla. Про парадигмы повеселило более всего. Особенно ООП, как методология написания чистого кода, с наворачиванием кучи, зачастую лишних сущностей… И звучит так, как будто чистота кода зависит напрямую от парадигмы, а не от сплава опыта и навыка.
Если такое пишут в прод (как в примерах этого теста), это очень печально. Поработать компилятором/интерпретатором для таких перлов тоже желания не возникает, как и бороться с вымышленным руководством(надеюсь), которое как-бы хочет денег от «проекта», но не хочет работать. Поэтому, цель этого квеста не ясна, Wow эфекта не вызывает, только демотивирует, если представить себя парнем из этого квеста.
но называть высокоуровневым язык, в котором, например, вместо массивов и строк — адреса в виртуальной памяти (!), можно только забыв про 90% существующих языков программирования.
На этом основании вы говорите о том, что С не является высокоуровневым.
Потом мы цепляемся за реализацию массивов.
Ну да, ну да, только вот у сишных массивов нет контроля границ, длину надо таскать явно вместе с указателем — в общем, в Си нет массивов.
По прежнему не понятно, почему заявляется о том, что в С отсутствует этот сложный тип данных.
Комментарий про «опасную» архитектуру так же относится именно к этой фразе.
int[] arr = new int[10];
int* arr = (int*) malloc(10 * sizeof(int));
Видимо вас очень беспокоят динамические массивы в С.
В первом случае тип переменной — массив целых чисел. Во втором — указатель
Первый случай.
Ваш пример — это статический массив:
int[] arr = new int[10];
Оператор new указывает на то, что каждый элемент массива получает значение по умолчанию. Каким оно будет определяется на основании типа данных (0 для int). Динамические массивы в Java реализованы через классы Vector и ArrayList и для управления элементами эти классы используют методы интерфейсов Collection и List.
ArrayList <Integer> i = new ArrayList<Integer>();
i.add(3);
i.add(new Integer(34));
System.out.println("i size: "+i.size());
System.out.println("i elements:"
+i.get(0).intValue()+", "+i.get(1));
Статический массив С:
int arr[3] = {0, 1, 2};
Статический массив Java:
int arr[] = {10,20,30};
Как видите, разница даже в синтаксисе невелика
Ну, напомню, что в Java все сложные типы данных ссылочные, в Java массивы являются объектами. Это значит, что имя, которое даётся каждому массиву, лишь указывает на адрес какого-то фрагмента данных в памяти. Кроме адреса в этой переменной ничего не хранится. Индекс массива, фактически, указывает на то, насколько надо отступить от начального элемента массива в памяти, чтоб добраться до нужного элемента. Просто в Java нет явных указателей, и в нормальных условиях, ручного управления памятью.
Второй случай.
int* arr = (int*) malloc(10 * sizeof(int));
Выделяется 10 блоков по sizeof(int) байт каждый, к элементам массива можно обращаться как через индекс так и через разыменование arr[i] и *(arr+i).
Здесь речь идет только о динамическом массиве, который вы пытаетесь сравнивать со статическим Java. В C динамические массивы реализованы через явные указатели, за которыми действительно сложно следить.
Первый я могу передать в другой метод или вернуть из другого метода без хаков и костылей, второй — нет. «Массив» в Си — это паттерн, а не элемент языка.
Жалуетесь на архитектуру языка.
Передергиваете. Меня не особо волнует, что происходит, когда я пишу
case class Person(firstName: String, lastName: String)
Главное — как с этим работать на выбранном мной уровне. Это называется абстракцией.
Не передергиваю. Вспомните, изначально речь шла о «низкоуровневости».
И это ваша фраза раскрывает просто все.
Только один ответ может быть на такое — очень жаль.
Как можно называть язык низкоуровневым, когда за вас все делает компилятор, выдавая оптимизированный по своему алгоритму машинный код, производительность которого может довольно сильно варьироваться в зависимости от компилятора и его настроек. Так же напоминаю, что для действительно низкоуровневых операций в С делают ассемблерные вставки.
PS
Просьба не делать выводов типа таких:
«но называть высокоуровневым язык, в котором, например, вместо массивов и строк — адреса в виртуальной памяти (!), можно только забыв про 90% существующих языков программирования.»
не имея достаточных оснований. Еще больше поражает, что такие заявления еще и «плюсуют»
1. Вырывать строку из контекста, это не есть признак хорошей аргументации.
2.
Ну да, ну да, только вот у сишных массивов нет контроля границ, длину надо таскать явно вместе с указателем — в общем, в Си нет массивов.
— из этой фразы вообще непонятно как сделан вывод о
в Си нет массивов
Расскажите пожалуйста, чем же являются эти пресловутые массивы в других ЯП?
Если у языка «опасная» архитектура и повышенное требование к внимательности и рукам разработчика, это автоматически делает его более низкоуровневым и трушным?
3.
То, что некий адрес и целое число являются массивом — плод воображения разработчика, не более
Все эти ваши дататайпы, структуры и объекты + синтаксический сахар — плод воображения разработчика, так сказать — human interface. Есть только 1 и 0, да и то это человеческая абстракция. На самом деле есть сигналы и физическое состояние транзисторов — вот это прямо таки самый «низкий» уровень (но не конечный), <irony> когда научитесь менять вручную и контролировать состояние каждого транзистора, тогда будете гуру «низкоуровневости» </irony>
Согласно официальной, академической, по которой учат студентов.
Разница в этой классификации в том, как именно человек пишет код (ну во всяком случае, как я это вижу).
Вы при работе с массивами в C напрямую взаимодействуете с адресами в памяти, с регистрами? В машинном представлении?
Подозреваю, что вы обращаетесь к элементам массива по индексу, да еще и через приятного вида синтаксис, и работа с ними не особо отличается от той же Java, кроме того, что С нужно следить за выделенной памятью.
В ассемблере (символьное обозначение машинных команд) же само понятие массива весьма эфемерно и его еще нужно, так сказать, смоделировать. Т.е. вам нужно через низкоуровневые операции с памятью, реализовать то, что есть в С «из коробки»
Ну вообще, вы можете попросить эту самую ориентировку показать. Как минимум, сотрудник должен объяснить, почему он остановил вас.
Понятное дело, что при общении с полицией есть тонкая грань.
Охрана не имеет полномочий запрашивать какие-либо документы в принципе, даже полиция может попросить у вас документы только при наличии основания. Таким образом, те кто требует у вас QR и ограничивает ваше передвижение(на данный момент нет ни одного закона, который обязывает вас иметь код и тем более демонстрировать 3м лицам),нарушает кучу законов, начиная от конституции и заканчивая УК. Но, к сожалению, большинство людей опасается возразить даже охраннику. Как говорится, за Державу обидно.
На этом основании вы говорите о том, что С не является высокоуровневым.
Потом мы цепляемся за реализацию массивов.
По прежнему не понятно, почему заявляется о том, что в С отсутствует этот сложный тип данных.
Комментарий про «опасную» архитектуру так же относится именно к этой фразе.
Видимо вас очень беспокоят динамические массивы в С.
Первый случай.
Ваш пример — это статический массив:
Оператор new указывает на то, что каждый элемент массива получает значение по умолчанию. Каким оно будет определяется на основании типа данных (0 для int). Динамические массивы в Java реализованы через классы Vector и ArrayList и для управления элементами эти классы используют методы интерфейсов Collection и List.
Статический массив С:
Статический массив Java:
Как видите, разница даже в синтаксисе невелика
Ну, напомню, что в Java все сложные типы данных ссылочные, в Java массивы являются объектами. Это значит, что имя, которое даётся каждому массиву, лишь указывает на адрес какого-то фрагмента данных в памяти. Кроме адреса в этой переменной ничего не хранится. Индекс массива, фактически, указывает на то, насколько надо отступить от начального элемента массива в памяти, чтоб добраться до нужного элемента. Просто в Java нет явных указателей, и в нормальных условиях, ручного управления памятью.
Второй случай.
Выделяется 10 блоков по sizeof(int) байт каждый, к элементам массива можно обращаться как через индекс так и через разыменование arr[i] и *(arr+i).
Здесь речь идет только о динамическом массиве, который вы пытаетесь сравнивать со статическим Java. В C динамические массивы реализованы через явные указатели, за которыми действительно сложно следить.
Жалуетесь на архитектуру языка.
Не передергиваю. Вспомните, изначально речь шла о «низкоуровневости».
И это ваша фраза раскрывает просто все.
Только один ответ может быть на такое — очень жаль.
Как можно называть язык низкоуровневым, когда за вас все делает компилятор, выдавая оптимизированный по своему алгоритму машинный код, производительность которого может довольно сильно варьироваться в зависимости от компилятора и его настроек. Так же напоминаю, что для действительно низкоуровневых операций в С делают ассемблерные вставки.
PS
Просьба не делать выводов типа таких:
не имея достаточных оснований. Еще больше поражает, что такие заявления еще и «плюсуют»
2. — из этой фразы вообще непонятно как сделан вывод о Расскажите пожалуйста, чем же являются эти пресловутые массивы в других ЯП?
Если у языка «опасная» архитектура и повышенное требование к внимательности и рукам разработчика, это автоматически делает его более низкоуровневым и трушным?
3. Все эти ваши дататайпы, структуры и объекты + синтаксический сахар — плод воображения разработчика, так сказать — human interface. Есть только 1 и 0, да и то это человеческая абстракция. На самом деле есть сигналы и физическое состояние транзисторов — вот это прямо таки самый «низкий» уровень (но не конечный), <irony> когда научитесь менять вручную и контролировать состояние каждого транзистора, тогда будете гуру «низкоуровневости» </irony>
Разница в этой классификации в том, как именно человек пишет код (ну во всяком случае, как я это вижу).
Вы при работе с массивами в C напрямую взаимодействуете с адресами в памяти, с регистрами? В машинном представлении?
Подозреваю, что вы обращаетесь к элементам массива по индексу, да еще и через приятного вида синтаксис, и работа с ними не особо отличается от той же Java, кроме того, что С нужно следить за выделенной памятью.
В ассемблере (символьное обозначение машинных команд) же само понятие массива весьма эфемерно и его еще нужно, так сказать, смоделировать. Т.е. вам нужно через низкоуровневые операции с памятью, реализовать то, что есть в С «из коробки»
Cогласно классификации: С — высокоуровневый, процедурный. Таки не Ассемблер же.