У меня такая проблема: Как сделать слово из частей или букв? Например если есть три переменные типа char s1='a', char s2 = 'b', char s3 = "c". Нужно что бы в Memo получилась строка вида "abc". Затем следущая строка с другим содержимым. Как вобще организовать вывод в Мемо любых символов друг за другом в строку или как сделать из нескольких переменных строку для вывода ее в Memo? Я пробовал использовать функцию strcat c с файлом string.h, но оно ваще не работает а строка была такая : strcat (s1,s2,s3) Не работает оно! Помогите плиз! Если не сложно то с комментариями

последний вариант у меня не работает! Ошибка

а через обычный плюс???

Что за ошибка?

Вот собственно прога с третим вариантом:

билдер указывает на строку char s[20];

надо поставить { перед char s[20]; тк функция начинается с {, а вы ее стерли   

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


К тому же не забывайте, что в Builder есть ещё целый ряд своих классов по типу AnsiString, UnicodeString и другие. Можете написать собственные классы. Можно на темплейтах соорудить что-нить. Можно написать универсальные функции или методы с неопределённым количесвтом параметров (...) и т.д. Проявите фантазию! Задача крайне элементарная и очень тривиальная!


А автору хочу сказать, что прежде чем паниковать и писать "Ааа! Не работает оно! Помогите!", надо сначала просто внимательно изучить документацию, благо её много! Книги Страуструпа, Шилда, Кернигана и Ритчи и т.п. К тому же есть сайтик полезный: http://www.cplusplus.com/
strcpy имеет два параметра, так же как и strcat (а вы передавали ей три, притом, вас не интересовало в какую область памяти будет происходить копирование и какие типы данных вы ей передаёте). Если бы поискали, обнаружили что есть ещё sstream. Там всё ещё проще! Человек не пытался читать документацию, а сразу полез на форум. На форуме помогают решить проблему. А ваша лень и невнимательность - это проблема, которую на форуме помочь решить не могут.

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

Это сообщение отредактировал(а) Bodro - 21.6.2012, 16:25

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


sizeof(char) - зачем? у вас много лишнего времени? sizeof(char) == 1 по определению.


А где      
        *(res + 3) = 0; 
Вот этого пропускать нельзя!
Иначе программка может напечатать вам роман Л.Толстого "Война и Мир", с последующим выпадением в осадок.


зачем (void) ?

Излишняя тщательность (граничащая с параноей),
И одновременно халатность, там где инициализация просто необходима.

Добавлено через 1 минуту и 39 секунд
Прошу прощения, за придирки. Что-то на меня нашло. Сорри.

Вы, судя по всему, не очень хорошо знаете язык.  Дело в том, что функция calloc эквивалентна вызову malloc и последующим memset с нулями. После вызова calloc все 4 байта будут нулями. Я понимаю, придраться хочется, но лучше, прежде чем придираться, попробовать собрать код и посмотреть на него в отладчике.

Например, тут описание calloc: http://www.cplusplus.com/reference/clibrary/cstdlib/calloc/
Тут malloc: http://www.cplusplus.com/reference/clibrary/cstdlib/malloc/
Тут memset: http://www.cplusplus.com/reference/clibrary/cstring/memset/

Аналог кода с calloc можно написать так (malloc и memset):

По поводу (void) перед функциями, возвращающими значение. Дело в том, что некоторые компиляторы (например компилятор для процессоров на ядре SH4) сильно ругаются на это. Так же ругаться может gcc. По-стандарту, мы обязаны обработать значение, которое возвращает функция. Если мы этого не делаем, то должны явно указать что мы не собираемся использовать возвращающий результат. Борланду плевать на это, а другие компиляторы могут ругаться. Во многих библиотеках есть специальные макросы для этого, например, макрос в Qt: Q_UNUSED. Если вам не нравится (void) (иногда есть ситуации, когда компилятор ругается на (void), только несколько другими сообщениями - такое тоже может быть), можете использовать в С99 или в С++ такую функцию:

Всегда старайтесь писать код, чтобы при включённой опции компилятора -Wall или аналогичной полностью отсутствовали предупреждения.

По поводу излишней инициализации. Открываем книгу ISBN 5-8459-0226-6, глава 27. Читаем полностью. Это, конечно, касается не C++, а C, но сути это не меняет. Герберт Шилдт очень хорошо описал правила проектировки программ на C. В том числе и о неоходимости явной инициализации локальных переменных.

По поводу 0 вместо NULL. Читаем тут: ISBN 978-5-7989-0425-9 параграф 5.1.1. Это Б.Страуструп.

Теперь по поводу sizeof(char) == 1 по-определению. Скажите мне, по какому такому определению? Лично я никогда не сталкивался с тем, что sizeof(char) больше 1, но это не означает что такого не может быть. Посмотрите на другие типы данных - int, long, long long, short. Они какие должны быть по-определению? Они от машины к машине, от компилятора к компилятору могут быть совершенно разные! В таких случаях лучше использовать stdint для явного указания размера. Это раз. А второе, указание sizeof(char) явно говорит человеку, читающему программу, что мы не просто выделяем какой-то блок данных, а что мы выделяем его именно для 4 символов. В данном случае это, конечно, не столь важно - пример крайне простой, но вот в более сложном и громозком коде это может существенно облегчить чтение и понимание программы. Скажем так, это просто хороший стиль написания. Хотя я не исключаю наличие систем с sizeof(char) отличным от 1. Споры затевать не надо на эту тему - свою позицию я объяснил.

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

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

Так же заметил, что в func8 перед printf забыл поставить (void).


Вы согласны со мной?

Это сообщение отредактировал(а) Bodro - 23.6.2012, 16:23

Bodro, по поводу calloc, и инициализации нулями, да вы правы.

Очень рад что наш разговор заставил вас заглянуть в стандарт C++11, к сожалению, в настоящее время мало кем поддерживаемым (я знаком только с gcc кто более или менее в полной мере его поддерживает). Больше, я так понимаю, добавить вам нечего?

Но по поводу стандарта вы совершенно правы - char не меняется ни в C ни в C++. Занимает ровно 1 байт. Он прописан во всех стандартах. Про sizeof(char) я уже написал достаточно - дело не только в стандарте, но ещё и в читабельности кода. К тому же, если вы опытный программист, то должны знать, что стандарт не поддерживает полностью практически ни один компилятор. Я уже об этом говорил, что я не встречал систему, где char занимал бы более чем 1 байт. Но это ни в коей мере не говорит о том что такого не может быть! Это просто хороший стиль написания кода! Если вы с ним не согласны - не используйте его - пишите просто 1. Никто вас не неволит - не вижу тут никакой ошибки.

Вот в каждом форуме найдётся человек, который домотается до мелочей, а про суть ничего не скажет. Вам просто надо было показать что вы тоже многое знаете? Показали? Молодец. Я не сомневался что вы умный и талантливый человек. Я видел ваши ответы - очень грамотные и чёткие. Но, вместо того, чтобы искать соринки в моём коде (я так понимаю, мы выяснили что их там нет), лучше бы написали ещё в с десятка два примеров как реализовать конкатеницию символов. Это было б куда полезнее, чем пытаться развести тут холивар. К тому же, судя по всему, вы хорошо знаете C++11 - вот и привели бы примеры с замыканиями и лямбдой.

Если вам хочется всё же продолжить данную тему, предлагаю перенести её в нашу личную беседу посредством личных сообщений. Но для начала вы попробуйте собрать представленный мной код на любой платформе и на любом компиляторе. Если будут проблемы - что-то упадёт или что-то не заработает - пишите! Буду рад обсудить с вами реальную интересную задачу. А тратить время на пустую болтовню считаю бессмысленной затеей. Вы, разве, не согласны?
Предлагаю просто закрыть тему! К тому же ей уже 4 года! Я написал несколько примеров рабочего кода, проверил их. Код работает. Думаю, это главное для решения задачи.

Модератор, для предотвращения холивара - закрывай тему. 

Это сообщение отредактировал(а) Bodro - 24.6.2012, 00:14

Ну собственно в стандарте ISO/IEC 14882:1998, ISO/IEC 14882:2003, таже самая фраза. Цитировать не буду, можете посмотреть сами, она и там, под тем же самым номером 5.3.3.
Или и стандарты 1998 и 2003 года тоже мало кем поддерживаются?
просто sizeof измеряет размер в чарах, (чему бы не был равен чар!)
сдедовательно sizeof (char) - это тафталогия.


Bodro, нет! Меня просто раздразило излишнее многословие в вашем коде.  (выдаваемое за кроссплатформенность)
Не знаю почему, но меня это раздразило.
Обычно я не вступаю в дискуссию по стилю написания, потому-что у каждого свой стиль. И лезть со своими мерками - моветон.

Ok

Это же надо было такую дурацкую конструкцию придумать.



Компилятор уже будет знать размер на стадии компиляции. а вот calloc(4, sizeof(char)) выделение 4 байтов памяти это вообще пипец.

Парни - больше пишите программ и изучайте язык, чтобы понимать такие "дурацкие конструкции" и не удивляться им. Если у вас недостаточный опыт работы с языками, компиляторами и разными платформами, то не надо это выставлять напоказ - лучше скрывать это, а то выглядит очень некрасиво. Больше похоже на болтовню, нежели на профессионализм. volatile хотя б ссылку на стандарт привёл.

Если вы не видели ничего кроме Builder, Visual Studio и Windows, то лучше бы не вмешивались в те вещи, которые не понимаете. Любая критика должна быть обоснована. А вы просто плюнули пост, засрали и всё! И ни доказательств, ни примеров "более правильной", по вашему мнению, реализации. Ничего - пустота и болтовня!

К тому же я от вас, кроме засирания, пока не увидел ни одной строчки кода (ни от одного ни от другого). В первых постах люди писали код, затем я написал кроссплатформенный абсолютно рабочий код - большое количество примеров. А от вас, кроме бестолковой критики, ничего не последовало. Хотите поболтать - пишите мне в личку - форум не надо засорять мусором и флеймом. В личке, если хотите и если у меня будет время на вас, я покажу код, реально используемый в ядре Linux, в оборудовании CISCO, в браузере Oregan, в ядре операционной системы STM OS20, в некоторых "хакерских" утилитах и бэкдорах, а так же в некоторых прикладных программах, реально используемых на платформах Linux и Windows.

Вы, ребята, похоже что, тролли или холиварщики. Напиши парочку примерчиков и представь их, а троллить - много ума не надо! Надоела мне вся эта чушь! Код не пишите, а только тролите! Желаю удачи!


Модератор, да закрой ты тему! А то начнётся сейчас тут война. Парень (Dreamuchiy) уже получил огромное количество ответов на вопрос. Думаю, он и сам за 4 года уже нашёл ответ на свой вопрос.

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


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

#define UNUSED(x) ((void)(x))
не?

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

Ладно, может просто кто не понимает суть подавляющей функции. Объясню.
В стандарте C99 и в C++ есть так называемые встраиваемые функции - ключевое слово inline. Код данной функции подставляется непосредственно в место вызова (это все знают - просто напоминаю). Таким образом, код функции

подставится в место её вызова, а, поскольку, она пустая, то ничего подставляться не будет. Таким образом, она никаким образом результирующий код не изменит, но позволит компилятору понять, что мы значение, которые передаём ей, собираемся использовать. Можно использовать template для подавления любых типов, а не конкретно int (только C++). Внутри переменную unused можно давить средствами прагм, обычным (void) и т.п. Но давить придётся в одном месте, а не в тысячи. Даже если ваш компилятор выкинет ворнинг, он его выкинет только в одном месте и для данного компилятора конкретно это место можно заглушить прагмами. Вариаций написания подобных функций много - проявите фантазию. Я представил лишь пример, отражающий саму суть.

Для тех кто по-прежнему продолжает считать что это "дурацкая конструкция" - пусть скажут это Trolltech и Nokia:


Простите за грубость, но учите матчасть!    Вопросы по поводу "дурацких конструкций" или по поводу ещё чего-то остались? Задавайте - с удовольствием отвечу, раз пошла такая пьянка. И впредь, прежде чем сказать что что-то "дурацкое", "тупое", "дебильное", "ламерское", "так только тупой мог сделать" и прочее (это относится не только к данному топику) задумайтесь - может это просто вы неправы? 


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


UPD
Вот сюда ещё взгляните - ещё один интересный вариант подавления: http://www.boost.org/doc/libs/1_49_0/boost...port/unused.hpp

Это сообщение отредактировал(а) Bodro - 27.6.2012, 15:28

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

Вообще-то, я просто написал программу и всё! Надо было просто её собрать и проверить работоспособность. Вместо этого люди стали показывать свой "профессионализм" и писать комментарии, ища в коде погрешности. На что и получили, собственно, телеги, где приходилось объяснять всё как ребёнку. Люди-то не спрашивали, а писал то что в коде они увидели "ошибки", а потом и вовсе дошло до "дурацких конструкций". Конструктивный диалог никто не вёл. Если что-то в моём коде показалось непонятным и странным - можно же было просто спросить? К чему все вот эти фразы?





Почему такого-же? Я не увидел в ответах рассказов про недюженый профессионализм, телеги кода, ссылок на примеры и подробных комментариев. Я объяснял всё тщательно и подробно, со стороны же оппонентов такого не было.

Предлагаю закончить весь разговор миром. Если кого обидел - прошу прощения! Я серьёзно! Просто давайте как-то более вежлевее, терпеливее и профессиональнее относиться друг к другу.


Это сообщение отредактировал(а) Bodro - 27.6.2012, 16:37

Макрос Q_UNUSED позволяет избежать предупреждений по поводу неиспользования какой-то переменной (чаще всего аргументов).
А вовсе не для функций возвращающих значение, которое мы не используем.

Да я встерчал в паре-другой проектов такие конструкции, и считаю это абсолютно ненужным загромождением кода.
К тому же это непоследовательное решение. Раз уж идти этим параноидальным методом, то нужно идти до конца.
И приводить к void, везде где не исползуется значение. А поскольку язык С/С++ состоит практически на 90% из выражений, то 
к (void) нужно приводить практически каждую строку.
например:

Кстати, это абсолютно правильный, рабочий и кроссплатформенный код.  
но умный ли, это вопрос...


Кроме того, ссылки на Trolltech и Nokia не совсем уместны (тем более в разделе дебилдера)
Достаточно будет одной ссылки на стандарт.
Буду признателен если вы укажете место, где говорится что приводить к (void) неиспользуемое значение функций - есть жизненная необходимость.

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

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




Это сообщение отредактировал(а) volatile - 28.6.2012, 00:40

*** 1 - "ПАРАНОИДАЛЬНЫЕ КЛЮЧИ КОМПИЛЯЦИИ, КОТОРЫЕ НИКТО И НИКОГДА НЕ ИСПОЛЬЗУЕТ" ***

Информация об используемых компиляторах:

Код из libc:

Проверочный код:

Результат работы:


В строке $ gcc test.c -c -O3 есть что-то параноидальное, сложное или крайне-редко используемое?

*** 2 - "САГА ОБ АБСОЛЮТНОМ ЗНАНИИ ЯЗЫКА СИ И C++ ИЛИ АБСОЛЮТНО ПРАВИЛЬНЫЙ, РАБОЧИЙ И КРОССПЛАТФОРМЕННЫЙ КОД" ***

Вы тут где-то видите неиспользуемые переменные или возвращаемое функцией значение? Вы совсем не понимаете о чём мы говорим?

*** 3 - МЫ УМНЕЕ ВСЕХ ИЛИ QT И BOOST ДЛЯ НАС НЕ АВТОРИТЕТ ***
Очень странно что Boost и Qt для вас не являются авторитетом. Это библиотеки, которые используются во всём мире в огромном количестве программ и прекрасно себя зарекомендовали как мощнейшие кроссплатформенные библиотеки. Если вы их не считаете за хороший пример написания кода, то это как бы наводит на мысль о вашей квалификации. Qt и Boost отлично используются в Билдере.

*** 4 - НАДО ЖЕ БЫЛО ВЫДУМАТЬ ТАКУЮ ДУРАЦКУЮ КОНСТРУКЦИЮ ***
Информация о компиляторе Intel:

Тестируемый код:

Результат для компилятора Intel под Linux:

А вот gcc обрабатывает такие ситуации отлично (даже при всевозможных опциях предупреждений):

Как видим, одного лишь (void) бывает недостаточно.

*** 5 - ВЕК ЖИВИ - ВЕК УЧИСЬ ИЛИ РАССКАЗ О ТОМ КАК Я СЛАЖАЛ ***
На счёт функции подавления признаю - недолядел - представил не совсем универсальный способ. На самом деле всё гораздо строже. Данный механизм мы используем редко (в основном уже готовые макросы или функцию в том виде, в котром я её вам описал) от этого и недоглядел. Так вот - суть в ссылке, т.е. когда мы пишем (void) variable;, то некоторые компиляторы считают что мы пытаемся использовать неинициализированную переменную и ругаются на это (если переменная действительно неинициализировалась). Функция подавления в том виде, в котором я её описал первоначально, положительного результата в этом случае не даст, потому что мы в неё пытаемся передать значение неинициализированной переменной. Как раз тут-то и нужна ссылка! Таким образом компилятор будет понимать что, возможно, мы переменную проинициализируем внутри функции.

Это что касается C++. Теперь, если мы хотим написать код на Си и нам, возможно, придётся компилировать его на компиляторе C++. Т.е. нам нужно создать какой-то способ подавления предупреждений о неиспользуемых переменных как на компиляторах C, так и на компиляторах C++. Тут возникает некоторая загвоздка! Ссылок-то у нас нет, а конструкция с (void) не всегда работает (пример - учебный компилятор Comeau или, например, компилятор Intel - раз есть два, значит есть и другие). Тут придётся шаманить:

Вообще, выглядит страшно и совместимо только со стандартом C99 и C++, т.к. содержит inline. Скажем так, я не нашёл оптимального универсального способа глушить предупредения компилятора о неиспользуемых переменных. Есть способ, применяемый на компиляторах C++, есть способ (см.выше), применимый на компиляторах C99 и C++. Можно придумать способ и для C89, но он не очень хороший (вызов call и ret).

Ну и опять таки, придётся передавать не само значение переменной, а её адрес.

Для тех, кто считает что я загоняюсь, хочу сказать, что реальные задачи именно такие - откройте GNU-код и увидите. Ещё примеры - протокол RTSP от CISCO, браузер Oregan от Oregan Networks, TCP/IP стек протоколов NexGen, код операционной системы STM OS20, ПО IPTV приставки IP-STB ICxSTB500-01, веб-интерфейс некоторых прошивок оборудования D-Link и др. Мне всегда хватало того что есть в Boost и Qt. Для более простых случаев я писал собственные глушилки или использовал (void), когда этого было достаточно. Но сейчас специально порылся и увидел, что всё-таки есть компиляторы, на которых даже тех вариантов, которые я представил (которые обосрал volatile и некоторые другие участники) оказывается недостаточно. В моей практике они не встречались.
У всех, кто удивился моим конструкицям и способам глушения ворнингов хочу спросить - вы хоть пытались гуглить проблему??? Для себя я нашёл способы глушения, но, как я сегодня узнал, что даже такие варианты не всегда помогают. Прежде чем засрать - вы бы почитали хоть Интернет!

*** 6 - ПО-СТАНДАРТУ, В ТУШЁНКЕ ДОЛЖНО БЫТЬ МЯСО ***

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

*** 7 - ВЕСЬ РАЗГОВОР НЕ ПО ТЕМЕ ***
Да, спор наш и правда абсолютно не по теме. Тема конкретная - Билдер. Человек задал вопрос - я просто написал несколько примеров, которые в том числе работаю на Билдере. На этом можно было б остановиться, если бы не volatile, который решил показать что он не знает функции calloc, но зато точно знает как можно обосрать то, что он не сделал. Ну а дальше пошло-поехало. Я предлагал много раз закрыть тему, но каждый раз кто-то что-нибудь неприятное да напишет!

В заключении хочу сказать. Я тут собрал всё в кучу и различные платформы и компиляторы, и языки С и C++. Много что. Но суть-то не в этом. Изначально я получил претензии в свой адрес что я написал очень неправильный, кривой, неработающий, праноидальный (и т.д.) код. И что я всё это выдаю за кроссплатформенность. Что в том что я написал нет никакой необходимости и это полный бред. Данный трактат написан для того, чтобы прочитав его и попробовав примеры, которые я указал, вы задумались, что стоит ли нападать на человека, который просто решил помочь другому и предложил несколько вариантов кода. Зачем нападать и тем более критиковать, когда у вас недостаточно опыта и знаний на критику? Господа, я призываю вас - впредь не нападайте ни на новичков ни на спецов - только себя выставляете в дурном свете! Прекратите же все свои нападки на мой код! Если есть что сказать, то сначала напишите хоть какие-нибудь примеры, касающиеся данного топика, а потом уже критикуйте (только очень прошу - подтверждайте свою критику фактами, стандартами, документацией, примерами кода, ссылками на авторитетные источники, личный опыт и т.п.).

Обращаюсь к автору темы и к модератору - закройте тему! Холивар чистый воды! Прошу прощения, что я его поддерживаю, просто не люблю необоснованные нападки на меня.


volatile, если вы не знаете, то зачем же пишете? Чего вы добиваетесь от этого спора? (ответ в личные сообщения)

фантастичное чтото есть, какая версия gcc?

Я так понимаю, весь текст вы не читали.



Это сообщение отредактировал(а) Bodro - 29.6.2012, 17:38

А у вас что за версия libc и что за версия gcc? Или хотяб что за операционка?

Мне нужно:
$ uname -a
$ gcc --version
$ ldd --version
$ lsb_release -a

Если что-то не заработает - скажите.

UPD
Кстати, функцию main могли бы не писать - мы ведь собираем с ключом -c. Правда, на предупреждение это никак не влияет вовсе.

Это сообщение отредактировал(а) Bodro - 29.6.2012, 17:58

у меня 4.3.4 
опять же тут два очевидных решения:
1) писать нормальный код и честно проверять возвращаемое значение
2) использовать -Wunused-result, хотя лично на моей версии он даже такого ключа не знает

