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

указатель является лишней прослойкой

4.2

оверхед N*размер указателя.

4.2

Каст всех структур в obj, я так не помню такое возможно ли в сишечке

да. С нулевым кастом по времени(Внимание! Здесь водятся драконы!)

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

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

можешь писать на C++, и ВНЕЗАПНО перейти на PureC, когда это уместно.

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

ООП это самый простой способ абстрагирования. Есть более сложные для понимания. Сишка позволяет использовать ООП, но оно там не встроенное, а только ручное. Ну вот Линусу нравится например...

4.2?

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

Образование высшее экономическое

Про качество высшего говнообразования все в курсе. И как следствие:

Занимаюсь SEO более 7 лет

Что такое SEO тоже примерно все в курсе. Что-то вроде орифлейма и гербалайфа с помесью собирания бутылок. Грязная дешевая работа для самых непритязательных и низкоквалифицированных. Как следствие:

по ряду причин задумываюсь о переквалификации в управдомы программисты.

В околосеошной тусовке есть и свои «программисты», которые травят байки по заоблачные зарплаты и роскошную жизнь. Хотя они и находятся на несколько ступенек выше сеошников, все равно ведут нищюю и убогую жизнь.

- люблю учиться и разбираться - люблю осязаемые результаты - нет проблем с самоорганизацией - умею работать с литературой / данными любого объема - спокойно работаю как самостоятельно, так и в команде - (считаю что) могу разобраться практически в любой нужной мне теме (при наличии справочной информации) - (как бы это не звучало, но) имеется чувство прекрасного, что позволяет создавать вещи, которые нравятся другим людям (e.g. сайты) - люблю оптимизировать и оформлять

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

К частью для тебя ты живешь в нужной стране, где огромные денежные средства пропадают среди еще более тупых индивидуумов чем ты. Поэтому делай как все - крутись, вертись, и что-нибудь перепадет и тебе.

4.2 == ты не прав.

то есть, ты предлагаешь держать массив указателей на разные структуры и не согласен, что помимо самих N структур, прийдётся хранить указатели на них? То есть N1*размер структуры 1 + N2... + N*размер указателя. Какая магия используется?

Ой, ну да. Ну и всё равно ты лалка

В сишечке запросто функция void foo(void); может делать что угодно, и где угодно. ВНЕЗАПНО: ещё и когда угодно. Т.е. результат может проявится далеко не сразу.

Ситуация CL один в один. Там даже по стандарту на тот же ридер влияет куча переменных из пакета CL. И хрен бы кто-то знал, как и когда они на него повлияют, если бы не стандарт опять же.

Желания у местных борщеедов хоть отбавляй...

Лол, тут из всех лисперов может 2-3 на этом лиспе пишут. Остальные прочитали этот говносикп и пишут псто в стиле anonimous

Это притом, что в CL нет даже нормального типа, представляющего многомерный массив. Тот же мой воксельный рендерер на CL оказался в 30 раз медленнее аналогичного на C

в CL есть возможность явно указать тип значения. Сделав это, моё множество точек будет занимать примерно столько же места в памяти как в сишечке, где изначально нет возможности не указывать тип.

Ты какую-то абсолютную ерунду написал. Массив в том же SBCL - это такой же массив, как и в C + хидер, обозначающий тип и структуру этого массива. К явному указанию типа это имеет нулевое отношение.

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

Только время тратить на разработку тех фич, что и так имеются.

А вот в CL тебе придётся тащить ВСЁ

Ну а не пофиг ли? Ну выйдет у тебя 40 мб на харде и 100 мб в памяти. Ну и жалко шоле? По поводу быстродействия - ясное дело, что против C не попрешь, но сравнить можно, в отличие от всякого другого схожего по функциональности говна, что щас в моде

Это притом, что в CL нет даже нормального типа, представляющего многомерный массив. Тот же мой воксельный рендерер на CL оказался в 30 раз медленнее аналогичного на C

