3) boost

4) мобильное приложение

Хотя, там хидер-онли, емнип. МОжно было просто код взять

5) самопальный optional 6) singleheader optional из интернетов, десяток их

7) кумыс

Есть имеющие опыт по resiprocate? Что происходит внутри SipStack::send(), отсылает ли он на самом деле сообщения или это очередная абстракция и нужно делать что-то еще? По докам непонятно (их почти нет). По коду сообщения просто по очередям гоняются, где доступ реальная работа с сокетами и отправка сообщений и есть ли она вообще - не пойму.

Есть имеющие опыт по resiprocate? Что происходит внутри SipStack::send(), отсылает ли он на самом деле сообщения или это очередная абстракция и нужно делать что-то еще? По докам непонятно (их почти нет). По коду сообщения просто по очередям гоняются, где доступ реальная работа с сокетами и отправка сообщений и есть ли она вообще - не пойму.

я не пойму твой вопрос

но у меня рабочий проект на нем и там все работает

https://github.com/resiprocate/sendsipmsg/blob/master/sendsipmsg.cxx - это не поможет тебе?

я не пойму твой вопрос

Например SipStack stack; stack.addTransport(TCP, 5060); NameAddr from("<sip:foo@192.168.64.100>"); NameAddr to("<sip:foo@172.217.16.46>"); auto registerMessage = *Helper::makeRegister(from, to); stack.send(registerMessage); После выполнения этого кода действительно выполняется попытка отправки сообщения с моего 5060 тср порта на адрес указанный в request-uri/to ?

Потому что если да, то мне tcpdump говорит что ничего не отправляется и я не знаю в чем проблема

Посмотри пример, который я скинул

Там пример отправки на уровне DUM, для отправки отдельного сообщения на уровне транзакции он разве обязателен? Или там что-то очевидное чего я не вижу/понимаю?

мне надо такое: class A{ B b; } class B { A a; }

Если тебе такое надо, то имеет место хуевый дизайн. Линейкой по пальцам автору оного:)

Например SipStack stack; stack.addTransport(TCP, 5060); NameAddr from("<sip:foo@192.168.64.100>"); NameAddr to("<sip:foo@172.217.16.46>"); auto registerMessage = *Helper::makeRegister(from, to); stack.send(registerMessage); После выполнения этого кода действительно выполняется попытка отправки сообщения с моего 5060 тср порта на адрес указанный в request-uri/to ?

а, хм, тут впринципе относительно протокола бред написан, да

Если тебе такое надо, то имеет место хуевый дизайн. Линейкой по пальцам автору оного:)

нет

так он работает только с указателями и ссылками

А тете что мало?

мне надо такое: class A{ B b; } class B { A a; }

а ты в голове представляешь layout этих классов?

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

Придумали, конечно

бле, так хотел избежать указателей - и на тебе

Именно: НА ТЕБЕ!

А тете что мало?

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

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

:) а ты часто кладешь папку в сумку, которую потом кладешь в эту же папку?

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

Такой же уже нет, не влезет...

можно попробовать std::optional

можно попробовать std::optional

std::optional<T> выделяет статически sizeof(T)+1

Ты уже опоздал, предлагали

да, вроде было выше

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

это optional<Briefcase> или vector<Briefcase> из твоего же "в А есть Б, а в Б есть А" получается "в чемодане всегда есть сумка, а в сумке всегда есть чемодан"

это optional<Briefcase> или vector<Briefcase> из твоего же "в А есть Б, а в Б есть А" получается "в чемодане всегда есть сумка, а в сумке всегда есть чемодан"

да, optional бы подошел

но я про него не додумался. А когда мне подсказали - я уже половину переписал на указатели

в общем ,для такого юзкейса нужно отношение агрегации, а class A {class B b; }; - это отношение композиции

но я про него не додумался. А когда мне подсказали - я уже половину переписал на указатели

переписывай обратно при случае, лучше раньше чем позже ;) https://github.com/martinmoene/optional-lite https://github.com/akrzemi1/Optional

но я про него не додумался. А когда мне подсказали - я уже половину переписал на указатели

По семантике optional равносилен указателю.

По семантике optional равносилен указателю.

но не по реализации, ему нужен полный тип

Я думаю, что в этом случае нет особого смысла переписывать на optional. Тем более еще и свой optional придется писать(взять готовый)

Если бы тебе подошёл optional, подошёл бы и указатель

взять готовый != писать свой, особенно когда готовый уже поимел много звёзд на гитхабе и публикаций на реддите

Я думаю, что в этом случае нет особого смысла переписывать на optional. Тем более еще и свой optional придется писать(взять готовый)

Я думаю что ты просто напросто не осознаешь до конца, что ты хочешь . Просто если бы ты осознавал, ты бы этого не хотел

По логике мне не сильно важно использовать там optional или указатель

other people's code is beautiful, not always in quality, but in terms that it is already there and covers things you might forgot in hurry (c)

Даже более того - мне это вообще все равно