догадываюсь

Добавлено через 2 минуты и 16 секунд

зачем такой код может быть нужен?

Добавлено через 3 минуты и 18 секунд

это к предыдущему вопросу

Ну тогда уж не -Wunused-result, а наоборот: -Wno-unused-result. -Wunused-result указан по-умолчанию.

А на счёт нормального кода - согласен - проверять возвращаемое значение нужно, но согласитесь, вы же не всегда его проверяете и не всегда оно вам действительно нужно. Порой возвращаемое значение можно проигнорировать. Но при переносе на другую платформу могут возникнуть ненужные ворнинги, а если, в случае с gcc, вы так же укажите -Werror, то код просто не соберётся.

Так что, как сами видите, однозначностей тут нет. Я надеюсь, вы то хоть со мной согласитесь?

Кстати, вы посмотрите на stdio.h на функцию fread. У неё в конце указано что-то вроде __wur или __attribute_warn_unused_result__?

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

Вот смотрите - у нас есть файл, который должен себя вести по-разному, в зависимости от некоторых условий, например, работает ли он как в составе библиотеки или как файл в отдельной программе. Когда у вас 1000 строк кода, вы можете написать программу вполне нормально, а когда у вас за 10 лет работы сменилось порядка 20-30 программистов и код у вас занимает 100 000 строк или более, то проще разобраться с конкретной функцией (методом) и переработать её, чем переделывать весь проект, ковыряясь в огромном количестве кода. Общаяя проблема сложных систем в том, что их нельзя понять в полном объёме и можно работать только лишь с какой-то частью. Для этого и существуют куча всяких тонкостей, в том числе и глушение ворниноов. Когда задача выходит за пределы написания конкретного драйвера или конкретной утилиты и превращается или в написание прошивки для устройства (вместе с ОС) или, например, в написание бизнес системы (например, VKernel Capacity Analyser - это просто пример), то разобраться в этой системе становится просто невозможно.

