выбор языка неудачный.

Меня смущает что gloox нужно устанавливать.

А что в этом плохого?

Либо устанавливать библиотеки gloox'a на сервер, либо вконпелять его статически в бинарник. Так же можно поступать с любыми недефолтными библиотеками, если нету возможности их установить.
И еще посмотри в сторону питона и xmppy, например.

Выбор языка обусловлен желанием выучить его. На Perl такие вещи уже делал.

Либо устанавливать библиотеки gloox'a на сервер, либо вконпелять его статически в бинарник.

О вот можно об этом поподробнее? Это указывается флагами для g++? Где прочитать об этом?

Почитать можно в man gcc/g++/ld. Ключик --static собирает статически все что может.
Чтобы впихнуть одну-единственную библиотеку, достаточно указать ее статическую версию, gcc bin.out libexample.a

Спасибо, думаю дальше разберусь.

gloox rip причем окончательно, лучше уж тогда jreen юзать

jreen в зависимостях x11 тащит.

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

чт омешает форкнуть и внести необходимые патчи ??

jreen в зависимостях x11 тащит.

он тянет QtCore, иксы ему вроде как не нужны

$ ldd ./libjreen.so.1.1.0 
	linux-vdso.so.1 =>  (0x00007fff2a4be000)
	libQtNetwork.so.4 => /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4 (0x00007f52a66df000)
	libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007f52a6211000)
	libqca.so.2 => /usr/lib/x86_64-linux-gnu/libqca.so.2 (0x00007f52a5f17000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f52a5d00000)
	libspeex.so.1 => /usr/lib/x86_64-linux-gnu/libspeex.so.1 (0x00007f52a5ae7000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f52a57e2000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f52a55cc000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f52a520f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f52a4ff1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f52a4ded000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f52a4be5000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f52a48ef000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f52a45f5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f52a6d9a000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f52a43b7000)

и QtNetwork еще, иксов нет

Ещё один? А чего не на питоне?

Может то, что ТС таки новичек для таких действий? А со jreen'ом всегда можно с вопросами ко мне обратиться или в конфу кутима.

Не тянет, и пара кутимовских ботов на jreen'е и написана!

Угу. Было дело...

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

В своё время делал подобное в целях удалённого управления и лёгкого скрытного администрирования. Правда, на С.

Пните в нужном направление.

Кхм... Направлений тут несколько. Во-первых, для нормальной работы бота нужно внимательно ознакомиться с http://wiki.xmpp.org/web/Programming_Jabber_Clients

Важно обратить внимание на то, что сам по себе поток сообщений от бота и к боту это XML. Организация приведена в ссылке выше. Дело в том, что либо Вам придётся парсить и создавать сообщения либо самому («врукопашную»), либо используя libxml2/expat... Это первая зависимость. В случае, если будете сами напрямую работать с XML, то её можно избежать, но для начала не рекомендую морочиться.

Во-вторых, бота можно реализовать по открытому протоколу (порт 5222, согласно RFC 3920). Но это действительно не интересно. Лучше использовать SASL/TLS для того, чтобы закрыть протокол и не смущать админов. Дело в том, что все предполагают что новые клиенты xmpp работают по закрытому протоколу, на «неофициальном» порту 5223 (на порту 5222 любой дятел со сниффером наперевес, находящийся в том же домене коллизий что и Ваш бот, спалит и его наличие и поток команд-откликов). Так что, вторая зависимость, это поддержка протокола TLS/SASL.

Или что лучше подойдет для моих целей?

Если на «попробовать», то я бы рекомендовал начать с уже проделанной работы. Т.е., для начала, берите библиотеку (ту же loudmouth или iksemel — вот это вообще на голом С и ни кого это не обламывает) и пробуйте просто зарегистрироваться на сервере. Ну и дальше по Вашему списку (что Вы хотите получить от бота). Список доступных и работоспособных библиотек здесь. Разберитесь с сущностями — например каким образом xmpp-клиент на одной учётной записи, на одном сервере, может иметь произвольное число подключений с разных машин. Прочтите RFC 3920, вики по ссылке выше.

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

P.S. Чуть не забыл — забейте на советчиков, рекомендующих сменить язык. В ответ смело рекомендуйте поменять ориентацию.

Собственно написать бота и решил, чтобы попрактиковаться.

Всё верно. Заодно и с сетевым программированием разберётесь. Будут вопросы — задавайте, помогу чем смогу.

