Программирование. Самоидентификация.

Бери Objective C для XCode и дальше по вкусу: iOS/Mac OS. Разработка для мобил окажется легче, т.к. можно опустить часть с ассемблером.

А чем в основном разработчики под Mac OS занимаются? И зачем им ассемблер? Я думал они с железом дел не имеют, системного программирования под Mac OS нету

в С я изначально должен продумать тип данных для точек и не могу использовать списки, потому что на С просто нет такой возможности:) Примерно так?

нет. В C тоже можно менять тип данных и использовать списки. Очевидно, в учебниках, об этом не пишут. В K&R много написано о том, что такое указатель,, но не слова о том, как его нужно, и как НЕ нужно использовать. Фактически, книжки типа K&R — просто алфавит. Предполагается, что говорить тебя УЖЕ научили, ты просто не можешь свои слова записывать буквами. Дональд Кнут даже сишку не использовал в своих примерах, и фигачил любые списки/деревья прямо на ассемблере, который сам и придумал. А ты говоришь «нельзя». Можно, просто ты не знаешь как.

Ну так никто не мешает в CL юзать массивы вместо списков

ну никто не мешает в сишке НЕ юзать массивы. Их юзают в примерах просто потому, что примеры в книжках по сишке не про алгоритмы и структуры данных. Подумай, как-бы «понятно» выглядел-бы пример K&R, если-бы вместо массива там было красно-чёрное дерево? За деревьями ты не увидел-бы леса. Вот только потому там именно массив.

А вот если я в сишечке захочу использовать фичи CL, к примеру, оперировать со сколько угодно(ну почти) числом, или там extended массивом, то меня ждёт оверхед на реализацию таких типов, вместо того чтобы просто взять и пользоваться, в нужных местах оптимизируя как в сишечке!

никакого оверхеда нет, и быть не может. Как раз наоборот: обычно тебе не нужны ВСЕ фичи для работы со своими типами, потому твоя библиотека получается компактной и быстрой. А вот в CL тебе придётся тащить ВСЁ. Мало того, если уж так тебе хочется тащить ВСЁ в сишку, то ты всегда можешь юзать разные gmp и ещё Over9000 разнообразных либ. Причём с ровно таким же оверхедом как в CL, если не меньше(это даже баг, а не фича, ибо выше вероятность взять не ту батарейку).

А ты говоришь «нельзя». Можно, просто ты не знаешь как.

Он имел ввиду, что в сишке такого _встроенного_ типа данных как «список» нет.

А чем в основном разработчики под Mac OS занимаются?

Приложениями для апп стора, ассемблер не нужен :)

Он имел ввиду, что в сишке такого _встроенного_ типа данных как «список» нет.

и что? А в моём процессоре нет _встроенных_ CAR и CDR. За то там есть адреса памяти как сишные указатели, и целые числа как сишные int. Есть там и _встроенные_ double/float.

А списки по любому надо костылить через указатели и int'ы. Что в CL, что в сишке. И готовые костыли тоже есть и там и там.

Приложениями для апп стора, ассемблер не нужен

приложения для аппстора надо думать используют какие-то либы? Кто пишет либы?

Я уже говорил, как отобрать у gcc один регистр. Разница до 20% выходит.

Кто пишет либы?

Apple

Я уже говорил, как отобрать у gcc один регистр. Разница до 20% выходит.

ты признаёшь то, что ты умеешь только срать, гадить и портить?

никакого оверхеда нет, и быть не может.

