Не осиливаю сокеты Беркли

В современном мире сокеты - прежде всего программный интерфейс. То, что сокет еще и тип файла в Unix - это дело десятое. Не во всех ОС это так.

Да, да конечно. Только по моему надо учиться так, чтоб можно было поменять инструмент.

• Сначала абстракция ОС - виртуальная машина.
• Потом абстракция Потока байтов.
• Потом абстракция Процесса в ОС: изолированная память.
• Потом взаимодействие между Процессами.
• Потом Сети: Взаимодействие между процессами на разных хостах.
• Потом GUI как вишенка на торте.

А не с ног на голову. Сначала Qt, а потом непонятно, что такое Socket. Ваше «дело десятое» приводит к том, что мы читаем в теме у ТС.

Не надо тут умничать.

Давайте внятно выражаться в темах для новичков. «В STL нет сокетов» - это равноценно выражения «В Python SQL нет файлов».

P.S.

В библиотеке структур данных файлов быть и не должно. Файлы - внешний носитель. Структуры Данных - организация информации в RAM.

Как тогда они будут понимать код?

Никак. Они будут пихать текст задачи в чатгпт, применять результат, потом скармливать чатгпт получившиеся ошибки и просить их исправить. И так по кругу.

Даже не так, нафиг они тогда нужны?

Программисты смертны, хуже того, они внезапно смертны… Бизнесу нужно их кем-то заменять, желательно молодыми которым можно будет объяснить почему им будут платить мало.

Неужели Столяров этому не учит?

Почитайте оглавление. Там написано.

• Прежде чем «отвязываться от платформы» хорошо бы хоть примерно представлять, что такое платформа.
• Прежде чем начинать писать на С++ 11, хорошо бы научиться писать на Си.

Тут человек впухает с таблицей умножения, а вы «блатуете» тригонометрией. Кросплатформенный многопоточный подход - это как раз то что необходимо знатоку «изучающему сокеты», но уже «знающему» SQL, STL и АБВГДЖЗЛ.

P.S.

«Знаток» асинхронности/многопоточности не понимает сокеты. Это говорит о жирнющем синдроме Даннинга-Крюгера, он даже не понимает, что он не понимает. Многопоточность он изучил, а базовый примитив взаимодействия между процессами понять не может.

В Техникум, в Техникум, на первый курс. И прилежно конспектировать.

P.P.S.

ТС вознамерился работать С++ разработчиком без базы которая требуется NodeJS Junior. Вместо того, чтоб дать ему базовый курс вроде Столяра или Курячего с Маслинским. Начинается жонглирование С++ 11/STL/Qt - инструментами которые просто чтоб понять надо долго практиковаться в написании кода.

Какой может быть Qt, когда CLI не освоен? - это риторический вопрос. Такой Qt может быть только как самодеятельность на городской олимпиаде, но не как боевая разработка.

Столяр - он ничего сверх естественного не дает. Он за 20 лет детально отработал алгоритм обучения и на практике убедился: что и когда понимает ученик.

• ООП - невозможно объяснить пока не будет написано определенное количество процедур.
• STL - невозможно объяснить пока «от руки» не будет «нарисовано» определенное количество Linked List, BST и Trie.
• Сокеты - непонятны пока не будут объяснены Файловые Дескрипторы и Потоки.

И так далее и тому подобное. Он просто предлагает оптимальный путь обучения банальностям. Если очень некогда и есть большой практический опыт «формошлепства» - можно взять методичку 2006 года, там 3000 страниц ужаты примерно до 300 страниц, плюс минус.

Но трехтомник - подробней и больше тем затронуто, включая Big O Notation.

Попробуй сделать mozgon

Самое последние я скажу, и пойду уже.

Устроится на работу - не сложно. Сложно там удержаться, и работать без стресса и выгорания. «Спихнуться» на второсортную галеру пройдя формальный опрос не так сложно, а вот потом ходить на разбор к «начальнику» - в это психологически сложно.

А чтоб не было стресса, выгорания, перегрузок, срывов - то всего навсего надо получить соответствующие образование. Можно формально, можно не формально. Главное получить, а это OSI, Big O Notation, что там у нас еще? В общем глядите программу Техникума - как базовый минимум, её составляли не с бодуна и составляли люди компетентные.

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

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

сокеты Беркли