Ну охуеть теперь , значит многомерные массивы виноваты. И это ничё , что у тебя

 (reduce #'+ dot)

(+ (x dot) (y dot) (z dot))

то есть, ты предлагаешь держать массив указателей на разные структуры и не согласен, что помимо самих N структур, прийдётся хранить указатели на них? То есть N1*размер структуры 1 + N2... + N*размер указателя. Какая магия используется?

в твоём случае, ВНЕЗАПНО: списки. В каждой структуре указатель на next_object. Т.к. в точке у тебя штуки 3 float как минимум, то оверхед от лишнего указателя будет на порядок меньше, чем в CL.

Но ты так и не сказал: зачем в твоём случае _разные_ структуры в одном массиве?

Ситуация CL один в один. Там даже по стандарту на тот же ридер влияет куча переменных из пакета CL. И хрен бы кто-то знал, как и когда они на него повлияют, если бы не стандарт опять же.

потому что CL это ФП с Over9000 неФПшных костылей. Типа C++11, только древнее и замшелое говно.

Лол, тут из всех лисперов может 2-3 на этом лиспе пишут. Остальные прочитали этот говносикп и пишут псто в стиле

угу. ИЧСХ, ИМХО это общая ситуация по всей планете — на Руси 3.5 лиспера, а во всём Мире их штук 10, кто *реально* пишет.

Только время тратить на разработку тех фич, что и так имеются.

не трать, возьми готовые.

Я бы мог провести показательный тестик, но зачем? Ведь тебе всё один хрен, животнае

вина именно в массиве? как делал покажи

Массив в том же SBCL - это такой же массив, как и в C + хидер, обозначающий тип и структуру этого массива. К явному указанию типа это имеет нулевое отношение.

явное указание типа для элемента я имел в виду

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

Ах, ну да же. Пардон

Я хочу массив точек в 3-х мерном пространстве и потом обрабатывать его с помощью всех этих прибамбасов вроде map/reduce.

Но: массив #2a((1 2 3) (3 4 5) (5 6 7)) уже не sequence, а такой #(#(4 6 7) #(1 4 5)) хранит как минимум много лишней инфы.

Как быть тут?

В реальных задачах, которые пишут реальные программисты, выигранные тобой даже несколько мегабайтов

у меня даже тестовые задачки на CL часто падали или зависали. А тоже самое на C/C++ отлично работало. Да, у меня руки из жопы, касаемо CL. Но ты уверен, что ты действительно годный код на сишке пишешь?

а вот время разработки стоит многого

на самом деле оптимизировать весь код нет никакой нужды. Достаточно оптимизировать только 5% максимум, или даже меньше. Остальное можно писать хоть на php, это не имеет значения с т.з. ресурсоёмкости. Т.ч. про «время разработки» ты не прав. Как я уже говорил, для сишке полно всяких готовых костылей, т.ч. 95% кода можно писать легко и непринуждённо. Остальные 5% тоже, и оптимизировать их уже потом, когда это будет важно и критично.

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

там, где критична производительность не использовать map/reduce? Ты говоришь так, как будто я сказал, что использую более ВУ типы данных везде, где на С пишут массивы и считают байты, а потом сравниваю

CL часто падали или зависали.

Нормальная реализация не должна ни падать, ни зависать. Али что ты имеешь в виду?

Достаточно оптимизировать только 5% максимум, или даже меньше

Во-во. Можно и лишп с FFI взять, раз так приперло

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

Но ты уверен, что ты действительно годный код на сишке пишешь?

я вообще на сишечке не пишу и рассматриваю во всём этом диалоге С с точки зрения программиста, пишушего на высокоуровневом ЯП задачи с высоким уровнем абстракции

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

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

там, где критична производительность не использовать map/reduce?

map при возможности в цикл в sbcl разворачивается, это 100%. Так что пофиг.

тестовые наверное и есть тестовые, а не реальные?

ясное дело — не реальные. Зачем мне этот глюкодром в реальности? ☺

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

почему не подходит C++?

Нормальная реализация не должна ни падать, ни зависать.

а если данных МНОГО?

Написать свои map/reduce очевидно же. Ты меня игнорируешь?

Зачем мне игнорить ананимуса? Или если я не на каждый твой коммент отвечаю, то всё - трагедия?

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

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

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

ну вот и падает. Причём на таких детских значениях типа 1048576. Для сишечки это вообще ниочём. Даже в моё нетбук влезает тысяча массивов по 1048576 байтов. А я нетбук вообще за комп не считаю, только как терминал.

потому что приходится отвлекаться на низкоуровневые вещи

не нужно. Это миф и городская легенда. Считают такты и обмазываются битами только недалёкие люди.

Основной плюс, по-твоему, я так понимаю - из коробки есть С

не основной, но весомый. И не «есть», а «есть нативная интеграция с PureC».

* (reduce #'+ (make-array 1000000000 :element-type '(unsigned-byte 8)))

0

УМВР reduce чтобы точно убедиться, что он создается

я знаю. Там даже профит есть какой-то если сравнивать с виртуальными функциями C++. Вот как раз в таких одностроках и есть.

умные указатели не от простой жизни пишут наверное, да и ты предложил писать менеджер объектов чтобы не писать руками деструкторы, ну это ведь пздц, зачем это в ЯП ВУ

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

Ну нет, и что? Как язык связан с процессором? никто тебе не гарантирует, что лисп-программа не будет запущена на лисп-машине (где есть встроенные car/cdr), или что программа на сишке не будет запущена на managed процессоре, где нету встроенных указателей.

еще один забавный факт, раз уж вы сеошник, то работаете думаю в 99% с сайтами которые написаны на пэхапэ, как бы работу даже искать не надо для тренировки на кошках

умные указатели не от простой жизни пишут наверное

да, не от простой. Потому что в простой жизни указатели только на int/float могут указывать, а если они указывают на что-то более сложное, то получается ерунда.

В твоём любимом язычке просто этот указатель уже написан, и приколочен гвоздями к объекту. Вот тебе и кажется, что это «просто». На самом деле, просто это только в примитивных случаях.

да и ты предложил писать менеджер объектов чтобы не писать руками деструкторы, ну это ведь пздц, зачем это в ЯП ВУ

не распарсил. Если тебе нужен менеджер, пиши менеджер. При чём тут ручные деструкторы?

Да, поэтому и начал с php. Все равно, краеугольная проблема - это скорость. Поэтому кое-какие скрипты рекомендовали переписать на пайтоне и реализовать в виде десктопной прилаги. Были моменты, когда вообще не мог найти готовое решение / костыль для ряда проблем (например, при работе с google docs). Знания - сила )

ЯП == описание и синтаксис системы команд некого виртуального «процессора». Обобщённого и более удобного, нежели те реализации, что в железе. Компиляция == перевод программы с одного ЯП на другой. Лиспер должен это понимать.

Как язык связан с процессором?

непосредственно. Когда я пишу на сишечке, я примерно представляю, как мой код будет выглядеть на конкретном CPU. Могу даже посмотреть код, и понять — вот эта строчка даёт вот этот код, а та строчка — вот тот. На другом CPU код конечно будет отличаться, но не слишком сильно, и эти детали не имеют решающего значения(умножать/делить на константу можно сдвигом+сложением, а можно специальной командой. Для меня это не принципиально и не имеет значения, что именно подставит компилятор. Важно, что я и так пойму «вот тут — умножение/деление»)

никто тебе не гарантирует, что лисп-программа не будет запущена на лисп-машине (где есть встроенные car/cdr)

не гарантирует. Это тоже самое, что говорить производителю презервативов «никто не гарантирует, что твоё изделие не оденут на голову, вместо шапки». Ну может и оденут, зачем рассчитывать на идиотов? ☺

Все равно, краеугольная проблема - это скорость.

ВНЕЗАПНО: если переписать твой код с php на C/C++, то быстрее он работать НЕ БУДЕТ. Скорее всего — на 2..3 порядка медленнее.

Т.ч. даже не думай, что ЯП как-то поможет решить твою проблему. Грамотно написанная программ на PHP работает также быстро, как грамотный код на любом другом ЯП. Единственное исключение: если один из ЯП не предназначен для данной задачи. А php таки предназначен.

Поэтому кое-какие скрипты рекомендовали переписать на пайтоне и реализовать в виде десктопной прилаги.

БСК

Были моменты, когда вообще не мог найти готовое решение / костыль для ряда проблем (например, при работе с google docs).

при чём тут ЯП?

ЯП == описание и синтаксис системы команд некого виртуального «процессора».

Нет, не так. ЯП - это набор термов и отношение эквивалентности на них.

На другом CPU код конечно будет отличаться, но не слишком сильно

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

не гарантирует. Это тоже самое, что говорить производителю презервативов «никто не гарантирует, что твоё изделие не оденут на голову, вместо шапки». Ну может и оденут, зачем рассчитывать на идиотов? ☺

То есть попытка запустить программу, написанную на ЯП Х, на процессоре, который заточен для исполнения программ на ЯП Х, - это одевание презервативов на голову?

Не спорю. Но начинать С/С++ с 31 года мне кажется поздновато. Кстати я программист С++, поэтому сишарпы не мои, но нужно учитывать предварительные условия, прежде чем давать советы

а куда деватся? прыгнуть в прошлое и начать в 6 лет?

Это вызывает у меня недоумение, с каких пор приличные конторы нанимают джунов без каких-либо знаний?

Лоровским специалистам по всему лучше знать.

Человеку просто нужно сказать, что у него две дороги: 1. Изучать С/С++/Object-C - и когда начнет рости борода, появятся полезные результаты 2. Изучать более высокоуровневые языки, и полезные результаты появятся уже когда член еще будет стоять

В любом случае, он должен сам решить

Да, поэтому и начал с php. Все равно, краеугольная проблема - это скорость. Поэтому кое-какие скрипты рекомендовали переписать на пайтоне и реализовать в виде десктопной прилаги. Были моменты, когда вообще не мог найти готовое решение / костыль для ряда проблем (например, при работе с google docs). Знания - сила )

Да у тебя каша из говна в голове, что не удивительно. Тебе еще комплимент сделали, когда сравнили с пятнадцатилетнем. У пятнадцатилетнего хотя бы голова свежая, туда можно знания правильно уложить.