В гугле забанили?

ты около года будешь вылизывать либу реализующую XMPP

Хоть уже и написал, но повторю...

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

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

А подробнее можно? Что такого есть в перле/питоне/руби чего нельзя сделать или неоправданно долго делать на С++?

RFC 3920 я уже сам нашёл, а про библиотеки и шифрование не знал. Спасибо за информацию.

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

Есть в крестах и высокоуровневые библиотеки: stl, loki и boost, например. Но применять их без хорошего понимания, как работают шаблоны невозможно. (Хотя stl довольно таки user-friendly, тонкостей там хватает. В boost вообще чёрт ногу сломит).

В общем, делать неоправданно долго (либо исхитряясь так, что 70% кодеров тебя не поймёт) и аккуратно на C++ нужно практически всё.

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

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

Так я на перле с сетью работал, пакетными сокетами, форками, пайпами, сигналами от ОС... На java тоже опыт программирования имеется. Сколько можно эти матрицы умножать на каждом ЯП который начинаешь учить.)

В C/С++ крайне муторная и опасная работа с памятью. И для начала хорошо бы представить размер проблемы: сначала просто наступить на грабли, а потом уже лезть в тёмный сарай с сельхозпринадлежностями. Вот я и рекомендую повозиться с матрицами: сделать их через указатели, затем через stl.

Понятно. Да думаю в этом есть смысл. Спасибо за совет.

Хватит уже повторять как попка всякую чушь.

Попка (твоя?) повторяет всякую чушь?

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

А что плохого в конструкторах?

Я имел в виду работу с голой памятью вообще. Иногда это необходимое зло, но чаще всего ненужно.

В C++ оно тоже не нужно, есть RAII и ссылки.

Умные указатели спешат на помощь.

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

Они довольно медленные, увеличивают время компиляции и появились в стандартной библиотеке сравнительно недавно.

Ещё как нужно. Про ссылки я в курсе.

Медленные по сравнению с чем? С обычными указателями? Но ведь обычные не нужны, если верить тебе.

Или по сравнению с альтернативой в «годных» языках?

С обычными указателями?

Да.

Но ведь обычные не нужны

Я говорил, что обычные - та ещё гадость, но нужны.

Я говорил, что обычные - та ещё гадость, но нужны.

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

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

Итак, ты что ты там утверждаешь?

Ещё как нужно.

Только для использования с древнелибами на С. Но и это спокойно оборачивается.

Тебе оно не понравилось, ибо медленное.

Да не серебряная пуля это, а костыль. Дело не только в медленности, но и в количестве букв, например, которое нужно писать: Foo* и boost::shared_ptr<Foo>. А разыменование weak_ptr - это вообще комедия двух действиях. Велика вероятность, что в команде найдётся сишник, считающий себя самым умным, наляпает голых указателей и устроит сегфолт.

Я предложил тебе решение, которое сильно упрощает проблему,

Которое помогает заглотить кактус чуть поглубже.

Итак, ты что ты там утверждаешь?

Что плюсы - узкоспециальный язык.

Указателей я стараюсь избегать, но когда очень нужно - см. ответы выше. Ничего «крайне муторного и опасного» нет, разве что работать приходится с легасиговнокодом (мне приходится), да и то, слухи преувеличены.
Пусть меня закидают камнями, но для большинства вещей достаточно auto_ptr.

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

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

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

еще один «Чукча не читатель, чукча писатель».

Что, мне надо приводить избитые аналогии про то что гвозди можно забивать фрезерным станком? Инструмент надо подбирать под задачу. Никто не спорит что на плюсах можно написать что угодно, да хоть брейнфаке, но трудозатраты в сравнении с питоном не соизмеримы. Для конкретной задачи ТС.

Если ТС просит помощи по плюсам, какого хрена лезть с другими языками?

P.S. Чуть не забыл — забейте на советчиков, рекомендующих сменить язык. В ответ смело рекомендуйте поменять ориентацию.

можно использовать для чего угодно

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

Указателей я стараюсь избегать

ОП по собственному признанию писал только «hello world». Предлагаешь ему сразу начать со смартпоинтеров? Как вообще понять работу обёрток над указателями, не понимая, что есть голый указатель?

Так что моя фраза про сложность работы с памятью оправдана. Нужно либо работать с ней руками, что сложно, либо использовать сложные обёртки.