Сколько времени на это уйдет ?

Начинаю изучать Си, тяжело мне дается честно сказать. Напишу пример задачи, хотелось бы знать сколько времени нужно чтобы написать ее, занимаясь каждый день по 2 часа, плюс я не какой-то гений.

Задача:
Дан массив. Вывести на экран его максимальный элемент и сколько раз он встречается в массиве.

0

Сообщение от Yaroslavpwnz Начинаю изучать Си, тяжело мне дается честно сказать.

У меня для вас есть "странное предложение" -- если трудности вызывает исключительно синтаксис, почему бы не начать изучать паскаль, затем базовые алгоритмы с его использованием, а после освоения указателей не вернуться (или нет) на Си?
Паскаль был изначально создан специально для обучения, его синтаксис меньше провоцирует на совершение неявных ошибок, позволяя сосредоточиться на собственно алгоритмах, а не на выискивании синтаксических "блох" в коде.

1

Поддерживаю идею, только сейчас, в XXI веке, я бы рекомендовал взять какой-нибудь язык со сборкой мусора: Go, Python, C#, Lua, Java. Может быть даже Scheme, если ТС будет заниматься по книге "Структура и интерпретация компьютерных программ". Или Haskell, если охота настоящей функциональщины. Действительно, чтобы понимать алгоритмы, язык не важен, но высокоуровневый позволяет сосредоточиться исключительно на алгоритме, как таковом. А уж поняв алгоритм, реализуешь его на чем угодно, хоть на C, хоть на Forth, хоть на ассемблере.

Выгода от использования C может быть в том, что из-за скудости стандартной библиотеки любые структуры данных придется создавать самому. Что дает понимание, как они устроены. То же самое касается ООП: релизуя его на C, понимаешь как он "встроен" в ОО-языки. Но для того, чтобы понимать структуры данных, надо о них для начала знать. Вот и рождаются вычурные и неэффективные решения на С, объясняемые тем, что в нем, например, нет хэш-таблиц. И тут идет выбор меньшего зла: либо реализовывать хэш-таблицу самому, либо попытаться реализовать алгоритм без него. А вот в Lua, наоборот, хэш-таблица - единственный "коллекционный" тип данных. Но это может привести к тому, что начинаешь воспринимать хэш-таблицу как "золотой молоток", слишком привыкаешь использовать их где ни попадя. То есть у каждого языка есть достоинства и недостатки. Точнее, свои слабые и сильные стороны. И если хочешь изучить какую-то тему глубоко, можно взять язык, в котором эта тема - сильная сторона. Например, генераторы есть много где, но язык Unicon весь построен на них, что дает очень интересные эффекты и позволяет использовать идиомы, которых нет в других языках (но их можно туда привнести, но для этого надо иметь о них представления, а для этого желательно хотя бы чуть-чуть потренироваться на Unicon, из особенностей которого они и родились естественным образом). Ну и так далее и тому подобное. Изучение многих языков расширяет мышление. Знание одного - углубляет знания. Так что многое зависит еще и от того, хочет ли ТС развиваться в глубину или в ширину. Тот же C++, например, можно изучать десятилетиями, и все еще находить там неизвестные особенности, типа скрытых утечек памяти при передаче lvalue-параметра.

Пока у ТС есть время и он еще толком не знает, каким языком будет зарабатывать на жизнь (если вообще состоится в этой профессии), я бы рекомендовал развиваться "в ширину", изучая алгоритмы, структуры данных, парадигмы программирования, идиомы разных языков... Как минимум два языка, один сравнительно низкоуровневый (здесь очень подходит C), один высокоуровневый - Python, Ruby, JavaScript...

И еще один совет: пока мозги молодые, гибкие, изучи хотя бы один "экзотический" язык, которого (почти) никто не знает. Вакансии по ним появляются редко, но если уж появятся, то претендентов нет. Джавистов нужно много, а на рынке труда их еще больше, а вот Erlang, APL/J, haXe или Cobol нужны сравнительно редко, но на рынке труда специалистов по ним почти нет. Есть и другая точка приложения сил. Есть "вторичные" языки, которые, наоборот, нужны почти всем, независимо от "первичного" языка. Я имею в виду SQL и регулярные выражения.

