Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,указатели,Баян,баян, боян, баяны, бояны, баянище, боянище,it humor,geek,
Еще на тему
it-юмор geek указатели Баян
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,указатели,Баян,баян, боян, баяны, бояны, баянище, боянище,it humor,geek,
Подробнее
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,указатели,Баян,баян, боян, баяны, бояны, баянище, боянище,it humor,geek,
void (*Void)(void);
Ох и наебался я с этими указателями на указатели по студенчеству…
все с ними наебались. поэтому я пошел заниматься СУБД. не вытянул этого дерьма.
Коллега, получается
Так сами указатели вообще не сложные. Просто в си ебоватая нотация, которая запутывает.
По факту, ты в чём угодно всё равно используешь указатели. Но далеко не везде эта хуйня такая криптографическая, как в си.
По факту, ты в чём угодно всё равно используешь указатели. Но далеко не везде эта хуйня такая криптографическая, как в си.
Да ладно, что там криптографического то? Я блин в старшей школе по какой-то советской книжке разобрался за пол дня, и теперь живу с этим.
Вот ебанина с синтаксисом косвенной адрессации в разных ассемблерах под разные архитектуры реально иногда запутывает.
Вот ебанина с синтаксисом косвенной адрессации в разных ассемблерах под разные архитектуры реально иногда запутывает.
Там надо много думать, чтобы сделать нормально. Вот так с ходу...
Ну, во-первых, си рождался когда на стеке часто приходилось выделять память, а куча была экзотикой. Потому сейчас, когда всё на куче, всё нахуй указатель. Можно было бы сделать указатель по умолчанию, а для стекового/глобального отдельные кейворды. Которые означают, что вот тут у нас значение, а не указатель.
То же с передачей по референсу. Вместо кракозябры лучше бы использовать что-то типа "ref". От нескольких символов никто не помер бы.
Ну и вообще отделить блядь математические/логические операции от указаний типов . "*&" используются в разных контекстах. Причём, * это указание типа, а & перед именем переменной - это и указание типа, и операция, поначалу это путает просто пизда.
Плюс, какого хуя у нас переход по указателю "вниз" это "->', а "вверх" это "&", а не "<-. А почему бы тогда ссылку не брать как <-. Это нахуй в разы понятнее и просто интуитивно - двигаемся мы вперёд по указателям, или назад.
Это чисто вот сходу размышления, я же говорю, что по хорошему там дохуя подумать, и убрать самый буллшит, заменив на более интуитивные варианты, которые не надо запоминать и разбирать ребусы из одинаковых знаков.
Ты буквально описал C#, лол. Кому нужно на неуправляемом стеке жить, те и stackalloc/NativeMemory.Alloc (буквально обёртка над вызовом malloc) тянут, кто постарше на Marshall.AllocHGlobal (уже устарело, нормально только на окнах пашет), и пишут на классической поинтерной нотации с * и &. А кому нахрен это сдалось, те даже не парятся. Лишь раз в год добавляют ref там, где non-referenced значения по умолчанию нужно тягать конкретно по ссылке.
> Ну, во-первых, си рождался когда на стеке часто приходилось выделять память, а куча...
Ты пытаешься перетянуть универсальный язык среднего уровня к ЯВУ. Это плохая затея. Си существует до сих пор только благодаря его простоте и универсальности. Он накладывает минимальные ограничения ни использование памяти и вообще не предполагает что на таргете есть хип. И это позволяет писать на нём ядра ос, которые сами должны реализовать хип внутри себя.
> То же с передачей по референсу. Вместо кракозябры лучше бы использовать что-то типа "ref". От нескольких символов никто не помер бы.
Передача по ссылке просто не нужна, если можно передать указатель. Чем меньше вещей делаются неявно тем лучше для стабильности программ. Если у тебя параметр функции указатель - ты работаешь с ним как с указателем и понимаешь, что можешь поломать память. А лишние буквы - нахуй не упёрлись. Я полюбил си за то, что там было минимум букв в управляющих констукциях, и это хорошо.
> Ну и вообще отделить блядь математические/логические операции от указаний типов
Ну тут частично соглашусь - значки для взятия указателя и разыменования не слишком удачно выбраны, как и проблемы с плохой стандартизацией приоритета операторов. Если бы разрабатывать новый язык на смену, то стоило бы этот момент проработать тщательнее, но пока скобочки успешно решают проблему. Пользуйтесь скобочками господа.
> Плюс, какого хуя у нас переход по указателю "вниз" это...
Всё не так. Переход по уазателю "вниз" это *. Взятие адреса это &. A->B это сокращение для (*A).B - т.е. взятие поля структуры по адресу.
> Это чисто вот сходу размышления, я же говорю, что по хорошему там дохуя подумать, и
Знаешь почему Си до сих пор настолько популярен? Потому что те, кто делает ему замену всегда плохо понимают, что они делают. Либо как Страуструп пытаются переделать Си в ЯВУ, в итоге получается Кривое Монстро. Либо пытаются заставить компилятор думать за человека, как это делают создатели раст. Когда нибудь получится с развитием AI. Но не сейчас. А загонять программиста, который осознанно пишет на средне-низкоуровневом языке в рамки "делай так, а так тебе делать не надо" - это плохая идея.
Нет, я бы не отказался от полноценного приемника Си, свободного от 50+ лет легаси. Из того что ты тут назвал в него стоило бы взять только возможно слегка переработанные операторы. Остальное - мимо. Этот язык совсем не должен быть пайтоном.
Ты пытаешься перетянуть универсальный язык среднего уровня к ЯВУ. Это плохая затея. Си существует до сих пор только благодаря его простоте и универсальности. Он накладывает минимальные ограничения ни использование памяти и вообще не предполагает что на таргете есть хип. И это позволяет писать на нём ядра ос, которые сами должны реализовать хип внутри себя.
> То же с передачей по референсу. Вместо кракозябры лучше бы использовать что-то типа "ref". От нескольких символов никто не помер бы.
Передача по ссылке просто не нужна, если можно передать указатель. Чем меньше вещей делаются неявно тем лучше для стабильности программ. Если у тебя параметр функции указатель - ты работаешь с ним как с указателем и понимаешь, что можешь поломать память. А лишние буквы - нахуй не упёрлись. Я полюбил си за то, что там было минимум букв в управляющих констукциях, и это хорошо.
> Ну и вообще отделить блядь математические/логические операции от указаний типов
Ну тут частично соглашусь - значки для взятия указателя и разыменования не слишком удачно выбраны, как и проблемы с плохой стандартизацией приоритета операторов. Если бы разрабатывать новый язык на смену, то стоило бы этот момент проработать тщательнее, но пока скобочки успешно решают проблему. Пользуйтесь скобочками господа.
> Плюс, какого хуя у нас переход по указателю "вниз" это...
Всё не так. Переход по уазателю "вниз" это *. Взятие адреса это &. A->B это сокращение для (*A).B - т.е. взятие поля структуры по адресу.
> Это чисто вот сходу размышления, я же говорю, что по хорошему там дохуя подумать, и
Знаешь почему Си до сих пор настолько популярен? Потому что те, кто делает ему замену всегда плохо понимают, что они делают. Либо как Страуструп пытаются переделать Си в ЯВУ, в итоге получается Кривое Монстро. Либо пытаются заставить компилятор думать за человека, как это делают создатели раст. Когда нибудь получится с развитием AI. Но не сейчас. А загонять программиста, который осознанно пишет на средне-низкоуровневом языке в рамки "делай так, а так тебе делать не надо" - это плохая идея.
Нет, я бы не отказался от полноценного приемника Си, свободного от 50+ лет легаси. Из того что ты тут назвал в него стоило бы взять только возможно слегка переработанные операторы. Остальное - мимо. Этот язык совсем не должен быть пайтоном.
Эх, си. Настоящий лего программирования. Жаль я в тебя не могу(
Любой может. Я гарантирую это.
Просто копни глубже - изучи ассемблер какой нибудь. Самое простое что я знаю - для PIC16Fxx. Там 20 команд и простейшая логика. Я вилел как вообще не программист написал первую программу для этого контроллёра просто покурив мануалы и примеры за один выходной.
Сделай каких нибудь пару проектов на асме для чего угодно, и потом в Си войдёшь с ноги.
Вся эта истерия вокруг сложности и опасности Си из-за того, что люди не понимают как работает память компьютера.
Просто копни глубже - изучи ассемблер какой нибудь. Самое простое что я знаю - для PIC16Fxx. Там 20 команд и простейшая логика. Я вилел как вообще не программист написал первую программу для этого контроллёра просто покурив мануалы и примеры за один выходной.
Сделай каких нибудь пару проектов на асме для чего угодно, и потом в Си войдёшь с ноги.
Вся эта истерия вокруг сложности и опасности Си из-за того, что люди не понимают как работает память компьютера.
Да у меня просто времени нет его изучать(((
Алсо, то, для чего он мне нужен (хочу кое-что для распери пи микро сделать), требует таких финтов, которые не каждый про сможет; Я не хочу компилить прогу на расбери или ставить вторую ось... кросс-компайлинг через винду на линукс для расберри...
Алсо, то, для чего он мне нужен (хочу кое-что для распери пи микро сделать), требует таких финтов, которые не каждый про сможет; Я не хочу компилить прогу на расбери или ставить вторую ось... кросс-компайлинг через винду на линукс для расберри...
Слушай, я тут хз если честно. У меня мало опыта в программировании встаривоемого линукса.
Поройся на сайте дистрибутива, который на RPI используешь, там должна быть про кросс-компиляцию. В теории гцц на винде работает, и сделать нативный тулчейн под винду можно. Но это в теории. На практике вполне возможно что единственный путь будет через виртуалку или докер+виртуалку.
Поройся на сайте дистрибутива, который на RPI используешь, там должна быть про кросс-компиляцию. В теории гцц на винде работает, и сделать нативный тулчейн под винду можно. Но это в теории. На практике вполне возможно что единственный путь будет через виртуалку или докер+виртуалку.
На форуме мне посоветовали просто забить, ибо это такой геморрой, что не известно ни одного человека, так сделавшего(
Так и сидит в ящике(
Так и сидит в ящике(
Блядь, реактор сожрал нахуй весь смысл, вместе со знаками "меньше".
И, сукабля. Строки. То, что в си самое уебанское. Надо в жопу засунуть урановый лом и начать ядерную реакцию тому, кто придумал нулл-терминейтед массив байт как дефолтные строки использовать. Они медленные, они путанные, они источник миллиардов уязвимостей.
Почему не сделать тип строка? А хуй знает. Почему не длина сначала? Всё равно мы один байт всираем на терминатор(ну и нулл-терминейтед строку каждый желающий может себе организовать, только это нужно исключительно поезавшим). Хуй знает.
Почему не сделать тип строка? А хуй знает. Почему не длина сначала? Всё равно мы один байт всираем на терминатор(ну и нулл-терминейтед строку каждый желающий может себе организовать, только это нужно исключительно поезавшим). Хуй знает.
О, у меня есть мем по этому поводу!
Потому что в си нет строк. Вообще. Совсем. На этом всё, я могу уходить.
Null-terminated литералы это просто способ задать массив.
В конечном счёте никто не запретит программисту сделать под свою задачу свой собственный способ хранить строки.
По поводу медленности нуль-терминатед строк, тут бабушка надвое сказала. Если сравнивать с длинна-буффер строками, то медленнее (у нуль-терминатед) только взятие длинны. Перебор по строке быстрее, доступ к произвольному символу такой же/слегка быстрее. Как то так.
Да и паскаль-лайк строк типа длинна-буфер тоже есть куча недостатков. Самый большой из которых - невозможность на этапе проектирования языка предсказать какой размерности счётчик необходим. Вот представь, как кайфово бы было, если бы во всём по сейчас было бы техническое ограничение на длинну строки в 256 символов?
Null-terminated литералы это просто способ задать массив.
В конечном счёте никто не запретит программисту сделать под свою задачу свой собственный способ хранить строки.
По поводу медленности нуль-терминатед строк, тут бабушка надвое сказала. Если сравнивать с длинна-буффер строками, то медленнее (у нуль-терминатед) только взятие длинны. Перебор по строке быстрее, доступ к произвольному символу такой же/слегка быстрее. Как то так.
Да и паскаль-лайк строк типа длинна-буфер тоже есть куча недостатков. Самый большой из которых - невозможность на этапе проектирования языка предсказать какой размерности счётчик необходим. Вот представь, как кайфово бы было, если бы во всём по сейчас было бы техническое ограничение на длинну строки в 256 символов?
Строк как-бы нет, но как-бы есть. Ты ведь можешь написать
char* s = "хуй"
"В конечном счёте никто не запретит программисту сделать под свою задачу свой собственный способ хранить строки."
Именно. Именно поэтому их в плюсах сука миллион, и это гемор.
А так, маємо те, що маємо. Строки в си ответственны за 99% серьезных уязвимостей ПО. Потому что длина буфера выделенной памяти НИКАК не связана с сутью строки, и просто напросто неизвестна в любом коде, который выполняет с ней операцию. И если ты конкатенируешь строки(самая частая операция с ними), то тебе остаётся только молиться, что ты не хуячишь байты за пределы выделенного массива.
char* s = "хуй"
"В конечном счёте никто не запретит программисту сделать под свою задачу свой собственный способ хранить строки."
Именно. Именно поэтому их в плюсах сука миллион, и это гемор.
А так, маємо те, що маємо. Строки в си ответственны за 99% серьезных уязвимостей ПО. Потому что длина буфера выделенной памяти НИКАК не связана с сутью строки, и просто напросто неизвестна в любом коде, который выполняет с ней операцию. И если ты конкатенируешь строки(самая частая операция с ними), то тебе остаётся только молиться, что ты не хуячишь байты за пределы выделенного массива.
> char* s = "хуй"
Могу. Но это не делает s строкой. char*s - это указатель на память, где компилятор заботливо положит твой хуй и нуль-терминатор.
А ещё это плохая практика. Если по s происходит только чтение памяти, то это надо указать
char* const s = "хуй";
Так компилятор-линкер смогут положить твой хуй в ro сегмент.
А если предполагаются изменения в хуе, то надо сделать например так:
#define S_SIZE 16
char s[S_SIZE] = "хуй";
> Строки в си ответственны за 99% серьезных уязвимостей ПО
Не оружие убивает людей, людей убивают другие люди. Проблемы с безопасностью при использовании в си стандартных строковых функций есть, но высокий процент уязвимостей вызавн лишь тем, что высокий процент кода написан на С или использует стандартную библиотеку С, а какое нибудь целочисленное переполнение эксплуатировать гораздо сложнее чем проёб буфера.
Процент всё равно не так велик как ты указываешь. Есть ещё проблемы с экранированием в языках высокого уровня, инекции кода, воровство/подмена кук и т.п. ЯВУ- и ВЕБ-характерная дичь на которых держатся большинство атак на вэб.
Как не крути, то что в си нет строк не делает его отвественным за проблемы с безопасностью. Проблемы с безопасностью это всегда ошибка людей, и неграмотный человек напишет уязвимый код хоть на языке ада.
Могу. Но это не делает s строкой. char*s - это указатель на память, где компилятор заботливо положит твой хуй и нуль-терминатор.
А ещё это плохая практика. Если по s происходит только чтение памяти, то это надо указать
char* const s = "хуй";
Так компилятор-линкер смогут положить твой хуй в ro сегмент.
А если предполагаются изменения в хуе, то надо сделать например так:
#define S_SIZE 16
char s[S_SIZE] = "хуй";
> Строки в си ответственны за 99% серьезных уязвимостей ПО
Не оружие убивает людей, людей убивают другие люди. Проблемы с безопасностью при использовании в си стандартных строковых функций есть, но высокий процент уязвимостей вызавн лишь тем, что высокий процент кода написан на С или использует стандартную библиотеку С, а какое нибудь целочисленное переполнение эксплуатировать гораздо сложнее чем проёб буфера.
Процент всё равно не так велик как ты указываешь. Есть ещё проблемы с экранированием в языках высокого уровня, инекции кода, воровство/подмена кук и т.п. ЯВУ- и ВЕБ-характерная дичь на которых держатся большинство атак на вэб.
Как не крути, то что в си нет строк не делает его отвественным за проблемы с безопасностью. Проблемы с безопасностью это всегда ошибка людей, и неграмотный человек напишет уязвимый код хоть на языке ада.
"Могу. Но это не делает s строкой. char*s - это указатель на память, где компилятор заботливо положит твой хуй и нуль-терминатор.
А ещё это плохая практика. Если по s происходит только чтение памяти, то это надо указать
char* const s = "хуй";
Так компилятор-линкер смогут положить твой хуй в ro сегмент.
А если предполагаются изменения в хуе, то надо сделать например так:
#define S_SIZE 16
char s[S_SIZE] = "хуй";"
Именно, блядь.
Вместо того, чтобы добавить в компилятор и язык более полноценные строки, которые ну объективно нужны часто и много, сделали вот это недоразумение, вызывающее огромное количество проблем.
А ещё это плохая практика. Если по s происходит только чтение памяти, то это надо указать
char* const s = "хуй";
Так компилятор-линкер смогут положить твой хуй в ro сегмент.
А если предполагаются изменения в хуе, то надо сделать например так:
#define S_SIZE 16
char s[S_SIZE] = "хуй";"
Именно, блядь.
Вместо того, чтобы добавить в компилятор и язык более полноценные строки, которые ну объективно нужны часто и много, сделали вот это недоразумение, вызывающее огромное количество проблем.
Много где, но не везде. А из того где надо часто сишными методами вполне можно обойтись или даже стараются ими обойтись.
А там где звёзды сошлись, и производительностью можно пожертвовать, и памяти много, и хип, и ос, и окружение - во первых, а тебе точно нужен си а не пайтон? Во вторых - как я уже сказал, никто не запрещает написать свой костыль или взять какой нибудь готовый для хандлинга строк так, как тебе надо.
Если гипотетически предположить новый язык - убийцу си, сама по себе зависимость от хипа (по другому нормально строки на все случаи жизни не сделать) равно как и сокрытие работы с памятью сделает его ущербным рядом с C, и как результат - мертворожденным.
А там где звёзды сошлись, и производительностью можно пожертвовать, и памяти много, и хип, и ос, и окружение - во первых, а тебе точно нужен си а не пайтон? Во вторых - как я уже сказал, никто не запрещает написать свой костыль или взять какой нибудь готовый для хандлинга строк так, как тебе надо.
Если гипотетически предположить новый язык - убийцу си, сама по себе зависимость от хипа (по другому нормально строки на все случаи жизни не сделать) равно как и сокрытие работы с памятью сделает его ущербным рядом с C, и как результат - мертворожденным.
Пайтон... Не надо про пайтон.
Чтобы понимать, я пишу на жабе, для реалтайм систем. Внезапно, это возможно, если писать в си стиле. Ну и всё обвешано ансейфом и нативными вызовами того самого си, но логику радикально быстрее и безопаснее писать на джаве, благо, при соблюдении некоторых правил оно работает один в один как си по скорости (в конце концов, компилится оно в ту же хуйню, что и си), но без опасений взорвать хип неаккуратным движением.
Так вот, пайтон это нахуй пиздец. Он настолько медленный и непрозрачный, что когда приходится на нём делать что-то побочное, у меня волосы на жопе шевелятся. Просадка в 100 раз на ровном месте - просто легко, и нормально не фиксится в связи с базовыми особенностями языка.
Чтобы понимать, я пишу на жабе, для реалтайм систем. Внезапно, это возможно, если писать в си стиле. Ну и всё обвешано ансейфом и нативными вызовами того самого си, но логику радикально быстрее и безопаснее писать на джаве, благо, при соблюдении некоторых правил оно работает один в один как си по скорости (в конце концов, компилится оно в ту же хуйню, что и си), но без опасений взорвать хип неаккуратным движением.
Так вот, пайтон это нахуй пиздец. Он настолько медленный и непрозрачный, что когда приходится на нём делать что-то побочное, у меня волосы на жопе шевелятся. Просадка в 100 раз на ровном месте - просто легко, и нормально не фиксится в связи с базовыми особенностями языка.
Да. Очень интересно, держи в курсе.
Если у тебя в проекте есть хип, то у тебя или такой себе реалтайм, умерено жесткий. Или у тебя задача с минимальным потреблением памяти. Но это вряд ли. Вангую что у тебя там многоядерник на кортекс-А, линукс-рт и реакция в миллисекундах.
И да. Я как то рисовал в гимпе на ноуте используя вместо планшета/мышки стик, причём делал это на выставке, в окружении людей. Я больший извращенец чем ты.
Если у тебя в проекте есть хип, то у тебя или такой себе реалтайм, умерено жесткий. Или у тебя задача с минимальным потреблением памяти. Но это вряд ли. Вангую что у тебя там многоядерник на кортекс-А, линукс-рт и реакция в миллисекундах.
И да. Я как то рисовал в гимпе на ноуте используя вместо планшета/мышки стик, причём делал это на выставке, в окружении людей. Я больший извращенец чем ты.
Реакция с пределом 1 микро секунд(+1 на сеть, разумеется, в обход системы и проца). Хип как-бы есть, но разумеется, всё на реюзе и преаллокации.
Ты больше извращенец, но за мои извращения хорошо платят)
Ты больше извращенец, но за мои извращения хорошо платят)
И код, который реагирует в пределах 1 микросекуны написан тобой на яве в юзерленде, а не сишником в виде модуля ядра? Чот прохладно.
Пусть у тебя кортекс а на 2ГГц, тогда 1 микросекунда это около 2000 циклов процессорных.И за эти 2000 циклов надо отработать прерыванию, ткнуть мьютекс, прокрутится планировщику, переклюдчить контекст, отработать твой жаба-код и пнуть условный GPIO. Не то что бы это не было реально, но.. это до первого случая, когда конкурентные запросы придут с маленькой дельтой по времени. И тогда какой то из запросов просто провиснет и пробьёт бюджет времени, пока процессор будет заниматься контекст свитчингом.
Или ты модули ядра на жабе пишешь?
Пусть у тебя кортекс а на 2ГГц, тогда 1 микросекунда это около 2000 циклов процессорных.И за эти 2000 циклов надо отработать прерыванию, ткнуть мьютекс, прокрутится планировщику, переклюдчить контекст, отработать твой жаба-код и пнуть условный GPIO. Не то что бы это не было реально, но.. это до первого случая, когда конкурентные запросы придут с маленькой дельтой по времени. И тогда какой то из запросов просто провиснет и пробьёт бюджет времени, пока процессор будет заниматься контекст свитчингом.
Или ты модули ядра на жабе пишешь?
Юзерспейс. Использование ядра запрещено (работа напрямую с памятью сетевой карты, без ядра, без копирований), выделение памяти запрещено, мьютексы и любая синхронизация запрещена, переключения контекста запрещено(всё строго прибито к ядрам), работа только с памятью своей нумы кроме отдельных случаев(ох с этим ебля была), никаких IO. Запросы приходят и уходят через RDMA, какие в пизду конкурентные запросы?
И да, система выселена на одно ядро, на рабочие она права лазить не имеет. На них только и исключительно наши процессы. Даже слип потока запрещён, выход из него слишком затратный. Потому все ядра всегда крутят пустой цикл, если нечем заняться. Передача данных между ядрами и творческая ебля с кэшами процессора и интерконнектом - отдельный блядский цирк.
Т.е. у вас там отдельный юзейспейс процесс прибит гвоздями к конкретному ядру, которому запрещено обрабатывать прерывания и который крутится в бесконечном цикле? И это на нормальной системе, где на свободных ядрах работает ос? Чел не продолжай. Действительно блядский цирк. Вам очень сильно не хватает в команде хорошего программиста.
Чукча не читатель, да? И процессы у чукчи прибиваются к ядрам, ага.
Система выселена на одно, потоки распределны по ядрам. Как ты ПРОЦЕСС собрался аффинить, для меня ваще загадка. Аффинятся треды.
Хорошие программисты нам, конечно, нужны, но тебя бы не взяли, ты уже дважды игнорируешь написанное, а это очень плохой признак.
Ну, как пишешь так и читают. Я не правильно понял предложение про систему, спорить не буду. Но оно максимально корявое. Сейчас с третьей попытки сообразил вроде. У вас есть одно "системное" ядро, на котором крутится всё, не связанное с рт, а рт процессы прибиты каждый к своему ядру и в бесконечном цикле читают-пишут-ждут запрос. Детали ясны, но всё равно куда не плюнь как то где то не стыкуется. Как у тебя ява в рт работает, если выделения памяти запрещены? Или ява там только для того, что бы эмулировать хип стеком в обход ос? С одной стороны топология системы напоминает что то сверхнагруженное... и вдруг объектно-ориентированная ява с потерями на выделение памяти? Что то там у вас не ладно в датском королевстве.
Что бы ты правильно меня понимал, когда я говорил про хорошего программиста, я просто констатировал факт, а не предлагал свою кандидатуру. Я слишком много сил убил на лечение депрессии что бы работать с.. этим. Да и ява легаси будет слишком сильно давить, даже если начать всё переделывать нормально. Так что я пас.
Что бы ты правильно меня понимал, когда я говорил про хорошего программиста, я просто констатировал факт, а не предлагал свою кандидатуру. Я слишком много сил убил на лечение депрессии что бы работать с.. этим. Да и ява легаси будет слишком сильно давить, даже если начать всё переделывать нормально. Так что я пас.
А с чего ты решил, что ява не может работать без выделения памяти? Мы, естественно, не используем ни стандартную либу, ни сторонние в рабочем цикле. При ините - да, там всё, что угодно можно, и это одно из удобств. А сам язык не требует выделения памяти. Это не питон, где можно нечаянно это сделать. Насоздавал в начале, и реюзай до конца. Даже неявного копирования, как в плюсах, нету.
Ява для удобного инита, где вся её мощь, нормальных эксепшнов, если таки пизданулось(в реальном мире живем), устойчивости к падению всего(сишное у тебя упадёт всё сразу, у явы падает только ошибочный поток и его можно аварийно переподнять, или как минимум сохранить стейт и сделать graceful shutdown, вместо просто хуяк и всё), автоматическое отсутствие ошибок с памятью, и удобную работу с кодом(IDE для явы просто качественно иные, чем для плюсов, несравнимо более удобные). Из минусов - только то, что писать надо в си стиле, так это и на си придется делать, только менее удобно и безопасно.
Ява для удобного инита, где вся её мощь, нормальных эксепшнов, если таки пизданулось(в реальном мире живем), устойчивости к падению всего(сишное у тебя упадёт всё сразу, у явы падает только ошибочный поток и его можно аварийно переподнять, или как минимум сохранить стейт и сделать graceful shutdown, вместо просто хуяк и всё), автоматическое отсутствие ошибок с памятью, и удобную работу с кодом(IDE для явы просто качественно иные, чем для плюсов, несравнимо более удобные). Из минусов - только то, что писать надо в си стиле, так это и на си придется делать, только менее удобно и безопасно.
Ну иде и удобство языка это вопросы религии. Просто отмечу несколько моментов.
Эксепшны хоть и не являются частью языка, вполне себе хандлятся на си без проблем, что софтварные (привет farcall) что аппаратные (платформенно зависимый код).
Про то что сишный код падает сразу и весь тогда как явовый может увпсть по частям - очень смешно выглядит, с учётом того, что рантайм жабы написан на сях. Си имеют столько же или больше возможностей для обработки падений, сколько и ява.
Возвращаясь к вопросу трудоустройства, полажа руку на сердце, если бы я был проект менеджером, то я бы тебя уволил бы если ты настаивал на таком подходе.к разработке. Без обид и личной неприязни, просто из прагматических соображений. Заменить в проекте Сишника может быть сложно, но вполне реально. А вот найти второго такого мегаявиста, который сможет на яве не просто писать без утечек (а даже такого не просто найти) а чела, который разберется как вы там так яву раком поставили, зачем и куда..
В любом случае мы слишком сильно отдалились от темы разговора. В любом случае использование языков вроде явы в РТ среде это извращение и головная боль. Всё что можно было сказать я сказал, так что пожалуй я прекращаю отвечать в данной ветке. Удачи.
Эксепшны хоть и не являются частью языка, вполне себе хандлятся на си без проблем, что софтварные (привет farcall) что аппаратные (платформенно зависимый код).
Про то что сишный код падает сразу и весь тогда как явовый может увпсть по частям - очень смешно выглядит, с учётом того, что рантайм жабы написан на сях. Си имеют столько же или больше возможностей для обработки падений, сколько и ява.
Возвращаясь к вопросу трудоустройства, полажа руку на сердце, если бы я был проект менеджером, то я бы тебя уволил бы если ты настаивал на таком подходе.к разработке. Без обид и личной неприязни, просто из прагматических соображений. Заменить в проекте Сишника может быть сложно, но вполне реально. А вот найти второго такого мегаявиста, который сможет на яве не просто писать без утечек (а даже такого не просто найти) а чела, который разберется как вы там так яву раком поставили, зачем и куда..
В любом случае мы слишком сильно отдалились от темы разговора. В любом случае использование языков вроде явы в РТ среде это извращение и головная боль. Всё что можно было сказать я сказал, так что пожалуй я прекращаю отвечать в данной ветке. Удачи.
Дааа, а теперь в шарпе их так не хватает(
Да ну...
unsafe
{
byte* ptr;
}
Только все в рамках родного процесса. За пределы, как С(++), ни-ни.
unsafe
{
byte* ptr;
}
Только все в рамках родного процесса. За пределы, как С(++), ни-ни.
От я о том же
указатели ёбаные
Ну его этот int** или int***. Транслирую все в одномерную матрицу int*, когда надо обмазываться Си
а ничего, шо они в разных диапазонах адресов могут находиться?
Почему?
for (int i = 0; i < x; ++i) {
for (int j = 0; j < y; ++j) {
for (int k = 0; k < z; ++k) {
flatMatrix[i * (y * z) + j * z + k] = matrix[i][j][k];
}
}
}
Я правильно понимаю, что нет истины, а только работает и не работает?
Ну да. Падает GTest или не падает, TDD. В C++ все это в красивых удобных обертках std::array/std::vector
Если надо работать просто с многомерными массивами известной размерность то правильное решение.
int** удобен, когда надо обрабатывать несколько массивов. Ну, т.е. если у тебя матрица 4x4 то int[16] - это прям то что надо. Но когда в функцию надо передать произвольное число матриц, то int** будет кстати.
int** удобен, когда надо обрабатывать несколько массивов. Ну, т.е. если у тебя матрица 4x4 то int[16] - это прям то что надо. Но когда в функцию надо передать произвольное число матриц, то int** будет кстати.
Отличный комментарий!