Что-то на неандертальском.

Ты C++ видел? Сколько сигнатур оператора delete ты знаешь? Сколько раз происходит аллокация при создании std::promise? А при создании std::future?

https://beej.us/guide/bgnet/

Вот тебе про TCP и UDP сокеты.

stl библиотека шаблонов, а не структур данных. В названии же сказато!

OSI

Спорно.

Ну да, там ещё и алгоритмы есть

@bezmozgoff

Т.е. если взять технического специалиста и эксперта в своей области и физически исключить из процесса, то сопровождение «mission imposible»? А как же DevOps?! Если серьезно, техника технологии же позволяет с серьезным лицом не совершать фатальных ошибок. Приведу пример, если взять финансового специалиста в учётной отрасли: бухгалтер и через два года учёта и сданной отчётности: физически исключить, то «превратиться в тыкву»? Ведь это не правда, ведь правда? Отсюда, субъективно делаю вывод, что описание с самых извращённых и изощренных формах с максимальными «переигрываниями» ситуации: обычная «галера» за еду. Не претендую на истину, что бизнес диктует как он диктует и везде по разному: ровно как и то, что таки условия труда и организацию работодателем в демократической стране сотворили и привели сами участники процесса. Без наездов и озвучил мнение. Спорить не собираюсь. Хорошего настроения в первую рабочую пятницу 2026 года.

Говорят, изменял Адам. Ну, а почему тогда говорят, что человек от обезьяны произошёл?

Windows and COM-object, LUKE! too

А чего там невозможно объяснить то? ООП даже педивикия описывает достаточно просто. Ты просто исключаешь червей из возможного варианта событий, а это как раз тот случай когда надо не просто запоминать тупо чушь всякую как гуманитарии делают на какой-нибудь истории искусств, а шевелить мозгами - процесс весьма похожий с доставанием из ячеек памяти с сопоставлением с наблюдаемым явлением в попытке понять что же делать например. У него не работают мозги - в этом все дело. Ты даже если объяснишь ослу что он осел ничего не изменится. Это попытка середнячка в лучшем случае запустить свои мозги, но это достояние лучших и вот тут то все и начинает его плющить. Прочитать книжки и освоить их самому 5 лет? Ты уверен что ты станешь сидеть над несколькими простыми книжками про упрощенную фиготень на компе с отставанием от нашего времени на десятилетия? Это ведь почти уровень книжку ну хотя бы за месяц. Это не иностранный язык в корне отличающийся по структуре и словарному составу учить. Дебилам это сложно делать. Просто они знают что есть спрос на умных людей, но сами то они дебилы и это так просто не отменить. Их всю жизнь пичкали калом для искривления мозгов, так может это даже не их заслуга что они отупели в корень. Ты должен оценивать собеседника, хотя ты и сам порой чушь порешь и стараться внятно выражаться. Я думаю он тебя даже близко не понял, точнее перепонять пытался. Вот и тут можно объяснить как есть без объяснения причинно-следственной связи как это делается обычно, а можно внятно изложить и скорее всего там 90% воды для особо тупых умственно отсталых дегенератов, которых всеми силами тянут, потому что они упорные. 300 страниц это выжимка для тех кто не хочет мозг насиловать и у них все в порядке для быстрого старта хотя бы. Правда есть умные люди, но ты их похоже никогда не встречал. И все вокруг вдруг тупые, потому что с твоими представлениями не совпадают, а они у тебя понятное дело претендуют на истину в последней инстанции. И вот тут возникают сомнения в том что ты достаточно умный. Видишь как все внезапно оборачивается? То что с тобой не хотят разговаривать те кто умеет программировать чья проблема? Хотя Обезьян исключение, он наверное добрый. Опять не твоя заслуга в интересности.

stl библиотека шаблонов, а не структур данных. В названии же сказато!

В данном УПРОЩЕННОМ случае - это синонимы. В STL описаны шаблоны базовых структур данных: списков и деревьев. Структура Данных называется - контейнер, Итератор - инструмент получения результата алгоритма обхода (упрощенно).

На самом деле библиотека трех компонентная: «Структуры», «Алгоритмы», «Обертки» (Контейнеры и Итераторы). Но чтоб дойти до такого уровня ОБОБЩЕНИЯ, надо научиться понимать/работать с классическими Алгоритмами и Структурами Данных. Понимать - какой сервис предоставляют контейнеры и итераторы, что именно они автоматизируют.

