Хех.


Это они сводят поведение assignment operators для POD к поведению перегруженных операторов для классов (которые есть функции и уж точно завершат запись до возврата значения)?

Свежий стандарт C (не С++) у кого-то есть? Недавно и C обновили, не только С++

Наверное, цитата по ссылке
At the end of a full expression. This category includes expression statements (such as the assignment a=b;)
говорит, что любое ^= создает sequence point.

Не говорит. В "например" определяющей является точка с запятой, заканчивающая утверждение, а не присваивающий оператор, являющийся вместе со своими операндами выражением.
Т.е. expression в данному случае превращается в full expression путём участия в expression statement при помощи завершения символом
;
т.е.:
a = b = c = d; Это один expression-statement, превращает в full-expression всё a = b = c = d
Cостоящее из нескольких subexpression.

Может, в С++, особенно в C++11, что-то и не так, я туда ещё так не вчитывался.
Какие-то моменты, undefined в C, стали unspecified в C++, с этими их тонкостями ещё пойди разберись.

Да, кстати, я не подчеркнул отдельно

Вот ответ, разными компиляторами можно:

http://liveworkspace.org

Причём не только C/C++.
В ответ на кусок кода вся диагностическая выдача компилятора (в зависимости от ключей) и, при создании исполняемого файла, выдача на stdout

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





Итак, я считаю что с задачей А мы справились. Плавно переходим к задаче Б..

Задача Б
В этой реализации мне не нравится, что в случае дефолта сначала проверится один кейс, затем другой и только потом собственно выполнится подходящее действие! Что если нужно например месяца из чисел в названия переводить или там справочные данные какие?
Потом мне непонятно почему нужно static const char strue[]="бла-бла-бла"; делать!? Это в смысле что строки в памяти программ расположатся? Как с доступом к таким значениям? не будет страдать производительность?

Для таких программ потом и пишут заплатки на тему переполнения какого-нить буфера.

static - чтобы можно было вернуть из функции указатель на что-то вменяемое, const - считайте просто правилом хорошего тона.

Для этой задачи оптимальным наверное будет сочетание двух подходов: в случае если длина строки не более чем MAX_LEN использовать один подход, если больше - второй, и менять данные прямо по месту. Я пока еще не придумал как красиво пофиксить переполнение буфера ибо нужно на каждой итерации проверять условие достижения конца буфера, а мне не оч. такой вариант.


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

Поосторожнее… А то сейчас набегут спецы, которые сначала скажут, что возвращать указатель на внутренний статический буфер нельзя, потом скажут, что они имели ввиду, что оно-то можно, но глюкодром. А на вопрос, чем именно
глюкодромее
просто не будут отвечать по существу.
Недостаток у способа один:
Впрочем, для таких случаев мои функции подобного типа принимают второй аргумент (со значением по умолчанию в C++), которым программа, имеющая желание в одни заход получить несколько строк, обязан апередать буфер достаточного размера:
В итоге в большинстве случаев вызывается reverse(some_string); (второй аргумент по умолчанию подставляется 0), и только в отдельных случаях подставляется доп. буфер.

Однако задача в некотором смысле не решена и не может быть решена без уточнения условий и целей.
Например, если цель — скорость, а строки преимущественно «достаточно длинные», а процессор Cortex-M3 или другой, имеющий команду реверся байтов в 32-битном слове (i486+), то стоит подумать о зачитывании по 32 бита, реверсе порядка байтов соответствующей командой и т.п. Соответственно, с выделением места под буфер кратно 4 байтам + под концевой 0, спецобработкой хвоста из 1..3 символов и возвратом указателя на tmp_buf с нужным смещением.
«Если Вы не указали цель оптимизации, то Вам всё равно, как писать код» © Чеширсикй Кот – программист.

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

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


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



Да, лучше внутри функции.

Безусловно.
Т.к. в условии задачи не сказано, что исходная строка должна сохраниться, я бы делал реверс на месте. Цена вопроса - один strlen(). (оно, конечно, не спасёт, если строка вдруг окажется без '\0')

К переполнению, естественно, не приведёт. Но если память (опять же вдруг) закончится...

За жисть. У меня K&R был первого советского издания (в мягком переплёте, голубая обложка), не помню в нём таких упражнений. Хотя, может опять склероз буйствует.