1

Сообщение от LazySlacker И вообще, я не думаю, что на этом этапе важны микрооптимизации.

Ты вот такие речи загоняешь, а сам не можешь элементарно подумать:

Сообщение от LazySlacker C 1 if (max == NULL || *i > *max)

1. Если уж на то пошло, то этот вариант будет оптимальнее: if ( *i > *max || max == NULL ). Зачем каждый раз проверять max == NULL? По контексту понятно, что это условие выполнится только на первой итерации.
2. ( Мое сугубое мнение )

Сообщение от LazySlacker C 1 int* max = NULL;

Можно было сразу int* max = arr;, тогда бы и не пришлось выполнять эту дурацкую проверку: max == NULL.

0

Сообщение от Captain Maxee 1. Если уж на то пошло, то этот вариант будет оптимальнее: if ( *i > *max || max == NULL ).

То есть сначала разыменовываем указатель, а потом проверяем, что он может быть равен NULL? Классический баг.

Зачем каждый раз проверять max == NULL? По контексту понятно, что это условие выполнится только на первой итерации.

И что, это преступление?

Сообщение от Captain Maxee Можно было сразу int* max = arr;, тогда бы и не пришлось выполнять эту дурацкую проверку: max == NULL.

А если в будещем цикл изменится? Если нам понадобится проверить только часть (срез) массива? В том числе, возможно, нулевой длины?

Могу только повторить Вам Ваши же собственные слова:

Сообщение от Captain Maxee Ты вот такие речи загоняешь, а сам не можешь элементарно подумать:

И постарайтесь писать в менее оскорбительном и претенциозном тоне.

1

Сообщение от LazySlacker И что, это преступление?

Это преступление против эффективности. Зачем постоянно делать глупые лишние телодвижения если можно обойтись без них?

0

Сообщение от CoderHuligan Это преступление против эффективности. Зачем постоянно делать глупые лишние телодвижения если можно обойтись без них?

А я не понимаю, почему я должен думать за компилятор и пытаться облегчить компьютеру работу. Это компьютер должен облегчать мою работу. Я знаю такой тип программистов: экономят байты (а то и биты) памяти и тики процессора, в результате получается нечитаемый глючный код, вокруг которого надо плясать с бубном и дебаггером. У меня совершенно другое понимание программирования. С тупой работой компьютер справляется лучше, вот пусть он ее и выполняет. А программист должен думать над алгоритмом, а не искать утечки памяти и другие баги в жутко оптимизированной программе. Тем более что эта оптимизация зачастую вообще фиктивна. Например, мемоизация и ленивые вычисления в функционально-ориентированных языках могут дать выигрыш, на порядок больший, чем ручная оптимизация. В результате получается понятная программа, которая короче в 10 раз, проще для понимания, и не глючит. А работает так же быстро, как программа на C или C++. И даже если, например, в несколько раз медленнее, то зачастую выгоднее купить более мощный компьютер, чем терпеть убытки из-за затягивания сроков сдачи программы и глюков. А утечки памяти зачастую сводят на нет всю мифическую выгоду от ручного управления памятью. Структуры данных должны отражать предметную область, а не архитектуру компьютера. Ну и так далее.

1

Сообщение от LazySlacker То есть сначала разыменовываем указатель, а потом проверяем, что он может быть равен NULL? Классический баг.

Да, заговорился я. Естественно, я имел ввиду выполнить вначале 2 пункт, а потом 1.

Сообщение от LazySlacker И что, это преступление?

CoderHuligan уже ответил.

Сообщение от LazySlacker А если в будещем цикл изменится? Если нам понадобится проверить только часть (срез) массива? В том числе, возможно, нулевой длины?

