Типы данных в C были созданы неопределёнными, без сомнения, с той же целью - чтобы увеличить количество ошибок, сделать поведение программы более неопределённым, затруднить программирование. long - можете сказать какую длину имеет этот тип? Сколько в нём байт? Насколько он длинный? Я не могу. Когда я это вижу, у меня всегда вопросы. Понятие "длинный" - оно, знаете ли, очень субъективное, очень относительное, очень сильно зависит от контекста. В старых учебниках по C можете увидеть явные указания на то, что длины этих типов зависят от реализации. Т.е., пиша программу, Вы не знаете какую длину имеет тип данных. Вы можете предполагать, что это 32 бита и, соответственно, 4 миллиарда значений, а на деле может оказаться, что это всего лишь 16 бит, и 65 тысяч возможных значений. И Вашему алгоритму может просто не хватить диапазона значений. Ваша программа из-за этого будет работать с ошибкой. Определённость является важнейшим качеством программы. Ещё в первых теориях алгоритмов звучало то, что программа должна быть однозначной, не допускающей двусмысленностей. Т.е. неопределённость типов - это грубое нарушение этого правила построения алгоритмов. Что, кстати, можно сказать и о языках программирования с нестрогой типизацией. Нестрогая типизация переменных - это очень дурно. Такие языки всегда будут подвержены бОльшему количеству ошибок. Основные типы должны быть определены с полнейшей однозначностью. В C есть специальный заголовочный файл "stdint.h", который, судя по всему, путём макросных ухищрений, даёт программисту полностью определённые типы: int8_t uint8_t int16_t uint16_t int32_t uint32_t int64_t uint64_t Формат имён содержит лишний постфикс "_t". Эти имена хороши тем, что Вы сразу видите полностью определённую длину типа - длину в битах. Т.е. Вы с абсолютной точностью знаете какую именно длину имеет Ваш тип. Это оберегает от ошибок. Также Вы видите знаковость и беззнаковость - "u" - это "unsigned". Это тоже важно. Программа, написанная с использованием таких типов, будет работать абсолютно одинаково на любой аппаратной платформе. В C5 эти типы выглядят так: byte - uint8 int8 uint8 int16 uint16 int32 uint32 int64 uint64 В C# эти типы есть с самого начала: Byte - Unsigned Byte SByte - Signed Byte Int16 UInt16 Int32 UInt32 Int64 UInt64 Непонятно зачем понадобилось сделать исключение из общей схемы именования для UInt8. Byte - чудесное слово. Оно могло быть алиасом этого типа. Это абсолютно правильный подход. Уже бывает, что не хватает типов Int128, UInt128. Реализация этих типов может быть с дроблением на части - по размеру регистров целевой машины. Например, Guid имеет этот размер - 16 байт. Реальность такова, что процессорная техника развивается, и размеры регистров растут. В современности имем дело с 32-битными и 64-битными процессорами. Регистры этих процессоров имеют соответствующий размер. В частности, память адресуется этими регистрами. Если программируете с использованием указателей, Вам нужен специальный тип, имеющий размер регистра. Это значит, что в языке должен присутствовать специальный целочисленный тип, размер которого равен размеру регистра целевого процессора. В C5 он обозначается "int" и "uint". На 32-битных процессорах размер этого целого равен 32-м битам, а на 64-битных процессорах - 64-м битам. В будущем могут появится процессоры с регистрами 128 бит. Цифра для адресования памяти огромная, но когда-то глава одной известной корпорации был уверен, что 65 килобайт оперативной памяти компьютерам хватит на все времена. Я бы не стал ограничивать реализации языков программирования длиной регистра 64 бита. Этот специальный тип с переменной длиной, к сожалению, действительно, нужен. Например, для адресной арифметики. Например, для указания длины памяти. Это "native int" - "родной" тип "int" - целочисленное, имеющее размер "родного" регистра целевого процессора. Имена типов "float" и "double" также являются неопределёнными. "float" - плавающий? Плавающий тип? Тип, который плавает? Принимает неопределённые значения? У меня такие ассоциации с этим именем. В C5 имена этих типов заменены на "real32" и "real64" соответственно. Для той же определённости. Чтобы программист в самом имени типа видел длину и понимал что это за тип. Причём, стандарт языка должен однозначно определять не только длину этих типов, но и внутреннюю структуру. Потому что эти типы состоят из трёх битовых полей - знака, степени и мантиссы. Есть стандарт IEEE 754. Типы "real32" и "real64" строго соответствуют этому стандарту. Например, real32 - это [1 бит знака | 8 бит экспоненты | 23 бита мантиссы] и соответствующий смысл битов. Стандарт языка C5 должен строго и однозначно определять, что эти типы соответствуют именно этому стандарту, и никакому другому. Тогда на это можно полагаться и строить интерфейсы. Стандарт CLI неслучайно определяет типы с полной строгостью. Неоднозначность реализации - это всегда проблема для построения программных систем. .NET совершенно правильно поступила, определив эти типы с полной строгостью. Если есть какие-то процессоры, которые используют другие форматы - то это их трудности. Мейнстрим - это стандарт IEEE 754. Именно этот формат используют процессоры с архитектурой x86 и amd64. Если что-то отличающееся - то производителям этого специального аппаратного обеспечения нужно делать программные или аппаратные конверторы. Эти отличия не должны создавать проблемы для общепринятых стандартов данных. Т.е. это их трудности, а не языка программирования высокого уровня. Принцип "зависит от реализации" неприменим.
@@Даниил-з5л смотря чему \ в каком направлении хочешь учиться ? + все сугубо индивидуально! Сайтики пилить можно научиться за пол-года - год. Программировать свои микроконтроллеры на Си - и 5-ти лет может быть мало.
@@ipaldesse суть в том, что в ближайшее время я хочу начать изучать язык. Я хочу быть мобильным разработчиком. Мне нужны базовые знания в этой области. Какой язык посоветуешь? Также понадобятся знания в веб разработке. Вот что начать изучать с самого нуля, чтобы понимать все это дело?
Я: я сделаю великую видеоигру! Работодатель: круто. иди рисуй лутбокс и посчитай вероятности так чтобы фиол не выпадал, пиши документы для 120 человек, найди рефы по штук 200 достаточно, и сделай прототипы на блоках с механиками на С#. И вот аванс зп $250, вторая половина через две недели.
Стоит ли учить С# после С++ только чтобы писать игру под UNITY ? А может просто надо делать больше туториалов на С++ для CRYENGINE ? Тогда проблема с СИ#шарпом и UNITY отпадет сама собой 😁😁😁
Я как человек который учил и то и то скажу, что не стоит учить Шарп если тебе нужны игры качай Unreal Engine я объясню почему из-за того что нет контроля памяти нужна крутая архитектура чтобы не приходил сборщик и у тебя не было лага в игре. А выучить то как нужно делать архитектуру в юнити уйдет больше времени чем на изучение Шарпа. Так как если одновременно много объектов перестают быть нужны то их удаление вызывает лаги ну либо нужен девайс получше отсюда требования к игре выше.
C# во многих отношениях лучше с++: надёжнее, нормальное ООП, чище синтаксис Инфраструктура вокруг c# лучше: всякие асп нет, впф, сто тыщ шаблонов приложений и т.п.
@@GbyG_Ruslan согласен, слово "нормальное" здесь не подходит. Я имел в виду, что в c++ разрешено, например, множественное наследование. Хорошо это, или плохо - некорректный вопрос. Однако множественное наследование создаёт много сложностей и не очевидных проблем, что в свою очередь затрудняет и замедляет проектирование и разработку, хотя, возможно, и даёт какие-то преимущества.
Реализация switch-case в C/C++/C# неудачна. Это ветвление имеет путаный ход исполнения. Думаю, что это сделано нарочно - чтобы затруднить программирование и увеличить количество ошибок. Последовательного исполнения ветвей в C5 не должно быть в принципе. На практике, это исключительно редкий случай, когда требуется исполнить одну ветвь, а вслед за ней - другую. Наиболее часто встречается необходимость исполнения только одной ветви. На этой схеме (в моноширинном шрифте) представлен идеальный и наиболее удобный оператор ветвления: 1) Исполняется ветвь 0; 2) Доходит до точки ветвления; 3) Выбирается только одна из множества ветвей {1, 2, 3, 4}; 4) Исполняется эта ветвь; 5) Вслед за этим происходит выход за пределы оператора ветвления в общую ветвь 5. | | 0 | _________|_________ | | | | | | | | 1 2 3 4 | | | | | | | | ------------------- | | 5 | | Только одна из ветвей {1, 2, 3, 4} должна исполнятся, а остальные - нет. Т.е. в конце каждой ветви должен происходить автоматический безусловный императивный выход за пределы оператора ветвления. В C/C++/C# этого нет - чтобы выход произошёл, Вам нужно написать ключевое слово "break" явно, иначе исполнение уйдёт в следующую ветвь. Эта логика очень мешает програмированию. Программисты очень часто забывают написать этот "break", и это приводит к ошибкам исполнения. Отсутствие "break" в конце ветви компилятор не замечает - нет ни ошибки ни предупреждения. На практике, такая нужда, что после исполнения одной ветви требуется исполнить другую, - встречается очень редко. Сама эта концепция, что после исполнения одной ветви нужно исполнить другую, - разрушает стройность оператора ветвления. Поэтому, из C5 последовательное исполнение ветвей следует исключить. В C5 исполняется только одна ветвь, и в её конце происходит автоматический выход за пределы оператора ветвления.
Иногда встречается, что множество значений операнда switch соответствуют одной и той же ветке. Но это решается не путём последовательного исполнения ветвей, а путём перечисления всех вариантов в операторе case через запятую. Ветвь получается одна, просто ей соответствует множество вариантов операнда: switch (A) { // Одна ветвь // Переход в эту ветвь - при двух указанных значениях операнда case 1, 2: { } } ----------------------------------------------------------------------------------- В языке C2 автоматический выход за пределы оператора ветвления реализован. Это правильно. Неправильно то, что сохраняется возможность последовательного исполнения ветвей. Там это реализовано с помощью ключевого слова fallthrough, которое ужасно звучит и индуцирует в сознании программиста мысли о падении. Падении программы? ----------------------------------------------------------------------------------- Пусть Вас не пугает это "ограничение" функциональности. Цель этого сужения функциональности - обеспечение бОльшей ясности алгоритмов, бОльшей их простоты. Множество таких ограничений ввёл C# - и, как видите, язык получился очень хороший. Отсутствие макросов и заголовочных файлов - это чистая радость. Устранение возможности последовательного исполнения ветвей также приведёт к бОльшей простоте программирования. Оператор ветвления будет выглядеть так же просто как на изображённой схеме: простейшее ветвление из одной точки в множество ветвей, лишь одна из которых исполняется. ----------------------------------------------------------------------------------- Слова "switch", "case" и "default" - это паразитные слова, которые мешают чтению программы. "switch", и вовсе похоже на [witch] - "ведьма". Вероятно, имеются в виду плохие ключевые слова, внедрённые некоей ведьмой с целью усложнить программирование. "switch" - это переключатель. Т.е. это даже не ветвление, а некая непонятная логика. Что, в общем-то, мы и видим. "default"? "fault" - это неисправность.
C5 заменяет слово "switch" на "branch" с буквальным переводом "ветвь". C5 заменяет слово "case" на "equal" с буквальным переводом "равно". C5 заменяет слово "default" на "other" с буквальным переводом "другое". Т.е. ветвь от операнда A. Если A равно такому-то значению - переход в эту ветвь. Если все другие значения - переход в эту ветвь. Выглядит это так: ----------------------------------------------------------------------------------- // Переменная, значение которой определяет ветвь, которая будет исполнена uint8 A; ... // Оператор ветвления branch (A) { // Операторы в этой ветви отсутствуют - не исполняется ничего equal 1: // Исполняется одиночный оператор equal 2, 4: operator; // Исполняется составной оператор equal 5: { operator 1; operator 2; } //----------------------------------------------------------------------------------------------- // Синтаксическая ошибка - операнды "equal" не могут повторяться. // // Повторение операндов - это неоднозначность. // Куда должен произойти переход? В эту ветвь или предыдущую? equal 5: //----------------------------------------------------------------------------------------------- ///////////////////////////////////////////////////////////////////////////////////////////////// // Два нижеследующих варианта из синтаксиса следует исключить по той причине, // что они формируют код, структура которого читается с трудом. // // Да, это могут быть все операторы до следующего ключевого слова "equal", "other" // или конца оператора ветвления, но читать это программисту будет трудно. // Поэтому следует оставить только отсутствие оператора, одиночный оператор и составной оператор. equal 7: operator 6; operator 7; equal 8, 9, 10, 11: operator 10; operator 11; ///////////////////////////////////////////////////////////////////////////////////////////////// // Переход в эту ветвь - при всех других значениях операнда - // при значениях, которые не перечислены в операндах equal. // // Эта ветвь может отсутствовать. // // Эта ветвь должна стоять в самом конце. // Дело не в алгоритме: алгоритмически она может стоять в любом месте. // Но программистам будет легче воспринимать и искать её именно в конце. // Поэтому в C5 должно быть синтаксическое правило - эта ветвь может стоять только в конце, // после всех операторов "equal". other: { } } -----------------------------------------------------------------------------------
Всем привет! Ищу в компании разработчика Си (встроенное ПО) ОС Линукс для телекоммуникационного оборудования. г. Москва, если интересно пишите, подробнее расскажу. Спасибо за видео.
Источник сведений насчёт скорости разработки на C++ и C#. Откуда эта информация? Приведите детали. По моим ощущениям, разработка на C# намного быстрее, намного проще. Единственный недостаток C# - это производительность. Библиотека классов .NET восхитительна. Это лучший фреймворк из созданных.
@@ПростоЁж-щ3ъ подскажите пожалуйста, "...какой-нибудь нормальный..." это какой язык? я допустим для поступления python изучала и потом решила продолжить развиваться в нем. Но все как в один голос твердят, что python полная ху&ня, и лучше c++ изучать...или просто говорят перейти на какой-нибудь нормальный язык, но не говорят какой)
@@Анастасия-м5ф8м, все языки по-своему нормальные, просто, с каким-то будет легко на рынок выйти, а с каким-то по помойкам шастать первые несколько лет придется. Я бы отнес к нормальным, как раз python, Go, C#, js (любой фреймворк). Достаточно легкие, достаточно легко найти первую работу на них и высокие зп, на них куча вакансий. Вообще с c++ и вообще любым языком можно достичь всего, чего пожелаешь, при должном старании, лучше попробовать разное и выбрать что-то, что по душе, с чем тебе приятнее. (предупрежу, c++ по этим параметрам мало кому заходит)
> Выучить нормальный язык, который нужен рынку > C++ постоянно сидит в топ-5 лучший ЯП'ов, мой друг. Поверь, с плюсами тоже просто найти работу. На них пишутся всё ещё новые технологии + игры + на плюсах написано очень очень очень много строк кода => их нужно поддерживать
Обращаться с памятью в C#, действительно, очень удобно. Совершенно не нужно заботиться о её освобождении. Сборщик мусора оставляет желать лучшего. Многие объекты он удалить не в состоянии. Это приводит к разрастанию кучи старого мусора, из-за которого процессы приходится периодически перезапускать.
очередная реклама курсов, которые обещают через 3 месяца золотые горы, но так ли это? конечно же нет.
Страшно, очень страшно!
Мы не знаем что это такое, если бы мы знали что это такое, мы не знаем что это такое
🤣🤣✊
Типы данных в C были созданы неопределёнными, без сомнения, с той же целью - чтобы увеличить количество ошибок, сделать поведение программы более неопределённым, затруднить программирование.
long - можете сказать какую длину имеет этот тип? Сколько в нём байт? Насколько он длинный? Я не могу. Когда я это вижу, у меня всегда вопросы. Понятие "длинный" - оно, знаете ли, очень субъективное, очень относительное, очень сильно зависит от контекста.
В старых учебниках по C можете увидеть явные указания на то, что длины этих типов зависят от реализации. Т.е., пиша программу, Вы не знаете какую длину имеет тип данных. Вы можете предполагать, что это 32 бита и, соответственно, 4 миллиарда значений, а на деле может оказаться, что это всего лишь 16 бит, и 65 тысяч возможных значений. И Вашему алгоритму может просто не хватить диапазона значений. Ваша программа из-за этого будет работать с ошибкой.
Определённость является важнейшим качеством программы. Ещё в первых теориях алгоритмов звучало то, что программа должна быть однозначной, не допускающей двусмысленностей. Т.е. неопределённость типов - это грубое нарушение этого правила построения алгоритмов. Что, кстати, можно сказать и о языках программирования с нестрогой типизацией. Нестрогая типизация переменных - это очень дурно. Такие языки всегда будут подвержены бОльшему количеству ошибок.
Основные типы должны быть определены с полнейшей однозначностью. В C есть специальный заголовочный файл "stdint.h", который, судя по всему, путём макросных ухищрений, даёт программисту полностью определённые типы:
int8_t
uint8_t
int16_t
uint16_t
int32_t
uint32_t
int64_t
uint64_t
Формат имён содержит лишний постфикс "_t".
Эти имена хороши тем, что Вы сразу видите полностью определённую длину типа - длину в битах. Т.е. Вы с абсолютной точностью знаете какую именно длину имеет Ваш тип. Это оберегает от ошибок. Также Вы видите знаковость и беззнаковость - "u" - это "unsigned". Это тоже важно.
Программа, написанная с использованием таких типов, будет работать абсолютно одинаково на любой аппаратной платформе.
В C5 эти типы выглядят так:
byte - uint8
int8
uint8
int16
uint16
int32
uint32
int64
uint64
В C# эти типы есть с самого начала:
Byte - Unsigned Byte
SByte - Signed Byte
Int16
UInt16
Int32
UInt32
Int64
UInt64
Непонятно зачем понадобилось сделать исключение из общей схемы именования для UInt8. Byte - чудесное слово. Оно могло быть алиасом этого типа.
Это абсолютно правильный подход.
Уже бывает, что не хватает типов Int128, UInt128. Реализация этих типов может быть с дроблением на части - по размеру регистров целевой машины. Например, Guid имеет этот размер - 16 байт.
Реальность такова, что процессорная техника развивается, и размеры регистров растут. В современности имем дело с 32-битными и 64-битными процессорами. Регистры этих процессоров имеют соответствующий размер. В частности, память адресуется этими регистрами. Если программируете с использованием указателей, Вам нужен специальный тип, имеющий размер регистра. Это значит, что в языке должен присутствовать специальный целочисленный тип, размер которого равен размеру регистра целевого процессора. В C5 он обозначается "int" и "uint". На 32-битных процессорах размер этого целого равен 32-м битам, а на 64-битных процессорах - 64-м битам. В будущем могут появится процессоры с регистрами 128 бит. Цифра для адресования памяти огромная, но когда-то глава одной известной корпорации был уверен, что 65 килобайт оперативной памяти компьютерам хватит на все времена. Я бы не стал ограничивать реализации языков программирования длиной регистра 64 бита. Этот специальный тип с переменной длиной, к сожалению, действительно, нужен. Например, для адресной арифметики. Например, для указания длины памяти. Это "native int" - "родной" тип "int" - целочисленное, имеющее размер "родного" регистра целевого процессора.
Имена типов "float" и "double" также являются неопределёнными. "float" - плавающий? Плавающий тип? Тип, который плавает? Принимает неопределённые значения? У меня такие ассоциации с этим именем.
В C5 имена этих типов заменены на "real32" и "real64" соответственно. Для той же определённости. Чтобы программист в самом имени типа видел длину и понимал что это за тип.
Причём, стандарт языка должен однозначно определять не только длину этих типов, но и внутреннюю структуру. Потому что эти типы состоят из трёх битовых полей - знака, степени и мантиссы. Есть стандарт IEEE 754. Типы "real32" и "real64" строго соответствуют этому стандарту. Например, real32 - это [1 бит знака | 8 бит экспоненты | 23 бита мантиссы] и соответствующий смысл битов. Стандарт языка C5 должен строго и однозначно определять, что эти типы соответствуют именно этому стандарту, и никакому другому. Тогда на это можно полагаться и строить интерфейсы. Стандарт CLI неслучайно определяет типы с полной строгостью. Неоднозначность реализации - это всегда проблема для построения программных систем. .NET совершенно правильно поступила, определив эти типы с полной строгостью. Если есть какие-то процессоры, которые используют другие форматы - то это их трудности. Мейнстрим - это стандарт IEEE 754. Именно этот формат используют процессоры с архитектурой x86 и amd64. Если что-то отличающееся - то производителям этого специального аппаратного обеспечения нужно делать программные или аппаратные конверторы. Эти отличия не должны создавать проблемы для общепринятых стандартов данных. Т.е. это их трудности, а не языка программирования высокого уровня. Принцип "зависит от реализации" неприменим.
По С# информация пятилетней давности: о .Net Core ни слова. Аматорский обзор )
О чем ты говоришь, она либо читает текст либо тупо его заучила, особо не понимая что говорит
А что бы вы добавили про C#? Если нужен подробный разбор, может быть мы сделает про него отдельный выпуск
Фронтенд разработчик рассказывающий о C это уже мило
Доброе утро всем)
а С# то каким боком к С/С++ относится ? Тогда и джаву сюда надо было причислить, ведь она тоже компилируемая и имеет си подобный синтаксис
Просто взяли все языки, в которых первая буква 'C'
Сколько нужно самостоятельно обучаться программированию, чтобы освоить хотябы азы? И какую литературу лучше выбрать?
@@Даниил-з5л смотря чему \ в каком направлении хочешь учиться ? + все сугубо индивидуально! Сайтики пилить можно научиться за пол-года - год. Программировать свои микроконтроллеры на Си - и 5-ти лет может быть мало.
@@ipaldesse суть в том, что в ближайшее время я хочу начать изучать язык. Я хочу быть мобильным разработчиком. Мне нужны базовые знания в этой области. Какой язык посоветуешь? Также понадобятся знания в веб разработке. Вот что начать изучать с самого нуля, чтобы понимать все это дело?
Так это си подобные языки.
Я искал +C для SAMP,но это тоже пойдёт
Хахаххахах
чел харош
Ахахахаха
лол))
Боже она просто солнце ! по больше бы выпусков с ней
Спасибо. Было очень интересно вас слушать
Неожиданно видеть девушку еще и красивую с супер фигурой ведущию такие ролики, супер. Умничка.
Начнёт с истоков
Динозавр
Си один из старейших 😅
я frontend разработчик... после этого выключил
Конечно Си, это не твой уровень
+
Потрясающия леди!
Я: я сделаю великую видеоигру!
Работодатель: круто. иди рисуй лутбокс и посчитай вероятности так чтобы фиол не выпадал, пиши документы для 120 человек, найди рефы по штук 200 достаточно, и сделай прототипы на блоках с механиками на С#. И вот аванс зп $250, вторая половина через две недели.
Жаль не нашел это видео самым первым. Очень лаконично и толково.
все было бы отлично,только вот разлетающееся эхо...
3:07 не согласен, это минус только на начальном этапах, и это далеко не так сложно как кажется. Да и плюсов гораздо больше от такого подхода
Дошел до места "за 3 месяца можно стать специалистом" 😂😂😂
а будет какая-то шутка в комментах к простейши ECHO-серверам на Си и звуком спикера ?
И бормотание слушать и рекламу, ппц
Стоит ли учить С# после С++ только чтобы писать игру под UNITY ? А может просто надо делать больше туториалов на С++ для CRYENGINE ? Тогда проблема с СИ#шарпом и UNITY отпадет сама собой 😁😁😁
Лучше python юнити понимает python
Я как человек который учил и то и то скажу, что не стоит учить Шарп если тебе нужны игры качай Unreal Engine я объясню почему из-за того что нет контроля памяти нужна крутая архитектура чтобы не приходил сборщик и у тебя не было лага в игре. А выучить то как нужно делать архитектуру в юнити уйдет больше времени чем на изучение Шарпа. Так как если одновременно много объектов перестают быть нужны то их удаление вызывает лаги ну либо нужен девайс получше отсюда требования к игре выше.
C# во многих отношениях лучше с++: надёжнее, нормальное ООП, чище синтаксис
Инфраструктура вокруг c# лучше: всякие асп нет, впф, сто тыщ шаблонов приложений и т.п.
@@oxfaaaaa9687 ну в плюсах тоже нормальное ООП про синтаксис согласен. Но суть в том что плюсы работают быстрее
@@GbyG_Ruslan согласен, слово "нормальное" здесь не подходит. Я имел в виду, что в c++ разрешено, например, множественное наследование. Хорошо это, или плохо - некорректный вопрос. Однако множественное наследование создаёт много сложностей и не очевидных проблем, что в свою очередь затрудняет и замедляет проектирование и разработку, хотя, возможно, и даёт какие-то преимущества.
К сожалению UNITY обходит UNREAL по весу выходного проекта. По качеству графики они примерно одинакового уровня
Ты 5й Unreal вообще запускал? Какое качество графики одинаковое?
Я тоже с wiki читать умею
Тогда где твое видео о с++?
Спасибо. Познавательно.
Спасибо за ролик. Но я за python))
Если изучить одного из них,то изучать остальных двоих легче будет или как?
Реализация switch-case в C/C++/C# неудачна. Это ветвление имеет путаный ход исполнения. Думаю, что это сделано нарочно - чтобы затруднить программирование и увеличить количество ошибок.
Последовательного исполнения ветвей в C5 не должно быть в принципе. На практике, это исключительно редкий случай, когда требуется исполнить одну ветвь, а вслед за ней - другую.
Наиболее часто встречается необходимость исполнения только одной ветви.
На этой схеме (в моноширинном шрифте) представлен идеальный и наиболее удобный оператор ветвления:
1) Исполняется ветвь 0;
2) Доходит до точки ветвления;
3) Выбирается только одна из множества ветвей {1, 2, 3, 4};
4) Исполняется эта ветвь;
5) Вслед за этим происходит выход за пределы оператора ветвления в общую ветвь 5.
|
|
0
|
_________|_________
| | | |
| | | |
1 2 3 4
| | | |
| | | |
-------------------
|
|
5
|
|
Только одна из ветвей {1, 2, 3, 4} должна исполнятся, а остальные - нет. Т.е. в конце каждой ветви должен происходить автоматический безусловный императивный выход за пределы оператора ветвления. В C/C++/C# этого нет - чтобы выход произошёл, Вам нужно написать ключевое слово "break" явно, иначе исполнение уйдёт в следующую ветвь. Эта логика очень мешает програмированию. Программисты очень часто забывают написать этот "break", и это приводит к ошибкам исполнения. Отсутствие "break" в конце ветви компилятор не замечает - нет ни ошибки ни предупреждения.
На практике, такая нужда, что после исполнения одной ветви требуется исполнить другую, - встречается очень редко.
Сама эта концепция, что после исполнения одной ветви нужно исполнить другую, - разрушает стройность оператора ветвления.
Поэтому, из C5 последовательное исполнение ветвей следует исключить. В C5 исполняется только одна ветвь, и в её конце происходит автоматический выход за пределы оператора ветвления.
Иногда встречается, что множество значений операнда switch соответствуют одной и той же ветке. Но это решается не путём последовательного исполнения ветвей, а путём перечисления всех вариантов в операторе case через запятую. Ветвь получается одна, просто ей соответствует множество вариантов операнда:
switch (A)
{
// Одна ветвь
// Переход в эту ветвь - при двух указанных значениях операнда
case 1, 2:
{
}
}
-----------------------------------------------------------------------------------
В языке C2 автоматический выход за пределы оператора ветвления реализован. Это правильно. Неправильно то, что сохраняется возможность последовательного исполнения ветвей. Там это реализовано с помощью ключевого слова fallthrough, которое ужасно звучит и индуцирует в сознании программиста мысли о падении. Падении программы?
-----------------------------------------------------------------------------------
Пусть Вас не пугает это "ограничение" функциональности. Цель этого сужения функциональности - обеспечение бОльшей ясности алгоритмов, бОльшей их простоты. Множество таких ограничений ввёл C# - и, как видите, язык получился очень хороший. Отсутствие макросов и заголовочных файлов - это чистая радость.
Устранение возможности последовательного исполнения ветвей также приведёт к бОльшей простоте программирования. Оператор ветвления будет выглядеть так же просто как на изображённой схеме: простейшее ветвление из одной точки в множество ветвей, лишь одна из которых исполняется.
-----------------------------------------------------------------------------------
Слова "switch", "case" и "default" - это паразитные слова, которые мешают чтению программы. "switch", и вовсе похоже на [witch] - "ведьма". Вероятно, имеются в виду плохие ключевые слова, внедрённые некоей ведьмой с целью усложнить программирование.
"switch" - это переключатель. Т.е. это даже не ветвление, а некая непонятная логика. Что, в общем-то, мы и видим.
"default"? "fault" - это неисправность.
C5 заменяет слово "switch" на "branch" с буквальным переводом "ветвь".
C5 заменяет слово "case" на "equal" с буквальным переводом "равно".
C5 заменяет слово "default" на "other" с буквальным переводом "другое".
Т.е. ветвь от операнда A. Если A равно такому-то значению - переход в эту ветвь.
Если все другие значения - переход в эту ветвь.
Выглядит это так:
-----------------------------------------------------------------------------------
// Переменная, значение которой определяет ветвь, которая будет исполнена
uint8 A;
...
// Оператор ветвления
branch (A)
{
// Операторы в этой ветви отсутствуют - не исполняется ничего
equal 1:
// Исполняется одиночный оператор
equal 2, 4: operator;
// Исполняется составной оператор
equal 5:
{
operator 1;
operator 2;
}
//-----------------------------------------------------------------------------------------------
// Синтаксическая ошибка - операнды "equal" не могут повторяться.
//
// Повторение операндов - это неоднозначность.
// Куда должен произойти переход? В эту ветвь или предыдущую?
equal 5:
//-----------------------------------------------------------------------------------------------
/////////////////////////////////////////////////////////////////////////////////////////////////
// Два нижеследующих варианта из синтаксиса следует исключить по той причине,
// что они формируют код, структура которого читается с трудом.
//
// Да, это могут быть все операторы до следующего ключевого слова "equal", "other"
// или конца оператора ветвления, но читать это программисту будет трудно.
// Поэтому следует оставить только отсутствие оператора, одиночный оператор и составной оператор.
equal 7: operator 6; operator 7;
equal 8, 9, 10, 11:
operator 10;
operator 11;
/////////////////////////////////////////////////////////////////////////////////////////////////
// Переход в эту ветвь - при всех других значениях операнда -
// при значениях, которые не перечислены в операндах equal.
//
// Эта ветвь может отсутствовать.
//
// Эта ветвь должна стоять в самом конце.
// Дело не в алгоритме: алгоритмически она может стоять в любом месте.
// Но программистам будет легче воспринимать и искать её именно в конце.
// Поэтому в C5 должно быть синтаксическое правило - эта ветвь может стоять только в конце,
// после всех операторов "equal".
other:
{
}
}
-----------------------------------------------------------------------------------
Всем привет! Ищу в компании разработчика Си (встроенное ПО) ОС Линукс для телекоммуникационного оборудования. г. Москва, если интересно пишите, подробнее расскажу. Спасибо за видео.
Не видел вакансий с С++
Слепой наверное
Поэтому учите Rust😁
могу сказать только одно, если создавать популярную онлайн игру на телефон - C++
Серьёзно?
4;00 Firefox переписывали на Rust
Теперь я знаю
Источник сведений насчёт скорости разработки на C++ и C#. Откуда эта информация? Приведите детали.
По моим ощущениям, разработка на C# намного быстрее, намного проще. Единственный недостаток C# - это производительность. Библиотека классов .NET восхитительна. Это лучший фреймворк из созданных.
как выучить этот С++? с чего начать)
глянь бесплатный курс на канале SimpleCode, но лучше выучить какой-нибудь нормальный язык, который нужен рынку, он ведь деньги платит.
@@ПростоЁж-щ3ъ подскажите пожалуйста, "...какой-нибудь нормальный..." это какой язык? я допустим для поступления python изучала и потом решила продолжить развиваться в нем. Но все как в один голос твердят, что python полная ху&ня, и лучше c++ изучать...или просто говорят перейти на какой-нибудь нормальный язык, но не говорят какой)
@@Анастасия-м5ф8м, все языки по-своему нормальные, просто, с каким-то будет легко на рынок выйти, а с каким-то по помойкам шастать первые несколько лет придется. Я бы отнес к нормальным, как раз python, Go, C#, js (любой фреймворк).
Достаточно легкие, достаточно легко найти первую работу на них и высокие зп, на них куча вакансий.
Вообще с c++ и вообще любым языком можно достичь всего, чего пожелаешь, при должном старании, лучше попробовать разное и выбрать что-то, что по душе, с чем тебе приятнее. (предупрежу, c++ по этим параметрам мало кому заходит)
@@ПростоЁж-щ3ъ Спасибо!)
> Выучить нормальный язык, который нужен рынку
> C++ постоянно сидит в топ-5 лучший ЯП'ов, мой друг.
Поверь, с плюсами тоже просто найти работу. На них пишутся всё ещё новые технологии + игры + на плюсах написано очень очень очень много строк кода => их нужно поддерживать
😍
Смотрю видеоролик и лайкаю, только потому что девушка симпатичная:)
Мечта маркетолога
Я тоже. Член всему голова
Можно её инстаграм?
@@fuunnyvideospeedrun Ты рофлишь или застрял в том времени,когда люди не пользовались соц-сетями ?
Мой инстаграмм @stasha_red) Правда я его подзабросила, надо исправляться)
кто из них быстрее?
@Krazley вопрос был задан: кто из них быстрее всего?
Мне стало плохо от с/с++, как же надоели со своими мифами
Обращаться с памятью в C#, действительно, очень удобно. Совершенно не нужно заботиться о её освобождении.
Сборщик мусора оставляет желать лучшего. Многие объекты он удалить не в состоянии. Это приводит к разрастанию кучи старого мусора, из-за которого процессы приходится периодически перезапускать.
Три всадника апокалипсиса
@Krazley по факту
азаза
лол
С
ськи
+
☺ Тут тоже есть незатейливое сравнение C++ vs C# ))♫ ruclips.net/video/HZiL5Ki-cxI/видео.html&ab_channel=XeNoTh
Какая мерзкая озвучка
кек
Нормальные программисты. Физику не знаете? Программами для монтажа пользоваться умеете? Хахахах, снимаете в подвале с хромакеем. Звук как из колодца.