Так в том-то и дело, что в условии задачи не сказано ничего (см. выше про Чеширского Кота – программиста). Как я говорил дочери, когда в школе на информатике пошёл паскаль, — программу можно оптимизировать на скорость написания, на простоту отладки, на скорость выполнения, на минимальный размер, на скорость понимания другим человеком, …
«Множество чего? Просто множество!» (что-то меня на Алису потянуло) «просто оптимизировать» невозможно.

У меня был K&R, любовно кем-то подготовленный (фигурные скобки сделаны из круглых с надпечаткой поверх минусом, ключевые слова двойной печатью, …) и напечатанный на барабанном АЦПУ, переплетённый в переплётной мастерской (кажись, в один заказ с дипломной работй жены, тогда это 1987 год). Тоже таких упражнений не помню :-)

Во втором издании (в мягком переплете, белая обложка, голубая буква С) есть упражнения по переворачиванию строки.

Задача А. Работа над ошибками так сказать..
В этой версии маленькие строки (меньше LEN_BUF байт) копируются в обратном порядке в буфер и возвращается указатель на голову, а если строки большие, то перестановками решаем. Во втором варианте проверям чтоб строка не слишком большой была (меньше MAX_LEN_STR)



Не ясно еще как все же быть с одновременным вызовом функций

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

О майн Готт! Вы на листинг этого чуда хоть смотрели?

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

Ниасилил. Strlen() хоть вызывай, хоть делай сам - оно выглядит одинаково.
Чем, извините, это всё лучше, если оно жрет памяти вдвое больше, не заточено под ASCIIZ, в >3раза больше число итераций. О майн Готт!

K&R всплакнули бы от умиления...
Есть такая прилада профайлер, которая позволяет оценить время выполнения кода. Сравните результаты Вашей программы и поминавшихся выше вариантов со strlen().
Про наглядность кода и разбазаривание памяти ... пусть будет Задачей №3.

И попробуйте


UPD: сделайте s1 > LEN_BUF

_Pasha , функция работает в двух так сказать режимах:
а) когда входная строка меньше по длине чем LEN_BUF
б) когда входная строк больше, чем LEN_BUF

в варианте "а" strlen не вызывается, но при этом крутится вся строка
в варианте "б" strlen не вызывается, но выполняются действия аналогичные по смыслу. после этого строка перебирается и меняются местами данные, кол-во итераций длина строки/2. Вот как и у вас по сути.

последняя реализация лучше тем ,что если на входе функции будут разные данные ,то в общем итоге получается оптимальнее!
И обратите внимание - алгоритм "б" дополняет собой алгоритм "а" !



Я согласен. Предлагаю обсудить условия проведения соревнования на скорость и денежные призы. Итак!?







ну не знаю ,кажись работает:

Есть указатель на указатель на char:

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

обычно это имя переменной, которую получает main. Это массив указателей на строки - аргументы командной строки. В паре к ней идет argc - количество элементов в массиве.

Да поправят меня, если не прав
Указатель передается обычно тогда, когда функция может менять какие-то данные за пределами себя
Указатель за пределами какой-то функции тоже можно менять, не так ли? вот и передается указатель на этот указатель

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

Формально - прав. Фактически - нет. Поправляю.
Вопрос был о char **argv.
Есть такая штука, как code convention. Именем argv принято обозначать статический массив указателей на строки. Поэтому упаси бог использовать его по тому же принципу, как используют при работе со списками. Например, здесь переменную answer назвать argv нельзя из соображений личной безопасности:

То что вы написали тут формально и гарантированно работать не будет ИМХО.
Т.к. вы инициализируете указатель адресом локальной не статической строки и используете этот указатель вне области жизни этих строк (в другом стековом фрейме).
Вот так все формальности будут соблюдены:


Хотя набрёл тут на такое:
и немного из другой плюсатой оперы
Захотелось найти это в первоисточнике....

Это таки будет работать гарантировано. Потому что моя функция возвращает указатели на read only строки из секции data
Ваша функция тоже будет работать, но в ней есть бесполезное копирование строк из read only секции data в read write секцию. Недостатки
- в два раза увеличился объем памяти
- нет защиты от случайного изменения текста (оно в данном случае не желательно)

Посмотрите здесь

