да не ссорьтесь. все круты, - только каждый в своей сфере, а выяснять отношения - это както не по пацански.
эх, не оправдал надежд, что там в винде всего? Virtualalloc оболочка над Nt сервисным вызовом который и уходит потихоньку в native процессора, это уровень страниц, а хип это списки небольших участков памяти, связанные списки, а new это перегружаемый оператор по дефолту тянущий CRT. Ну усложнили в десятке архитектуру горизонтально, а вертикаль как было нт так и осталась по брльшому счету. Даже адреса шаред мемори в 10 никуда не сдвинулись и структуры peb/teb обратно совместимы. Браза, давай набирайся сил, а то проснёшься однажды с белорусским паспортом, возьмешь картонку и пойдешь к метро, где со старого смартфона будешь клацать по разбитому экрану в логин пагу васма вбивая ник инде.
im. для инициализации статических обьектов RTL заносит их адреса в CRT$LOL, а в них, если есть реги - заносятся деструкторы в atexit и тлс не пойму - в чём смысл? если отработать класс - то он весь ваш
не ссорьтесь, ктото знает много, ктото меньше, а есть ещё малята, которые хотят научиться, а не быть быдлом вроде джаваговнокодеров. кто их пригреет с еишными вопросами, кроме нас? так что - это наша задача - воспитать новое поколение
Ритуальные дебаты на васме, классика. Хотел сказать для того, чтобы ты сидел и не давало покоя, слом шаблонов заставляющий активировать внимание. Я конечно мало разбираюсь в программинге, просто хотел прояснить, что на васме люди в теме того, как что устроено и как работают либы.
SadKo, ну а что дешевле, нанять школьника, который за неделю все наговнякает на существующем фреймворке, или тебя, чтобы ты первые два месяца только свои библиотеки писал?
Да тут был вопрос скорей в плоскости как "для души" что-нибудь ваять, но про быдлоджавагавнокодеров ему все равно уже разъяснили
При всех своих плюсах работа в одно лицо все же имеет свои минусы Код пишешь только ты. Чтобы проект развивался - нужно работать именно тебе, тратить именно твое время (в отличие от сторонних решений). У сторонних решений есть комьюнити. Их пишет обычно больше одного человека. Они, в отличие от тебя, пишут документацию Они друг друга проверяют. У них есть пользователи, которые находят баги и жалуются на них, и баги исправляются.
Хочет комьюнити чтоб гнулинуксообразно все было и получается радар. Для чего этот радар такой нужен, они знают, а ты даже стараясь представить себе не можешь. Или хочет комьюнити tesseract'а использовать временные файлы или подключить гориллиард ненужных библиотек, и не видят в этом ничего дурного, а тебе это не подходит категорически. И так далее. Как бы смысл есть делать что-то в одно лицо, но не экономический.
f13nd, далеко не все можно потянуть самому. Но тем не менее - не совсем ясно в чем проблема. Библиотек и фреймворков становится все больше, а следовательно - становится больше выбор. Вроде бы надо радоваться? Или кто-то кого-то насильно заставляет писать приложение на PHP + AngularJS?
Так я с этого и начал, что это цивилизация, она так работает и никуда от мейнстрима не денешься. Запереться в келье на пару лет и монашить по-черному никто не запрещает, но ты оттуда сам вылезешь когда жрать охота станет.
Так интересно послушать\почитать спецов.. правда не чё не понял.. но очень интересно ((: Что касаемо жабы.. знаю, что "она" забралась в промышленность. Звучит гордо, но по сути штампуют ПО для касс.. Питерские чуваки пилят билд уже который год. Не скажу, что бы они сильно переживали о нем. Бабки платят, маятник жизни качается, все рады. Про безопасность стоит только догадываться.. но касса точно должна иметь связь с сетью, для передачи онлайн, данных, прямиком в налоговую .
А мне довелось работать с советским долгостроем в рамках прошлого проекта. По протоколу SOAP надо было запрашивать данные о грузах и класть в блокчейн. Система была написана на делфи, ее разрабатывали 10 лет. Вспоминаю об этом с содроганием. Над этой системой было бы неплохо сделать GraphQL-прослойку, которая предоставляла бы современный интерфейс к советскому легаси, но никто не будет эти заниматься.
--- Сообщение объединено, 7 май 2019 --- я бы хотел прислушаться к Инде, но он сам всё умножает на 0 в спорах, которые этого не стоят. --- Сообщение объединено, 7 май 2019 --- а что качается f13nd - то вау, не ожидал от него таких познаний, коими обладает
иными словами - не понимаю, чем руководствуется Инде, отвечая на ту или иную тему, но складывается впечатление что при этом он старается впихнуть невпихуемое, которое одновременно и не уходит далее контекста но и одновременно слишком глубоко и тащемта не рассматривается.
Ну тут вопрос двойственный: что выгоднее - нанять низкоквалифицированный персонал, сваять продукт за 5 минут, а потом иметь геморрой с его поддержкой и развитием, либо сразу делать всё аккуратно, но дольше и дороже по времени? Практика показывает, что в краткосрочной перспективе первое побеждает. Но в долгосрочной перспективе, по сути, рано или поздно настанет момент, когда вся система начнёт сыпаться, и её придётся перепроектировать с нуля. В финансовом плане краткосрочный подход так же проиграет, так как придётся ещё и тянуть бремя совместимости с прежним продуктом, что далеко не всегда просто. Кстати говоря, почему-то мысли о том, что в процессе эксплуатации и развития такую систему необходимо постоянно модернизировать, редко посещают манагеров, и они не закладывают время и ресурсы на это, пока вся система не складывается как карточный домик. В итоге имеем продукт, имеющий адскую реализацию под капотом, но вся команда уже ничего с этим не может сделать, так как, по сути, переделывать надо всё. --- Сообщение объединено, 8 май 2019 --- Здесь снова всё упирается в те или иные особенности языка. Кстати, джависты теперь всё меньше и меньше котируют Java, а потихоньку переходят на новомодный Kotlin, который, похоже, проектируют, как раз, по "краткосрочной" стратегии. У меня, кстати, относительно C++ тоже много критики. Например, не нравится большое желание отдельных особей погружаться в дикое метапрограммирование, в результате чего рождаются библиотеки, состоящие чуть менее чем на 100% из многоэтажных шаблонов, при этом несущих мало пользы. Фишка же Java в том, что меньше геморроя с написанием переносимых приложений, а также менеджментом памяти, поэтому платформа и стала такой популярной. Ну и всякие плюшки типа рефлексии активно стимулируют писать очередной мега-фреймворк, который "решит все ваши проблемы с сериализацией". Ну так и фишка в том, что это библиотеки, а не фреймворки. Вы берёте хорошо документированный программный интерфейс и пользуете, как вам угодно. Если что-то не получается, у этих библиотек есть доступный исходный код, и можно залезть внутрь и посмотреть, что выходит не так. Но учитывая то, что к библиотеке обращается непосредственно ваш код, поведение системы становится вполне предсказуемым. В случае с фреймворком всё иначе: вы инжектите ваш код в какое-то одному фреймворку известное окружение, а при каких условиях управление ему будет передано - это уже зависит не от вас. Лично для меня стектрейс из более чем 20 вызовов функций (при условии нерекурсивности алгоритма) - уже повод подумать о том, не слишком ли много слоёв абстракции задействовано при решении той или иной задачи. В случае со Spring же мы имеем портянки по несколько экранов, и они начинаются не с вашего кода, и заканчиваются не вашим кодом. А у вас от силы одна-две функции работают где-то там в середине. Иными словами: нихрена непонятно и непредсказуемо, если нужно разобраться в сути возникшей проблемы. --- Сообщение объединено, 8 май 2019 --- Ну примерно так и получается. Только совесть и опыт смотрят на это всё и плачут кровавыми слезами. Хорошо хоть есть возможность отвлекаться на свои проекты, иначе бы точно на стену полез.