Я не про этот оверхед. Я про то, что если я хочу написать прототип, в котором мне удобно использовать список и несколько операций над списком, к примеру map и reduce, то в CL(или там C#, F#...) я просто беру и использую это, а в сишечке мне нужно написать свою реализацию списка и операции над ним, оверхед во времени разработки!

Ещё пример, я хочу, чтобы мой список и операции над ним, работали с любыми типами данных, в высокоуровневых ЯП это есть из коробки, что же нужно мне делать в сишечке?

Ещё пример, пусть я решил что у меня есть геометрические примитивы - круг и линия. И я хочу их держать в какой нибудь структуре данных, пусть в списке. В лиспе так это вообще просто, так как в 1 списке могут быть разные типы данных. В C#/F#/... я создам общий интерфейс и буду держать в списке объекты, реализующие этот интерфейс. Что может быть проще? В сишечке есть способы, но это усложняет задачу и добавляет ненужные уровни более низкой абстракции.

тащить ВСЁ

а в чём проблема? ну есть там оверхед в килоббайты, ужас конечно для современного ПО, к тому же есть code walker, который вырезает всё что не используется... В сишечке, вроде, это делает линкер? А в CL можно даже делать ассемблерные вставки и юзать С.

Вообще, к чему сравнение ЯП высокого уровня с ЯП уровня железа?

А ты говоришь «нельзя».

я имел в виду из коробки, конечно можно написать хоть лисп на Си и писать на лиспе, но надо ли.

Кто пишет либы?

Apple

да, я знаю. А dll пишет microsoft. Dll-hell? Нет, не слышал.

Устал от мелкоменеджмента и хочется масштаба

Займись крупноменеджментом. Нафиг программирование, захочется повеситься

Ещё пример, я хочу, чтобы мой список и операции над ним, работали с любыми типами данных, в высокоуровневых ЯП это есть из коробки, что же нужно мне делать в сишечке?

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

В сишечке есть способы, но это усложняет задачу и добавляет ненужные уровни более низкой абстракции.

это зависит только от стиля. Если у тебя на высоком уровне абстракций идёт обмазывание битами, то ты ССЗБ. При чём тут ЯП? Кто мешал выделить нижний слой абстракции в другой файл? Да, в сишечке ты можешь сделать всё что хочешь, но разве кто-то заставляет тебя это делать?

а в чём проблема? ну есть там оверхед в килоббайты, ужас конечно для современного ПО

на миллион точек это уже гигабайты.

к тому же есть code walker, который вырезает всё что не используется... В сишечке, вроде, это делает линкер?

нет. Задача линкера — линковать. Обычно в программе Over9000 разных файлов на разных ЯП. Вот линкер их все и связывает в единое целое. В принципе никто не заставляет писать только на сишке, мало того, так мало кто делает (не считая ядра/модулей).

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

У всех этих языков (С/С++/ObjectC) есть одна «проблема» - они довольно низкоуровневые по сравнению, к примеру, с Java или C# - в первую очередь вам нужно понимать программную среду исполнения, в которой будут выполняться ваши программы и в целом требуют большего задротства (времени) как для разработки программ, так и в целом освоения языков

какой dll-hell? все организованно в удобный фреймворк.

это зависит только от стиля. Если у тебя на высоком уровне абстракций идёт обмазывание битами, то ты ССЗБ. При чём тут ЯП?

не понял, ты о чём? У меня есть круг и линия, и список геометрических фигур, какие биты? Я это вижу примерно так - создаю структуру с двумя массивами, для окружностей и линий, и список положений в общем списке. Вот лишний уровень абстракции, который скрывает отсутствие _одного_ списка фигур!

на миллион точек это уже гигабайты.

мы про разные вещи говорим:) Ты сказал, что если я хочу использовать списки CL, то мне прийдётся тянуть лишний код, к примеру я использую map и не использую mapcar, в выходном файле будет и map и mapcar, а я говорю, что есть code walker, который обрезает ненужное. Когда я копался в gcc, видел там тоже что-то подобное, но не помню как называется, суть одна.

В принципе никто не заставляет писать только на сишке, мало того, так мало кто делает

отчего же, если ты говоришь, что писать на Си высокоуровневые программы, так же удобно, как на ЯП типа лиспа или Java или ...

на миллион точек это уже гигабайты.

вроде мы уже решили, что в CL я могу явно задать тип для точки, к примеру uint_8

ты немного недопонял меня. «причины появляются после следствия» по часам следствия

ась? что это за физическое явление в котором нарушен принцип причиности? ( ведь если по часам события-следствия существует интервал когда событие-следствие уже в прошлом и событие-причина в будушем , то тут передача причиности в обратном направлении ходу часов события-следствия)

