При чем тут стандарты кода? Вложенное тело без скобок - это грабли для того, кто будет править код, позволяющие легко и неочевидно его испортить. При этом в плюсах у этого, так сказать, стандарта - только экономия нескольких байт в исходниках и, возможно, одной строчки. То есть можно считать, что плюсов у него вовсе нет.
Даниил Демидко: лаконичность в С++ - это ни в коем случае не экономия символов!
Лаконичность в С++ - это создание дополнительного уровня черновой работы в классе, работу которого (класса) в алгоритме потом можно будет читать, как роман. Потому что весь очевидный код убран в методы, имеющие очевидные названия.
Дамир Синицын: я не возмущаюсь, я констатирую факт. Для решения задачи кросс-компиляции требуется понимание того, как вообще происходит компиляция приложения.
Вы этого понимания в вопросе не проявили, а на вполне добротную IDE наехали не по делу.
bitrixweb: хинт: создаем в корне диска папочку "classes", в ней - файл Useful.php. В нем прописываем класс Useful и каждый раз, когда приходится делать что-то подобное вот такой ерунде, добавляем в этот класс соответствующую функцию. Постепенно получите "швейцарский нож" для рутинных операций.
Андрей: ну, не обязательно присваивать класс самой ссылке. Достаточно, чтобы специальный класс был у материала, в котором встречаются такие ссылки, которые надо обрабатывать.
Андрей: добавьте таким ссылкам, для которых это будет работать, некий общий класс. Чтобы не было странностей, если вдруг на странице попадутся ссылки, которые не надо так обрабатывать.
bitrixweb: можно один раз написать функции json_encode_1251 и json_decode_1251 с рекурсивным обходом. Если так и не соберетесь перевести сайт на utf-8 - не придется велосипедить слишком часто.
Если человек даже не знает, что приложения "делает" не IDE, а компилятор - где ему с Эклипсой справиться?
Тем более, что она капризная, как сволочь - чуть фаза луны сменилась, и библиотечные файлы, лежащие ровно там же, где всегда, вдруг "could not be resolved".
Судя по "работе с формами" - даже не WinAPI... в общем, вообще непонятно, при чем здесь Убунту.
С какого перепугу в системе будет инструмент разработки приложений, прибитых гвоздями к другой системе?
Дмитрий: ну да, что-то я туплю - второй-то сайт не ваш.
Получается, вы пытаетесь сделать классический CSRF, от которого любой современный браузер защитит своего пользователя, не дав вам никаких шансов.
Дмитрий: JS позволяет залезть со страницы в дочерний фрейм.
HTTP везде, но одно дело - когда вы с сервера обращаетесь к сайту и POST-ом отдаете ему данные, другое - когда у вас в браузере пользователя открытым текстом используются логин и пароль (для заполнения формы).
romy4: Так ему надо не курлом на сайт войти, а пользователя туда перенаправить залогиненным. Дмитрий: может, с iframe поиграться? Загрузить в него страницу с формой, заполнить, отправить.
Потом уже перенаправлять пользователя на тот сайт. То, что данные авторизации будут светиться открытым текстом, вас, возможно, не пугает...
Curl-ом то он все это проэмулирует, но куки от того сайта в браузере сами собой не появятся и с этого сайта их не назначишь. Так что при переходе на тот сайт пользователь не будет залогинен.