Тогда придется переписывать код, разве нет?

Сообщение от LazySlacker И постарайтесь писать в менее оскорбительном и претенциозном тоне.

Постараюсь.

Добавлено через 1 минуту

Сообщение от LazySlacker С тупой работой компьютер справляется лучше, вот пусть он ее и выполняет.

Поаккуратнее со словами, молодой человек.

0

Сообщение от LazySlacker А я не понимаю, почему я должен думать за компилятор и пытаться облегчить компьютеру работу

В твоём случае имеется одно из самых больших заблуждений современных программистов - они считают, что компилятор всемогущ. Сильно вырожденным примером в случае с кодом из поста #17 будет выглядеть как: программист написал пузырьковую сортировку, полагая, что компилятор распознает, что тут делается сортировка и сам построит код qsort'а или любого другого вида логарифмически сложной сортировки

По факту мы имеем не практике такую картину, что процессоры становятся более быстрыми, а софт тормозит всё больше и больше. Отчасти (возможно, что даже в подавляющей части) причина связана именно с этим - люди не понимают и не хотят понимать, как работает компилятор. Ну а коль ты заговорил о других языках программирования, то не хотят разбираться с тем, какую конкретно задачу на каком языке программирования более грамотно реализовать. Людям кажется, что достаточно включить самый высокий уровень оптимизации, как компилятор сам исправит все алгоритмические и проектировочные косяки

3

0

Сообщение от LazySlacker Например, мемоизация и ленивые вычисления в функционально-ориентированных языках могут дать выигрыш, на порядок больший, чем ручная оптимизация. В результате получается понятная программа, которая короче в 10 раз, проще для понимания, и не глючит. А работает так же быстро, как программа на C или C++.

Ну с таким образом мыслей тебе нужно учить другие языки, где всё будет "автоматическим"...

0

Сообщение от Captain Maxee Поаккуратнее со словами, молодой человек.

Не пойму, что Вам не понравилось в этой фразе. Я имел в виду действительно тупую работу. В общем смысле. Я не называл тупым Вас или Вашу работу.

Сообщение от Evg В твоём случае имеется одно из самых больших заблуждений современных программистов - они считают, что компилятор всемогущ. Сильно вырожденным примером в случае с кодом из поста #17 будет выглядеть как: программист написал пузырьковую сортировку, полагая, что компилятор распознает, что тут делается сортировка и сам построит код qsort'а или любого другого вида логарифмически сложной сортировки

Ну это странная надежда, конечно. Я скорее имел в виду, что в похожем случае нужно выстроить архитектуру программы таким образом, чтобы для любых данных и для любых ситуаций можно было использовать стандартный qsort (или, в крайнем случае, свою сортировку, если есть уверенность, что она лучше, но реализованную в программе один раз). Писать свою сортировку только потому, что не сообразил, как использовать стандартную для своей специфической ситуации - почти всегда дурость.

Сообщение от CoderHuligan Ну с таким образом мыслей тебе нужно учить другие языки, где всё будет "автоматическим"...