в целом требуют большего задротства (времени) как для разработки программ

4.2

вот здесь почитай: http://en.wikipedia.org/wiki/Learning_curve

Да, в этих твоих сишарпах низкий уровень вхождения, и любой дебил может писать на них код. Дебильный. Проблема в том, что новичок после «сишарп за 21 час» так и останется говнокодером. На всю оставшуюся жизнь.

C/C++ конечно за 21 час не осилить(и за 2100 тоже), но есть некий шанс стать программистом.

какой dll-hell? все организованно в удобный фреймворк.

знаю-знаю. Проходили 10 лет назад. Сказки рассказывай нубам, я уже слышал.

Зачем ты споришь с невменяемой, неграмотной, упертой сучкой? Не трать свое время на мразь.

Очевидно, в учебниках, об этом не пишут

неочевидно , вот в этом учебнике таки да. Reese R. - Understanding and Using C Pointers - 2013 ага это для

pseudo-cat как пример «идеоматического словаря(издание для чайников) об указателях»

ты о чем? миллион приложений в аппсторе без ассемблера и все счастливы.

не понял, ты о чём? У меня есть круг и линия, и список геометрических фигур, какие биты? Я это вижу примерно так - создаю структуру с двумя массивами, для окружностей и линий, и список положений в общем списке. Вот лишний уровень абстракции, который скрывает отсутствие _одного_ списка фигур!

кто тебе мешает сделать _один_ список фигур? Зачем тебе тут массивы? Да ещё и в структурах? Должна быть структура «фигура», которая может быть в списке.

Откуда тут вообще какие-то массивы появились? Что в них?

Ты сказал, что если я хочу использовать списки CL, то мне прийдётся тянуть лишний код, к примеру я использую map и не использую mapcar

я про более высокий уровень абстракций говорил. К примеру grep тянет glibc, хотя regex(7) там зачем-то сделан по своему, хоть в одном скользком месте и использует regex(7) из glibc. А эти твои mapcar — сам считай. Сам ведь говорил, что это копейки. Я их и не считал. Не помню, работает-ли это в gcc по дефолту или нет, вроде нет, т.к. gcc даже inlite всё равно в код тянет как мёртвую функцию.

отчего же, если ты говоришь, что писать на Си высокоуровневые программы, так же удобно, как на ЯП типа лиспа или Java или ...

я такого не говорил. Я говорил, что ФП для железа не годен. А про уровни ты начал. Давай уж про C++ поговорим, жэто как раз сишечка, но высокоуровневая. А в STL есть твои любимые списки, готовые, ЧСХ.

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

Практика программирования К&P и Юникс-универсальная среда программирования K&P , ну что за мания всё далать в среде одного «текста»

С-метод(т.е метод лаборатирии беллабс) лепим инстументы(можно и на с , а можно и на чём умееш) и из инструментов конструируем ... и так до.

в отличии от методов-Робинзона _ вот вам «язык(божественный) » и всё на нём , смолток и лисп среды этим «зло"употребляли - фанаты битофлипфлопинга тоже.

откуда задача , писать списки на сях с нуля , они же в стл (С++ :) ) есть и в objC(хз но очевидно есть) , ну а для pureC(можно найти отточеные и подкрутить старые реализации)?

вроде мы уже решили, что в CL я могу явно задать тип для точки, к примеру uint_8

не факт, что список из миллиона точек uint_8 займёт у тебя миллион uint_8. А вот в сишечке — факт. Правда ты потеряешь возможность вставки, т.к. для вставки в массив надо двигать пол-массива. Но ты можешь сделать и список, если это надо. Причём занимать этот список будет столько , сколько надо, а не хз сколько, как в лиспе.

ты немного недопонял меня. «причины появляются после следствия» по часам следствия

ась? что это за физическое явление в котором нарушен принцип причиности?

это я описался ☺ Конечно «следствия после причины по часам следствия». См. ниже — конуса где это не так не существует(в пределах этого континуума). Т.е. по любым часам следствие после причины, причём не раньше, чем за c секунд. Где c это инвариантная(предположительно) константа и зависит только от континуума.