Хм, а как optional расчитывает sizeof, если там рекурсия получается и sizeof не расчитать же?

Хм, а как optional расчитывает sizeof, если там рекурсия получается и sizeof не расчитать же?

так об этом и толковали всем, предлагавшим optional

ааа, я просто немного не уловил суть вашего разговора.

std::optional<T> выделяет статически sizeof(T)+1

хм, мб через него попробовать сделать Stack pimpl...

хм, мб через него попробовать сделать Stack pimpl...

Алекс, полный тип нужен

ага, ок, понял

Ну, самое главное, идея не ясна

Такого просто быть не может

так об этом и толковали всем, предлагавшим optional

к слову, sizeof+1 на стеке - это ведь и в бусте и в стд так? помню что принятые в стандарт куски буста отличаются от своей бустовой реализации, но плохо помню в чём

В чемодан нельзя положить другой такой же чемодан

Такого просто быть не может

ну смотри. У меня есть объект Book. У него может быть объект Review(а может и не быть). Есть объект Review - у него всегда есть объект Book, но этот Book всегда меньше по количеству полей, чем первый объект Book. Можно было ввести еще один ShortBook, но это была бы ебала.

В чемодан нельзя положить другой такой же чемодан

если у чемодана есть 3DSize габариты - то условно можно)

ну смотри. У меня есть объект Book. У него может быть объект Review(а может и не быть). Есть объект Review - у него всегда есть объект Book, но этот Book всегда меньше по количеству полей, чем первый объект Book. Можно было ввести еще один ShortBook, но это была бы ебала.

это просто отношение 0...*, которое в крестах эмулируется любым видом контейнера или пойнтера (если 0...1)

Вот я думал, что может придумали какой-нибудь воркэраунд для такого, что-то типа: Review { Book b:15байт }

ну смотри. У меня есть объект Book. У него может быть объект Review(а может и не быть). Есть объект Review - у него всегда есть объект Book, но этот Book всегда меньше по количеству полей, чем первый объект Book. Можно было ввести еще один ShortBook, но это была бы ебала.

Ну у тебя тут везде ассоциации. А ты хочешь использовать агрегацию.

Вот я думал, что может придумали какой-нибудь воркэраунд для такого, что-то типа: Review { Book b:15байт }

Это ты упёрся рогом в чистый воздух перед собой, а не воркэроунд нужен.

Агрегация не то что тебе нужно

Агрегация не то что тебе нужно

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

ну смотри. У меня есть объект Book. У него может быть объект Review(а может и не быть). Есть объект Review - у него всегда есть объект Book, но этот Book всегда меньше по количеству полей, чем первый объект Book. Можно было ввести еще один ShortBook, но это была бы ебала.

Книга не является частью рецензии на книгу, также как и рецензия не является составной частью книги (если только это не встроенная в книгу рецензия, но это должен был бы быть уже женой класс рецензии) При этом, заметь, ни одна, ни другая связи никак не влияют на время жизни этих объектов, они не управляют объектами.

Учитывая контекст - еще как являются

Но рецензия без книги - не нужна. А вот Книга без рецензии - обычное дело

ERROR: S client not available

Книга может быть без рецензии? Может.

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

в этом случае у тебя есть комбинация объектов, а класс (т.е. тип) у них один.

Рецензия без книги? Не может. Но книга не является частью рецензии поскольку на одну книгу может быть несколько рецензий

Рецензия без книги? Не может. Но книга не является частью рецензии поскольку на одну книгу может быть несколько рецензий

нет, рецензия будет только одна - моя.

Книга ее может содержать или нет, но если есть рецензия - то всегда на определенную книгу

Я вообще не понимаю, что мы тут обсуждаем

Твою предметную область

Ты её явно неверно понимаешь

нет, рецензия будет только одна - моя.

Почему нельзя написать вторую?

Нет, я ее верно понимаю, потому что мне ее такой отдают. Мне нет никакой необходимости городить ненужные конструкции, когда у меня уже есть готовый сформированный тип

Почему нельзя написать вторую?

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

Ну... Не, тебе конечно же виднее...

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

Я не могу. Другие то могут.

Я не могу. Другие то могут.

не могут.

тип есть юзер, у него есть рецензии

точнее могут, но я не могу получить чужую рецензию. Я получаю книгу и свою рецензию на ее

рецензии имеют в себе ID книги, текст

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

Это все круто, когда это надо хранить где-то

т.е. надо хранить не саму книгу, а ее идентификатор

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

и надо просто сделать пул книжек, на которые есть рецензии

Но я не храню, по сути, ничего

запрос-ответ-показ-удаление

ну, тебе только метаинфу надо хранить тогда: Книги ID, название Рецензии ID книги, текст рецензии

Ладно удачи подумай ещё

точнее могут, но я не могу получить чужую рецензию. Я получаю книгу и свою рецензию на ее

а это косяк в дизайне, рано или поздно другие заходят почитать не только свои рецензии

это не мне решать

мало того, своя рецензия меня меньше всего интересует

ну, сириосли

ладно, привет постановщику задачи