Ну для такого банального примера можно хотя бы проверку сделать — есть ли там «торт» и .length. Хоть и обойти элементарно, но новички хотя бы не будут тупо писать ответ. Еще меня не порадовало, что "%ddss" считается нормальным именем. Либо уж просить псевдоним, и разрешать любые символы, либо сделать, опять же, хотя бы минимальную проверку — например, не начинается ли имя со спецсимвола.
«В строке 3, определите длину слова „торт“ и умножьте данное значение на 9. „
И корректными будут считаться программы “36», «12*3», " («3»+«6»)*1 ". Потрясающе. Получается, не важно, что в коде, лишь бы был верный результат? Лучше уж ничему не учить, чем такому.
Проблема в памяти будет. Радужная таблица позволяет существенно сэкономить место. Кроме того, помимо словарных паролей, с помощью различных функций редукции можно получить и несловарные пароли «в подарок».
В изложении статьи неочевидно, чем данная схема приницпиально лучше схемы с сертификатами.
А схему идентификации и подписи на основе известных данных предложили еще Кискатр (Jean-Jacques Quisquater) и Гиллу (Louis Guillou) в 1988. (Почитать можно в Шнайере).
Вам не кажется, что МК понятия не имеет о массивах и в любом случае надо будет хранить длину или какую-нибудь метку о конце массива?
Сомневаюсь, что ваш товарищ обрабатывал строки не как набор байт.
Вы программируете микроконтроллер, стек у вас очень маленький и передавать по цепочке вызовов 4 байта размера очень дорого.
Стек у него маленький, а место для отдельной подпрограммы для определения длины, или для хранения этой длины в объекте массива или для какого-то обозначения конца массива есть? На уровне машинных кодов как раз затраты будут либо сопоставимыми, либо в случае «динамического» определения они будут больше. Вообще если стек маленький, можно передавать через регистры или оперативную память (Вы когда-нибудь программировали что-нибудь для нашего Тесея или микроконтроллеров с малым числом памяти?).
Может, вы приведете еще и пример, для чего на микроконтроллере обрабатывать строки?
Идеальный язык тогда получается тот, у которого один оператор «Сделай мне <...>» (по аналогии с известной кнопкой) :)
Си, на мой взгляд, просто предполагает, что вы лучше продумаете программу. Он дает хороший набор базовых инструментов, из которых можно построить весьма многое.
И я правда все еще не могу придумать хороший пример, где реально нужно определять размер массива. Я везде передаю указатель с длиной.
P. S. И что же такое строка, как не набор (массив) символов?
Речь же идет о том, с чего начинать и в данном плане мое мнение заключается в том, что низкоуровневые языки не сделают мышление более логическим, но зато сильно увеличат время и сложность вхождения.
Из известных мне высокоуровневых языков я может бы посоветовал для начала только Питон.
ООП языки вроде Java и C# со своей парадигмой «все есть объект», фабриками классов и прочими абстракциями ни разу не облегчают вхождение. В перле можно свихнуться от количества вариантов сделать одно и то же. Lisp и Haskell не каждый обычный программист поймет. Другие языки имею узкую специализацию или не распространены (уж учится-то надо на распространненом языке, чтобы было много примеров).
Однако Питон скрывает детали. Я считаю, что человек, который начал обучение с С, сможет написать (с трудом и велосипедами) любую программу на любом языке. Человек, который начал с Питона, может столкнуться с трудностями, когда не будет его стандартной функции или синтаксического сахара в каком-нибудь языке. В С придется писать много своих функций. Много функций — много практики. Волей-неволей начнете писать сначала простые функции для перевода строки в число, потом для возведения в степень, а потом придется писать функции посложнее — вот и естественная эволюция. А в Питоне? Все уже сделали до вас. Но делать для себя это вас не научит. Зачем готовить пироги, когда можно сходить в кафе и купить там пирог?
Знаете, во всем есть неочевидное, и подводные камни есть в любом языке. И мне кажется нет «универсальной» «удобности».
Насчет расфокусировки — все зависит опять же от мышления. Я бы послал сына сразу за пятью яблоками, потому что столько было написано в рецепте пирога. А надо будет еще яблок — пошлю еще раз, сынок молодой, ему полезно бегать:)
Лично я изучал сначала Basic, потом Pacsal, потом delphi, и только потом C. Чем больше я программирую на С, тем больше понимаю, что он продуман. Да, не всегда он удобен. Но в нем есть логика. А программист, как я считаю, прежде всего должен мыслить логически. Тот же питон построен из соображений удобства. Это очень клевая вещь, но если не научится мыслить логично, то программы будут… творческие. В конце концов, чтобы стать отцом, готовящим пироги, я должен сначала побыть неопытным сынулей, которого гоняют за яблоками. И я буду знать, хотя бы приблизительно, как сын ходит за яблоками. И не буду требовать от него купить там же гвоздей, потому что я так хочу.
Например как получить размер массива интов? Само собой int len=sizeof(array)/sizeof(int);
Это вам не какой-нибудь array.Lenght на C#. А почему стоит деление, а не умножение, ответит даже ребенок.
Скажите, вот реально где это пригодится? В С размер массива задается при объявлении/выделении памяти под него и размер будет где-нибудь рядом. На ум мне приходит обработка массива функцией. Но что тогда делать, если мне нужно обработать не весь массив, а только его часть? ООП в моем представлении предложил бы такой путь: создать отдельный объекта массива и передать в функцию его. Поправьте меня, если я ошибаюсь. В С логично передавать с указателем на массив и его длину, и тогда обработка части массива свелась бы к указанию «от сих до сих». Без лишних сущностей.
Что до деления/умножения: совсем-то мозги отключать нельзя. Петя купил на рынке яблоки. За них он заплатил 40 рублей. Каждое яблоко стоит 5 рублей. Сколько яблок купил Петя? Не правда ли, задача класса для пятого, если не меньше? И тут есть два подхода — спросить Петю (хотя по логике ООП, как я себе еще представляю, Петя спросит мешок с яблоками, а мешок уже даст ответ) или посчитать самому, потому что Петя может быть тугодумом, говорить только на китайском, а нам вообще могут понадобиться только красные яблоки, а Петя вообще брал, какие попались.
Я считаю, что не стоит все забивать одним молотком ООП, а использовать там, где необходимо.
Ну вот насчет нераспространенности языка С зря. Недавно же была на хабре статистика популярности языков, и он был весьма популярен. Кроме того, компилятор для С или С-подобного языка сейчас есть практически для всего, даже для чайника. А на начальных порах, на мой взгляд, его стоит изучать, т.к. 1) он относится к группе структурных языков, на начальном уровне их проще изучать. 2) у многих языков С-подобный синтаксис, будет легче читать программы на других языках. 3) программы на С, как я считаю, сбалансированы в плане понимания — с одной стороны, каждую конкретную строку просто понимать человеку, с другой стороны — каждая строка относительно близко к железу и просто понять, как все работает. Не совсем корректно выразился, наверно, но не получается яснее выразить свои мысли.
Я бы добавил в список книг для прочтения «Искусство программирования для Unix» Реймонда. Всю ее осилить сложно, но можно прочесть оттуда отдельные главы после овладения базовыми навыками в программировании. Несмотря на название, в книге описываются хорошие принципы unix-программирования, а не программирования _для_ unix.
А еще советую в самом начале обучения пытаться все простые программы выполнять в голове. Расписывать, например, циклы по каждому значению счетчика, записывать, как меняются переменные и т.п. Это кажется бессмысленным и ненужным, но я рад, что мой учитель заставлял это меня делать, т.к. благодаря этому я стал лучше понимать, как работают программы и, как следствие, лучше писать свои.
И, напоследок, как тут уже советовали, лучше больше практикуйтесь, но совсем забивать на основы не стоит. Стыдно признаться, но из-за незнания основ я когда-то в школе для битовых операций переводил число в строку из нулей единиц и обратно.
Насколько я понял, когда работал с ней, у нее один ИК-рецептор на ручке, чуть выше кончика с чернилами (такой толсты ободок). Что-то вроде триангуляции, два луча от передатчика, к ручке — определяются координаты. Очень жаль, что никак не отслеживается наклон ручки.
И корректными будут считаться программы “36», «12*3», " («3»+«6»)*1 ". Потрясающе. Получается, не важно, что в коде, лишь бы был верный результат? Лучше уж ничему не учить, чем такому.
А схему идентификации и подписи на основе известных данных предложили еще Кискатр (Jean-Jacques Quisquater) и Гиллу (Louis Guillou) в 1988. (Почитать можно в Шнайере).
Сомневаюсь, что ваш товарищ обрабатывал строки не как набор байт.
Стек у него маленький, а место для отдельной подпрограммы для определения длины, или для хранения этой длины в объекте массива или для какого-то обозначения конца массива есть? На уровне машинных кодов как раз затраты будут либо сопоставимыми, либо в случае «динамического» определения они будут больше. Вообще если стек маленький, можно передавать через регистры или оперативную память (Вы когда-нибудь программировали что-нибудь для нашего Тесея или микроконтроллеров с малым числом памяти?).
Может, вы приведете еще и пример, для чего на микроконтроллере обрабатывать строки?
Си, на мой взгляд, просто предполагает, что вы лучше продумаете программу. Он дает хороший набор базовых инструментов, из которых можно построить весьма многое.
И я правда все еще не могу придумать хороший пример, где реально нужно определять размер массива. Я везде передаю указатель с длиной.
P. S. И что же такое строка, как не набор (массив) символов?
Из известных мне высокоуровневых языков я может бы посоветовал для начала только Питон.
ООП языки вроде Java и C# со своей парадигмой «все есть объект», фабриками классов и прочими абстракциями ни разу не облегчают вхождение. В перле можно свихнуться от количества вариантов сделать одно и то же. Lisp и Haskell не каждый обычный программист поймет. Другие языки имею узкую специализацию или не распространены (уж учится-то надо на распространненом языке, чтобы было много примеров).
Однако Питон скрывает детали. Я считаю, что человек, который начал обучение с С, сможет написать (с трудом и велосипедами) любую программу на любом языке. Человек, который начал с Питона, может столкнуться с трудностями, когда не будет его стандартной функции или синтаксического сахара в каком-нибудь языке. В С придется писать много своих функций. Много функций — много практики. Волей-неволей начнете писать сначала простые функции для перевода строки в число, потом для возведения в степень, а потом придется писать функции посложнее — вот и естественная эволюция. А в Питоне? Все уже сделали до вас. Но делать для себя это вас не научит. Зачем готовить пироги, когда можно сходить в кафе и купить там пирог?
Какой язык тогда не пофигистичный?
Насчет расфокусировки — все зависит опять же от мышления. Я бы послал сына сразу за пятью яблоками, потому что столько было написано в рецепте пирога. А надо будет еще яблок — пошлю еще раз, сынок молодой, ему полезно бегать:)
Лично я изучал сначала Basic, потом Pacsal, потом delphi, и только потом C. Чем больше я программирую на С, тем больше понимаю, что он продуман. Да, не всегда он удобен. Но в нем есть логика. А программист, как я считаю, прежде всего должен мыслить логически. Тот же питон построен из соображений удобства. Это очень клевая вещь, но если не научится мыслить логично, то программы будут… творческие. В конце концов, чтобы стать отцом, готовящим пироги, я должен сначала побыть неопытным сынулей, которого гоняют за яблоками. И я буду знать, хотя бы приблизительно, как сын ходит за яблоками. И не буду требовать от него купить там же гвоздей, потому что я так хочу.
Скажите, вот реально где это пригодится? В С размер массива задается при объявлении/выделении памяти под него и размер будет где-нибудь рядом. На ум мне приходит обработка массива функцией. Но что тогда делать, если мне нужно обработать не весь массив, а только его часть? ООП в моем представлении предложил бы такой путь: создать отдельный объекта массива и передать в функцию его. Поправьте меня, если я ошибаюсь. В С логично передавать с указателем на массив и его длину, и тогда обработка части массива свелась бы к указанию «от сих до сих». Без лишних сущностей.
Что до деления/умножения: совсем-то мозги отключать нельзя. Петя купил на рынке яблоки. За них он заплатил 40 рублей. Каждое яблоко стоит 5 рублей. Сколько яблок купил Петя? Не правда ли, задача класса для пятого, если не меньше? И тут есть два подхода — спросить Петю (хотя по логике ООП, как я себе еще представляю, Петя спросит мешок с яблоками, а мешок уже даст ответ) или посчитать самому, потому что Петя может быть тугодумом, говорить только на китайском, а нам вообще могут понадобиться только красные яблоки, а Петя вообще брал, какие попались.
Я считаю, что не стоит все забивать одним молотком ООП, а использовать там, где необходимо.
А еще советую в самом начале обучения пытаться все простые программы выполнять в голове. Расписывать, например, циклы по каждому значению счетчика, записывать, как меняются переменные и т.п. Это кажется бессмысленным и ненужным, но я рад, что мой учитель заставлял это меня делать, т.к. благодаря этому я стал лучше понимать, как работают программы и, как следствие, лучше писать свои.
И, напоследок, как тут уже советовали, лучше больше практикуйтесь, но совсем забивать на основы не стоит. Стыдно признаться, но из-за незнания основ я когда-то в школе для битовых операций переводил число в строку из нулей единиц и обратно.
habrastorage.org/storage1/3188516b/e6667783/755d19d6/ce45cc5f.jpg