Если тебе прям совсем с основ, то почитай книгу Компьютерные сети Первый шаг - Уэнделл Одом. Там простым языком с самого простого уровня.

Если тебе именно работать с нами на C++ нужно научиться, то в зависимости от той ваканчии, на которую ты претендуешь, либо документация от Qt и соответственно QTcpServer/QTcpSocket/QUdpSocket либо Boost.Asio и соответствующие статьи и примеры.

Чтобы хорошо понять как работать с этим всем, хорошо бы все это попробовать самому.

Спорно.

Очередной IT-плоскоземельщик спорящий с практическим применением модели OSI.

stl библиотека шаблонов

Шаблонов в терминах C++. А вот уже на этих шаблонах в стандартной библиотеке (правильно так, а не stl) там реализованы алгоритмы, структуры данных и прочий функционал.

Привет https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html

wikipedia, kernel.org, lwn, тот же github примеров тьма. сейчас не начало 00-х. Выучить можешь гимн, а проблема (как мне кажется) в том «как приложить, что бы понять что это беркли, что это сокеты и оно работает»

Ну я вот сейчас в автошколе учусь, там 800 карточек с задачами. Когда ответ неправильный – разбираюсь почему, и в следующий раз даю правильный. Постепенно так и изучу. Так-то есть только один способ что-то изучить – фидбек-луп с реальностью. Зубрить без попыток применить (по сути принять какое-то решения) нет никакого смысла.

У Вас инструктор есть и препод по теории. ;-D ТС ну спросил и спросил, лишь бы взрослые дядьки мозги ерундой не забивали пока друг дружке доказывают у кого больше и складывали себе за это плюсики в кружку за количество постов.

У Вас инструктор есть и препод по теории

Но пока сам с задачей не столкнешься – в одно ухо влетает, из другого вылетает, я к этому

Бизнесу нужно их кем-то заменять, желательно молодыми которым можно будет объяснить почему им будут платить мало.

Тут мы приходим к социальному закону: процент программистов в социуме не меняется с середины 90ых.

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

Само понятие «Бизнес» - растяжимое, для функционирования офиса требуется эникейщик с навыками скриптинга, а не программист. Полноценный Техникум это уже «Яндекс», вот там нужны люди с фактическим освоением программы техникума.

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

• Программист - значит надо программирование 09.02.03 ПРОГРАММИРОВАНИЕ В КОМПЬЮТЕРНЫХ СИСТЕМАХ.
• Сетевик - значит надо специальность по сетям.
• Электронщик - иди конкретно на электронику.

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

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

Образование - это образование. До LOR я думал, что можно быть «самоучкой», как показала практика общения - нельзя. Требуется систематический фундамент. И, важно, именно фундамент конкретно под направление деятельности: электронщик спорящий о высокоуровневом программировании ставит себя в глупое положение, он не знает азов и додумывает.

Полностью согласен, без проблем.

А как же DevOps?!

Как показала практика в командах опытных программистов с системным архитектором девопсы не нужны. Они обитают либо там где IaaS, либо в галерах за еду/програмисты на уровне джуно-мидлов/нет архитекта.

Зачем нужен девопс там где архитектор уже выстроил полностью автоматизированный пайплайн, что ему делать? Наличие девопсов в не IaaS всегда означает косяки в архитектуре, которые они и призваны героически закрывать. Такова суровая реальность.

А над снижением bus factor обычно работают продакт, тимлид и архитект, каждый со своей стороны.

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

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

Вам также хорошего настроения.

Продолжу рассуждения.

1. Образование как база и территория.

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

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

2. Век живи - Век учись!

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

«эффективное управление бизнес процессами в ERP, это понимание что бизнес процессов нет» (с) Про DevOps была попытка тонкого пошутить, что иногда желаемое за действительное пытаются выдавать. Что не всегда ни всегда нужны какие-то инструменты: был бы толк (технологичность, обратная совместимость и перспектива). Про бухгалтера, не обижайте их: help tips в интерфейсе с рассылками не спасут Вас от экспертизы грядущих изменений по фронтам и положения дел в буховском деле (например, Вы же общаетесь с коллегами по каким-то вопросам?). Про бизнес процессы отдельная песня и не относится к данной теме и теме площадки.