А в простом случае, просто с помощью подобных конструкций можно глушить необрабатываемое значение от функций. К сожалению, не могу вам привести самый наглядный пример с компилятором STM для микропроцессора STi 5100, т.к. его просто нет под рукой - там нужно было или обрабатывать вообще всё или глушить, иначе предупреждения вам просто не дадут понять действительно проблемное место. Но, я надеюсь, что вы мне просто поверите, что есть такие ситуации, когда нужно использовать подобный подход. Все кто мне возразил просто не обладают достаточным опытом напсания кроссплатформенного ПО под разные микропроцессоры, микроконтроллеры, под управлением различных ОС, и не всегда даже что есть ОС. В этом вины, конечно, никого нет. Просто мне не нравится, что люди начинают нападать, не представляя о чём идёт речь. Если вы не понимаете - это ничего страшного. Главное - желание изучать и находить истину! Все мы люди и все мы ошибаемся. Общайтесь с разными программистами. Например, очень много интересно узнаете на оверфлоу, на генту, на ЛОРе, на винграде в разделе кроссплатформенного ПО и программирование под Unix. Ищите истину!

alexvs11 поверьте, такие ситуации встречаются сплошь и рядом. Особенно, когда вам достаётся огромный чужой код. Если бы такой необходимости не было, разработчики библиотек Boost, Qt и прочих не стали бы придумывать подобные механизмы. Просто поверьте. Примеров я вам привёл предостаточно, в одном из них вы сами убедились, что однозначности нет. Изучайте код, пробуйте, смотрите. Старайтесь найти истину, а не упираться в стену и принимать всё в штыки.

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