Ну и посыпаю голову пеплом по поводу опечатки в названии функции. Должно было быть true_or_false. Хотя так даже прикольно получилось, многозначительно.

На платформе АVR и так и сяк будет двойной расход памяти flash + копия в озу пока явно не зададим __flash.
Это так к слову...

Это объяснение не на том уровне. Хотелось бы в контексте Си стандарта...

На MSP430 - все литеральные строки хранятся во флэше. А для инициализированных массивов, если я не хочу переносить их п память, достаточно добавить const

Попутно. Оффтопик. Как вам удается редактировать свои сообщения, без того чтобы было написано "изменен тогда-то и тем-то"?

Это всё понятно. У MSP430 единое адресное пространство - просто и удобно... И про повсеместный static const я как бы тоже в теме. Меня интересует конкретный отсыл в стандарт и только...Также как и вам. Нажимаю редактировать -> быстрое...

В avr-gcc вообще все очень непросто со строковыми литералами.
Можете почитать нашу дискуссию на сей счёт: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
И был бы очень рад если ещё кто-то меня поддержит в ней!

Я так делаю - обязательно пишет что меняли текст.


Почитал. Познавательно. Я сам с AVR не работаю.

Запросто - С99 стандарт, глава 6.4.5 (String Literals), параграф 5
Так что возвращать из функции можно

О! Вот это вразумительно!
Спасибо! Приятно осознавать что ты поумнел после содержательной беседы. Серьёзно.
Отдельное спасибо igorle!

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

igorle ,вы привели программу


Мне кажется, что argv не указатель на указатель, скорее это указатель на массив указателей ! И в аргументах функции foo1 правильнее будет записать *argv[] вместо **argv
И в том виде в котором Вы запостили, код не компилится и нужно либо в аргументах printf разыменовывать argv либо использовать квадр. скобки и индекс для каждого элемента массива.

Мне больше нравится вот так:


Мы подчеркнули природу аргумента функции foo1 ,но вынуждено используем "указательные" св-ва масива для упорядоченного, с начала в конец, вывода элементов на "печать".

Кароче трудно как-то все получается

С точки зрения языка С, в данном случае (для прототипа функции), обе записи равнозначны. Используйте то, что вам понятнее.
Со временем придет "чуство" того, что имя массива и указатель - это одно и то-же.

Да, это я ошибся. Нужно *argv++
Ваш вариант, с последним элементом NULL, правильный, тем более что функция main действительно получает массив argv размером на единицу больше, чем argc, с NULL терминатором.


Массив и указатель - близнецы братья. При использовании - это одно и то-же. Немного практики, и это станет простым и естественным. И будет непонятно, как некоторые языки не используют указатели. Верной дорогой идете!

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

Я спрашивал именно о указателе на указатель. Дело в том что гуглится что-то невразумительное на этот счет. В К&R нет подробного освещения вопроса. Уповаю на ваш експириентс. Спасибо!

Указатель и массив - это не одно и то же. Но имя массива - это указатель на первый его элемент
a[0] то же самое что и *a
a[10] то же самое что и *(a+10)

Понятно, что при определении переменной
int a[] и int *b - разные вещи. Но после этого они во многом ведут себя одинаков. Во многом, но не во всем. a нельзя присваивать новое значение, b - можно.

int a[10];
int *b = a;

Теперь все, что вы хотите делать с a, вы можете делать с b. Обратное не верно
Например b[2] - это то-же самое что и a[2].

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

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

Дьявол в мелочах (с).
Тот случай, когда пренебежение терминологией, привело к не верному выводу. А именно, "указатель" != "адрес". Имя массива - не "указатель" на первый элемент, а "адрес" первого элемента.

P.S.
Оказывается, объяснить тоже не сложно.

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

Скажите, а где можно посмотреть реализацию отдельных функций описаных в заголовочном файле string.h ?

http://www.uclibc.org/

http://git.uclibc.org/uClibc/tree/libc/string

Многомерный динамический массив.

Забавно. Никогда так не делал. Первая реакция была - "ерунда". Потом подумал - а ведь должно работать....

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

Да, оч. интересно! Правда не совсем ппонимаю, как освобождать память из под такого массивчика?
Если указатель связанный с данными через "new" погибнет, потеряется - память "потечет"!?