Это можно сделать и на C, было бы желание. Другой вопрос, что программисту на C такой подход неизвестен или непривычен. Причем это не так сложно, как может показаться. И зачастую гораздо проще, чем писать плоский код, который весь работает на голом C, без всяких уровней абстракции. Никто же не говорит, что нужно сначала сделать из C C# или Haskell. Это бессмысленно. Но добавить какой-то уровень абстракции можно. Например, зайчатки ООП. Или какую-нибудь удобную (для данной конкретной задачи) структуру данных. Например, персистентные списки. Или перекидывать данные между функциями через стек, превратив C в частично конкатенативный язык (внутри функций будет обычный сишный код). Все это может привести к тому, что вместо десятков тысяч строк кода "просто на C" получается пара тысяч строк, который создают некий слой абстракции над C, а все остальное работает через этот слой. Причем получившаяся программа может быть и короче "плоской", и намного длиннее. Смотря от специфики ТЗ и выбранного слоя (или даже слоев) абстракции. Смысл не в этом, а в том, что эта часть получается гораздо проще, читаемее, надежнее. Можно и от необходимости ручной работы с памятью избавиться (не обязательно с помощью сборщика мусора, который "останавливает мир"). Можно сделать программу платформно-независимой, сконцентрировав платфомно-зависимый код в одном месте, вместо того, чтобы размазывать всякие ифдефы по всему коду. И так далее. Вплоть до того, что абстрагировать даже понятие "число". Чтобы не заботиться о том, что это - int, long, int64_t, size_t... Просто Number и все тут. Я знаю такой случай, когда программу на C# пришлось полностью переписывать, почти везде используя BigInteger. Другого выхода не было, такая задача попалась. Догадались бы абстрагировать число с самого начала - переписывать пришлось бы в одном месте. Вполне возможно, используя что-нибудь эффективнее BigInteger (IntX, например). Но на поиск альтернатив времени уже не было. Подытоживая: есть два типа программистов. Для одних программа - это код, а для других - архитектура. При этом грамотное архитектурное решение может дать выигрыш (в том числе иногда и в производительности, и уж всегда - в обслуживаемости, сопровождаемости кода), несравнимый с суммарным выигрышем от всех оптимизаций кода. Чтобы построить здание, не нужны идеальной гладкости кирпичи. Нужно спланировать, как класть кирпичи, чтобы получилось здание, а не груда кирпичей. А многие программы на C - даже не груда кирпичей, сваленная в кучу в надежде, что получится здание, а песок, сваленный в кучу в надежде, что песчинки как-то сами слепятся в кирпичи.

0

1

Сообщение от LazySlacker Или перекидывать данные между функциями через стек, превратив C в частично конкатенативный язык

А они разве не через стек перекидываются?

0

Сообщение от CoderHuligan А они разве не через стек перекидываются?

Я имел в виду другой стек. Погуглите, что такое конкатенативное программирование. А мне уже надоел этот разговор, честно говоря. Dixi.

0

Сообщение от CoderHuligan А они разве не через стек перекидываются?

Справедливости ради - не всегда. К примеру, в AVR первые 4 (или 8, не помню точно) байт передаются через регистры.
Насколько я знаю, стандарт не оговаривает механизм передачи аргументов, это решает компилятор.

0

Сообщение от COKPOWEHEU Насколько я знаю, стандарт не оговаривает механизм передачи аргументов, это решает компилятор

Это описано в программных соглашениях на конкретную архитектуру

2

Не совсем. Под ту же AVR есть несколько разновидностей компиляторов Си - gcc, CodeVisionAVR, IAR и другие. У каждого из них свои соображения по передаче параметров.
В любом случае Си предназначен для написания переносимых программ, а значит надо стараться как можно меньше полагаться на особенности какой-то конкретной реализации.

2

Чота глюкнуло и перепутал ARM с AVR

Под всякие специализированные железки (встроенные/сигнальные процессоры и т.п.) вполне возможно, что может твориться беспредел (т.е. коды, полученные разными компиляторами, могут быть несовместимыми). Но из этого никак нельзя делать глобальных выводов о том, что механизм передачи компилятор делает так, как ему вздумается. Для всех культурных процессоров есть программные соглашения, в которых всё записано

0

Но это все равно лишь договоренности. Причем компиляторы зачастую умеют подстраиваться к нетипичному способу. Вроде как передача параметров в Паскале, gcc и микрософтовском Си тоже несколько отличаются (глубоко не копал, наверное, порядком и тем, кто именно освобождает стек), поэтому иногда ставят модификаторы stdcall, pascal, __cdecl. Модификатор fastcall рекомендует компилятору передавать через регистры.
В общем, граблей хватает и на x86, надо только хорошенько поискать

0

Всех понял, всем спасибо

Добавлено через 1 минуту
спасибо большое, чуток разжевал )

0