Оператор присваивания возвращает значение, которое мы не используем.
Оператор присваивания - это тоже функция.
обычное:
равносильно:

operator= в языке С++ возвращает значение, которое мы в данном случае не используем. 

На весь остальной бред отвечать ни сил, ни желания нет, сорри.
Есть faq для новичков, поищите по форуму, там все есть.

Вам сколько лет, простите узнать? И какой у вас опыт программирования? вообще, вы чем занимаетесь? Просто, может смысле не имеет с вами общаться?

UPD
Надоело! От ваших оскорблений я устал! Думайте что хотите! Хотите что б я сказал что я не прав? Пожалуйта! Профессионалы, кто прочитает данный топик всё поймут. А перед вами распинаться я больше не хочу. alexvs11 запускает код, адекватно комментирует, интересуется. А вы ведёте себя как тупой баран, котрый упёрся рогами в стену и совершенно не слушает что ему говрят! Я признАю свою неправоту, если вы докажете что за 15 лет моей работы всё что написал и видел было мифом! Что для вас не авторитет никто - я понимаю! Вы не написали ни строчки кода, не сделали ничего, чтобы хоть как-то опровергнуть! Вы ТРОЛЬ! А я тупой осёл, кто повёлся на вас! И воноват на 100% я!!! Сколько раз зарекался с холиварщиками не общаться и опять повёлся! Доказать что-то тупому барану просто нереально, к тому же если этот баран ничего не возражает, а только льёт ###!