миллион приложений в аппсторе

ты-бы постеснялся называть это «приложениями»...

я уже начинаю верить, что мне в самом деле интересно, как использовать указатели в С в тех случаях, когда в ЯП ВУ их не надо использовать :)

Это напоминает примерно следующее - у меня есть абстрактное дерево, как мне взять листья этого дерева? А ок, у меня же есть адреса ячеек памяти, возьму ка я и обращусь по ним, к тому же я внёс manage, который проверяет чтобы в эти ячейки не попал мусор, супер, скорее всего там и будут мои элементы. Стоп, элементы могут быть разной длины... Хмм, ок, тогда я помещу в эти ячейки адреса других ячеек разной длины, супер, теперь у меня есть указатель на указатель моего элемента. Ну разве не прелесть эта сишечка...

Программист на CL, к примеру, - так, пробегаю дерево и беру элемент у которого нет children с помощью, к примеру, car и помещаю в список/массив/другое дерево/хэш таблицу/телеграмму

Ну а попробуй без магии указателей сделать оптимизированный двунаправленный список, где указатель на следующий и предыдущий элемент xor-ятся и занимают одну ячейку.

Ты некомпетентен. Прекрати свое существование.

Зачем тебе тут массивы?

чтобы имитировать один список, в которым значения разных типов.

Должна быть структура «фигура»

настолько общая, чтобы и круг и полилинию и ... описывать? Оферхед на память, нет?

Я говорил, что ФП для железа не годен.

изначально я говорил про алгоритмы никак не связанные с железом, про ФП я вообще не слово не сказал

Давай уж про C++ поговорим, жэто как раз сишечка, но высокоуровневая.

ну это совсем пздц, работать на высоком уровне и выделять/удалять руками память, не хочу об этом ЯП, к тому же будет разговор не о с++, а о STL

ладно, пусть миллион + n много меньше, что это меняет в масштабе миллиона. К тому же не правильно сравнивать список и массив, а список в С так же вносит свой оверхед на n. Ну так я то могу в списке хранить элементы разной длинны, а ты, если у тебя 999999 чисел помещается в uint_8, а 1 нет - ловишь куда больший оверхед...

а как потом получить два указателя из одного? Я изначально сказал, что лично для моих задач, и задач большинства программистов, не требуется настолько извращаться, что бы использовать приёмы битовой алгебры и тп. В случае необходимости в CL можно использовать самый низкий уровень абстракции, но это почти никому не надо.

По низкоуровневому мне нравится вот такая книжка - http://www.ozon.ru/context/detail/id/1458852/ но использовать знания, усвоенные в ней, в повседневном программировании мне не приходилось ни разу

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

Стоп, элементы могут быть разной длины... Хмм

что хммм? Ты заколачиваешь гвоздь отвёрткой. Тебе нужен C++.

Ну а попробуй без магии указателей сделать оптимизированный двунаправленный список, где указатель на следующий и предыдущий элемент xor-ятся и занимают одну ячейку.

попробуй сделать такой на сишечке, с магией.

Ну не от батти же об этом узнавать. Посмотри хотя бы на ядро Linux, там очень все неплохо с иерархией абстракций.

А что там сложного-то? http://en.wikipedia.org/wiki/XOR_linked_list

чтобы имитировать один список, в которым значения разных типов.

«разные типы» в терминах C == разные структуры. Просто кастуй указатель на разные структуры в какой-то один тип, желательно в более общий. Это у тебя типичное ООП решение.

настолько общая, чтобы и круг и полилинию и ... описывать? Оферхед на память, нет?

не. Во первых есть каст, во вторых есть union. Можешь даже прилепить к каждой структуре указатель на VT, и будет у тебя virtual (pure)functions ничем не хуже C++(только страшенькие)

Только я не понимаю, зачем ты решаешь задачу как ООП, и при этом пытаясь доказать негодность НЕ ООП ЯП? C++ как раз и сделали потому, что сишка не ООПшная.