Про бухгалтера, не обижайте их:

Ни в коем случае. Отдал 10 лет жизни комплексной автоматизации предприятий и бухгалтерий в том числе. Я не умоляю их работы, просто пытался объяснить что в современных реалиях bus factor одного бухгалтера больше не равен единице.

help tips в интерфейсе с рассылками не спасут Вас от экспертизы грядущих изменений по фронтам и положения дел в буховском деле

Шестой год работаю в качестве ИП на международном рынке в условиях санкций, бухгалтерию веду сам, пережил как-то все изменения, камеральные проверки без штрафов и претензий со стороны налоговой. Лет 10 назад бухгалтер был просто необходим для такой деятельности, теперь нет. Времена меняются.

DevOps - это странный термин, изначально в Google были инженеры ответственные за бесперебойную работу сервисов. В задачи которых входила автоматизация и анализ ситуации - термит SRE, где-то там была создана концепция совместной работы двух команд: разработки и поддержки, при этом спецы были взаимозаменяемы.

Дальше термин ушел в народ, и сейчас под DevOps понимается PowerUser который умеет настраивать фреймворки тестирования.

Услышал, написал так из наблюдений уполномочек и отслеживания стыков бух, производства и ит. Обычный наёмный. Единственное, что хотел все таки подметить: думаю, все справедливо написанное может быть применимо в плоскости масштаба. - Маленькие детки, - маленькие бедки.

Да, сейчас DevOps это каргокульт не имеющий ничгео общего с инженерами. Эникеи не могли стать программистами, но очень хотели получать как они, в итоге они начали усиленно обрастать ненужной инфраструктурой и «программировать» файлы настроек этой самой инфраструктуры.

Маленькие детки, - маленькие бедки.

Вы абсолютно правы, по уровню бух отчетности ИП не сравнится с ООО с сотрудниками. Но там и не один бухгалтер работает обычно, те там уже нет единой точки отказа. Благодаря автоматизации и реформе налоговой те времена прошли.

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

По сокетам почитай какую-нибудь классику, типа Стивенса или Рочкинда. Лучше в оригинале - может быть очень плохой перевод. Не знаю, как с этим сейчас дело обстоит, но в мое время в книгах запросто можно было встретить «доменные гнезда Unix» вместо Unix domain sockets.

По сокетам почитай какую-нибудь классику, типа Стивенса…

Stevens&Rago - прекрасная книга для состоявшегося инженера. Для студента в 1000 раз лучше Таненбаум или Столяров. Так как и Таненбаум и Столяров пишут живые тексты в публицистической манере.

Изображение из Таненбаума: Интефейсы в ОС.

Я отвечал на это:

В библиотеке структур данных файлов быть и не должно.

А речь шла о «файлах»-сокетах.

Что должно быть, а чего быть не должно в stl — вопрос интересный, конечно.

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

Зачем мне учиться на намёках?

Я склоняюсь к такому мнению: Для некоторой задачи я буду использовать подходящие технологии. Не связывая себя тем, на каком «слое» находится TCP и сколько слоёв куда и в каком протоколе зажали. Не раздумывая, какой сейчас «слой» я реализую. Зачем забивать себе голову вопросами, не имеющими отношения к предметной области? Пофилософствовать?

Возможно, в твоём сообщении противоречие.

Мои рассуждение не против самообразование, а против отсутствия базового системного образование.

То есть «базовое системное образование необходимо», что в контексте темы можно интерпретировать как «убережет от ошибок незнания незнания».

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

Кажется, это подразумевает базовое системное образование?.. Уж парочку программ на це-пе-пе он написал?

Но у него нет инженерно-технического образования,

Эээээээ…… [невнятно мычу] Чё надо-то чтоб уметь программы писать? На кого учиться-то? На программиста программ? На техника-инженера? На слесаря? На учителя истории?

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

То есть его не спасли общие знания в целом и глубокия знания в частностях от незнания незнания?

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

так а где я не прав? практически все наследуется от QWidget, хотя могу и ошибатся

от QObject

Если ты имеешь ввиду «есть ли что ещё для UI кроме qml/widgets», то нет. Ну конечно придирчивый человек может ещё назвать Qt WebEngine, но это больше вспомогательно для первых двух.