Добавлено @ 00:16
Самы поганый топик, судя по всему! Среди русскоязычных форумов, винград был не на последнем месте, но вы его обосрали до предела! Хоть бы одно доказательство! Троль и холиварщик!

Добавлено через 11 минут и 20 секунд

УЧИ МАТЧАСТЬ!!!

Добавлено через 14 минут и 34 секунды

Почитай про перегрузку!!! УЧИ МАТЧАСТЬ И ДУМАЙ ГОЛОВОЙ!!!

Это сообщение отредактировал(а) Bodro - 30.6.2012, 00:17

 Спасибо, загляну как-нить!

Добавлено через 1 минуту и 18 секунд
Но для начала, изуче calloc и libc, а потом говорите про перегрузку. Вспомните чушь, которую вы несли в начале нашего разговора! ВСЁ!

Так я вас оскорблять еще и не начинал даже

Хотите?  

Господа, остыньте немного. Не стоит обвинять Bodro в наведении тени на плетень и написании бреда. По существу он абсолютно прав! 
Проблема в том, что написание действительно кросс платформенного кода вещь весьма трудоемкая. Размер текста действительно сильно возрастает. С другой стороны действительно кросс платформенный код требуется очень редко, поэтому обычно ограничиваются определенным набором платформ и компиляторов, и делают код, который бы успешно компилировался на них.
Невозможно охватить все на свете, поэтому вопрос в том, что мы пытаемся охватить нужно ставить явно. 
Исходный вопрос был про Билдер, так что в данном случае вопрос о кросс платформенности явно не стоял, и (void) перед printf явный оверкил (Билдер этого не требует, а перенести программу с Билдера на другой компилятор невозможно по причине сильного отличия его диалекта С++ от всех остальных).