Мне например непонятно, на кой ляд было пихать круги, квадраты, точки и треугольники в один список? У тебя ведь только треугольники и точки? Сделай два списка. Нет? Тогда определись: сколько и какие.

изначально я говорил про алгоритмы никак не связанные с железом, про ФП я вообще не слово не сказал

сами по себе алгоритмы на первый взгляд не связаны. Но мы про реализацию.

ну это совсем пздц, работать на высоком уровне и выделять/удалять руками память, не хочу об этом ЯП, к тому же будет разговор не о с++, а о STL

при чём тут STL? STL это просто набор костылей, зачем о них говорить?

Что по поводу «память руками», то я как-то добился двухкратного профита. На php. Функцией unset().

почему именно С++? почему не Java или CL? Не понимаю, ты признаешь, что для задач с высоким уровнем абстракций не стоит использовать С, а стоит использовать ЯП ВУ. Но под ЯП ВУ имеешь в виду только С++, который, кстати, заставляет использовать НУ абстракций в савокупности с ВУ. Или это такая фича? Если да, то я и на CL могу использовать низкоуровневые оптимизации.

и что?

Что «и что»?

там для получения одного указателя нужно два рандомных(не кешируемых) обращения к памяти. Это тебе нужно иметь маленькую и быструю(по сравнению с CPU) RAM, как в 90х годах прошлого века. Сегодня у тебя большая и медленная память. Увы. Наверное годно для ембеддщиков, я не в курсе.

ты-бы постеснялся называть это «приложениями»...

то что приносит тонны денег создателям, вполне можно назвать приложениями, нет?

А где еще сишечкой-то пользоваться, как не в ембедщине?

ты признаешь, что для задач с высоким уровнем абстракций не стоит использовать С

абстракции разные бывают. У тебя это почему-то обязательно ООП.

Вот сишка с ООП — C++.

который, кстати, заставляет использовать НУ абстракций в савокупности с ВУ.

сколько повторять можно? Никто НЕ ЗАСТАВЛЯЕТ. Используй высокий уровень, перезагрузи new так, что-бы она строила фабрику памяти на Венере...

Или это такая фича?

да, фича. По умолчанию в C++ всё определено так, как в PureC. Например конструктор копирования копирует побитно, как int'ы. А operator new ведёт себя в точности как malloc(3). А operator+ складывает. А operator* разименовывает указатель. Это УМОЛЧАНИЯ. Ясное дело, что если твой тип надо копировать не так тупо, как int, то напиши — как.

А в моём процессоре нет _встроенных_ CAR и CDR. За то там есть адреса памяти как сишные указатели, и целые числа как сишные int. Есть там и _встроенные_ double/float.

то что приносит тонны денег создателям, вполне можно назвать приложениями, нет?

нет. Гомеопатия это лекарства? А порошок красной кобры собранный в восьмой день новолуния таиландской девственницей 17и лет, это лекарство от слабоумия?

«разные типы» в терминах C == разные структуры. Просто кастуй указатель на разные структуры в какой-то один тип, желательно в более общий. Это у тебя типичное ООП решение.

указатель является лишней прослойкой + оверхед N*размер указателя. Каст всех структур в obj, я так не помню такое возможно ли в сишечке, я так понимаю даже не рассматривается в виду оверхед +100500.

не. Во первых есть каст, во вторых есть union. Можешь даже прилепить к каждой структуре указатель на VT, и будет у тебя virtual (pure)functions ничем не хуже C++(только страшенькие)

могу, а могу писать на ЯП ВУ и не запариваться такими блуднями)

Только я не понимаю, зачем ты решаешь задачу как ООП

потому что ООП это всем понятный и простой способ абстрагирования. Многие ЯП представляют свои способы абстрагирования, не ООП в том числе, С не представляет, на С можно написать такие средства, только можно сразу взять подходящий инструмент, а не заготовку

Используй высокий уровень, перезагрузи new так, что-бы она строила фабрику памяти на Венере...

сначала надо использовать низкий уровень, для «перезагрузи new так, что-бы она строила фабрику памяти», что занимает лишнее время!