Если я использую библиотечные функции, ну например "strcat" библиотеки cLib, прототип описан в string.h, выделить память для результирующей строки должен программист? о_О

Вот именно™
Имя массива — это имя массива. Оно имеет тип «массив вон-того» (в зависимости от объявления).
Почти во всех выражениях оно автоматически приводится к указателю на первый элемент.

Я считаю что хороший способ запутать (и запугать) новичка. Вы должны теперь объяснить, что my_array и your_array следующем примере:

это две большие разницы. И вообще эти переменные - разного типа. Это неочевидно ученику.
Давайте спросил Буратино (задачу решить на листочке, не используя компилятор):
- какого типа your_array?
- что вернет sizeof(my_array) и sizeof(your_array)?
- можно ли сделать такое присвоение int **his_array = your_array; ?

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

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

Например, было актуально во времена «640 килобайт»
При фильтрации изображений, скажем, окном 3х3, можно выделить место на две дополнительных строки, начать фильтрацию в них. При получении третьей (номер 2) строки выходного изображения первая строка (номер 0) входного изображения уже не нужна, результат можно помещать в неё, потом в нужное место переписать указатель. В итоге через какое-то время строки изображений в памяти разбросаны как попало, но все работает :-)

Да, и узнать это из исходников - похвальный, но не самый простой путь. Лучше читать man pages
Кстати - многие функции еще и не проверяют корректность параметров. Например strcat(NULL, "basa"); просто покрошится.

Давайте сначала Вы объясните ученику, как при помощи записи вида int your_array[что-то-одно][что-то-другое]; создать массив неизвестного заранее размера с времением жизни, выходящим за рамки функции, в которой он создан.

Был вопрос «зачем такое может быть нужно». Дан ответ. Дальше ученик должен думать. Различия можно объяснять.


sizeof(my_array) вернёт в точности то же самое, что тут вернёт sizeof(your_array)
и всё равно придётся объяснять, почему sizeof(your_array) в двух разных местах возвращает разные значения.


Кстати, я считаю, что запись foo(char *arr[]) гораздо хуже, чем foo(char **arr).
В итоге-то одно и то же, у функций одинаковый прототип, принимают pointer to pointer to char.
В режиме компиляции С++ должно быть одинаковое mangled-имя.
В первой записи arr по сути тот же char **, только этого не видно (пресловутому ученику) и этот arr невозможно сделать константным.
foo(char const * const arr[])
Вот тут аж дальние char — константные. Указатели на них, хранящиеся в массиве, на который указывает аргумент arr (в С ведь массивы не передаются как параметры, не правда ли?) — тоже константные. А сам аргумент - не константный, хоть плачь.

всё, что имеем:

А с первой функцией все нормально, компилятор молчит.

Ещё раз. Указатель, это переменная, занимающая место в памяти. Под адрес же, память не выделяется. Что там происходит дальше, на что похоже, как оптимизируется и т.п. - дело десятое.

Не знаю как сейчас, а еще 3-4 года назад тот же IAR/ARM, на максимальной оптимизации, генерил совершенно разный код в одном и том же цикле, для Array[i] и *(pArray+i). Т.е. работал совершенно по-разному ( через указатель гораздо быстрее ). "Хотя казалось бы..." (с). Пришлось ручками ковырять libavcodec, на предмет переделки обращения a[] в *pa, потому что иначе SAM7S64 не успевал размотать два канала честного ADPCM.

Ну хорошо.
«is converted to an expression with type ‘‘pointer to type’’»
приводится к выражению типа «указатель на»
Не к «переменной типа „указатель на”». А к выражению. Приводится, а не есть им.
Результат этого выражения может не сохраняться в памяти. Может сохраняться во временной переменной в регистре. Может в результате оптимизации сразу компилироваться в тело команды.
Но сначала имя массива приводится к указателю на. Везде, кроме & и sizeof.
Только в результате этого приведения выражения и эквивалентны.

Да, кстати. Возьмём char a, b;. Теперь возьмём выражение a+b.
Приянто говорить «перед сложением a и b приводятся к целому».
Вы и здесь будете говорить «Ещё раз. Целое это переменная, занимающая место в памяти.» ?
«Целое», «указатель на» — это типы. А не переменные этих типов.

Кстати, и «переменная типа „указатель на”» может не занимать место в памяти. И даже в регистре. После оптимизации, конечно.