Кстати, по поводу ругани gcc на игнорирование результата от fread. Это не является встроенной реакцией gcc на игнорирование возвращаемого значения, а является явно затребованной (с помощью прагмы) реакцией от разработчика libc

Еще кстати, есть уж очень нестандартные компиляторы С, у которых например размер char'а - 2 байта (хотя sizeof(char) и у них 1), вполне понятно, что кросс платформенные программы на таком компиляторе скорее всего не заработают, какими бы они хорошими не были

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

вопрос.

Является ли данный код кроссплатформенным ?
и если нет, то что нужно здесь сделать. чтобы он стал действительно кроссплатформенным ?
(кода не много, так что труда думаю не составит)




Это сообщение отредактировал(а) volatile - 1.7.2012, 23:31

С точки зрения стандарта - является. Дальнейшее зависит от того, какими именно компиляторами мы собираемся это компилить. Некоторые могут потребовать return 0; в конце main
Некоторые (старые) могут потребовать #include <iostream.h>, ну и т.д и т.п.
Некоторые компиляторы вообще могут С++ не поддерживать   
Не бывает вообще кроссплатформенного кода.

ну это ладно, а почему вы не перечеслили главное, из-за чего здесь собственно сыр-бор?
  std::cout << "hello world" << std::endl;
возвращает значение (ссылку на объект std::ostream), которое не исползьзуется.

другими словами, если вы считаете что printf(...); некроссплатформенно, а (void) printf(...) кроссплатформенно
вам нужно признать и следующее
std::cout << "hello world" << std::endl; НЕкроссплатформенно
(void) (std::cout << "hello world" << std::endl); Кроссплатформенно

и вопрос вы где-нибудь когда-нибудь видели подобную, по вашему-кросплатформенную, конструкцию:
(void) (std::cout << ****);
я нигде и никогда не выдел. Специально даже поискал щас в гугле - ничего!

Вы действительно считаете что (void) (std::cout << ****); это кроссплатформенный код?


Это сообщение отредактировал(а) volatile - 2.7.2012, 23:41

volatile, я так понял, что речь идёт не совсем о кросплатформенности. Уже писали, что добиться поддержки всех компиляторов не получится. Поэтому, в данном случае, Bodro просто хочет, чтобы его WarningList был пустым во всех компиляторах, которые он использует. Я, кстати, тоже люблю, чтобы было чисто 

Так что, вы просто развели тут холивар на ровном месте...

Это сообщение отредактировал(а) artsb - 3.7.2012, 09:35

Не считаю. Запись (void)printf(...) в последний раз видел во времена K&R C. Потом оно как то рассосалось   
В настоящее время мне не известно ни одного компилятора, который бы по своей инициативе ругался на неиспользуемое возвращаемое функцией значение (а уж тем более С++ компилятор)

В настоящее время записи типа (void) func(...) или sizeof(char) используются в основном не для компилятора, а для программиста, в качестве явного указания намерений автора

PS. (void) перед printf на мой взгляд - overkill, но тем не менее вполне допустимая конструкция. Со смыслом может быть использована в обучающих целях - показать, что printf таки возвращает значение (которое мы не используем)

PPS. Конструкцию
лучше заменить на
или вообще на
 - это более переносимо (да и более привычно)

Добавлено через 1 минуту и 21 секунду

Точно!

Да нет автор утверждал именно об настоящеей кроссплатформенности.


Ну вот это ближе к истине. 
А использует он, компилятор для узкоспециализированного микроконроллера STi 5100, для тюнера (посмотрел не поленился).
Просто автор утверждал что именно так нужно писать всегда и везде. 

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



Короче чтоб закрыть тему, предлагаю свой вариант.
вот эту функцию

я бы написал так:


удачи всем!   


Это сообщение отредактировал(а) volatile - 4.7.2012, 01:37

Кстати говоря, 
Оказывается, этот охрененно кроссплатформенный код (так всем ужасно понравившийся)
вообще не компилируется на нормальном С компиляторе
ни здесь:
http://codepad.org/PauSSnZ5
ни здесь:
http://liveworkspace.org/code/54a261066030...e3cf2b1494edd74
 



да, да, абсолютно! 

volatile, так ето же не с++

alexvs11, Это C
Собственно автор и позиционировал его как С

Кроме того, в плюсах вообще не имеют смысла выражения типа (void) printf
Как верно заметил xvr


ps: Я вообще не понимаю почему вы приняли за чистую монету бахвальство псевдо "профессионала"?
Автор просто тупо брал самый длинный вариант из возможных, наивно полагая что самый длинный - означает самый кроссплатформенный. 
Я кстати, довольно часто сталкиваюсь с подобным стереотипом мышления.
(к сожаления этот топик не исключение.)