Quote:У тебя массив kakoy_to_massiv состоит лишь из 5 элементов, в то время как ты пытаешься "пройтись" вплоть до шестого его элемента (индексы от 0 до 5 включительно, то бишь всего 6 штук).

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

Quote:Да и объявлена функция kakaya_to_functcia как-то коряво.

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

Quote:Кстати, скажу тебе по секрету: запись &kakoy_to_massiv[0] эквивалентна записи kakoy_to_massiv Поскольку "имя массива" в С - это и есть адрес его первого элемента.

Да,читал про это Только вот невнимательно, из-за чего написал &kakoy_to_massiv и схлопотал ошибку

---
А есть не сложное объяснение почему оно все таки отображает то что мне нужно?
И как в этом помогает бесполезный код по выводу адреса? С ним даже
   начинает работать
Что происходит при присвоении kakoy_to_massive[5]? Ведь ее как бы не существует, сама создается? (или переходит снова на 0 элемент, затирая старое значение?)

Да, статья хорошая, только поздно ее увидел

Quote:P.S. А вообще здорово, что ты пытаешься разобраться с указателями. Это, возможно, самый сложный шаг в освоении C++.

P.S.Я больше директив и классов боюсь =) Пока толком не подошел ни к чему.

(03.04.2012 17:08)Efrit Wrote:  Ну и чем твой получившийся код лучше моего?

одной точкой выхода

(03.04.2012 17:08)Efrit Wrote:  Тебе приводится вводить не только дополнительную переменную

одна переменная в 4 байта ничего не решает.

(03.04.2012 17:08)Efrit Wrote:  но и целый двумерный массив

у тебя он тоже есть, хоть и занимает немного меньше места. и его существование не очевидно.

(03.04.2012 17:08)Efrit Wrote:  кстати, нафига он static?

чтобы существовал после выхода из функции

(03.04.2012 17:08)Efrit Wrote:  и всё лишь ради того, чтобы избежать дублирования return-ов.

ты поставил задачу - я ее выполнил. нечего ставить задачи в отрыве от контекста

(03.04.2012 17:08)Efrit Wrote:  Мне же проще использовать shared_ptr - и создавать ВСЁ в стеке, не парясь про утечки памяти при return-ах.

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

(03.04.2012 17:08)Efrit Wrote:  в то время как ты узнаешь об ошибке лишь тогда, когда пользователь доберётся до критичной строчки кода.

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

(03.04.2012 17:08)Efrit Wrote:  К тому же - сейчас, даже если вписать на место unsigned-переменной просто int-переменную (не обязательно константу) - то нормальные компиляторы всегда выдадут варнинг.

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

Quote:Ну так switch-то ты в итоге никуда и не дел

Переключатель - структурная конструкция и может быть развёрнута в if-elsif-else-end.

Quote:Так я же говорил про свой класс "массива", а не про "встроенные" обероновские массивы... В C++ я увижу подобную ошибку уже при компиляции, а в Обероне - лишь при исполнении.

Отрицательный константный индекс будет запрещён при компиляции.
Наличие знаковых типов ведёт к неизбежным преобразования знаковых к беззнаковым. То есть int и uint - числа из разных плоскостей. Избыточная сложность изучения, применения и использования при работе более одного автора проигрывает простому решению в стиле Калашникова.

(03.04.2012 18:20)Efrit Wrote:  Ну так switch-то ты в итоге никуда и не дел

так он и не противоречит единственности точки выхода

(03.04.2012 18:25)packa Wrote:  Что происходит при присвоении kakoy_to_massive[5]? Ведь ее как бы не существует, сама создается? (или переходит снова на 0 элемент, затирая старое значение?)

нет, ты обращаешься к левой памяти (в данном случае ты попал на допустимый адрес, но в реальности не все 2 ГБ виртуальной страницы имеют свой физический аналог и ты также легко мог бы попасть на несуществующий адрес и получил бы что-то типа "память не может быть "written"").

(03.04.2012 18:25)packa Wrote:  P.S.Я больше директив и классов боюсь =)

ну там все проще

packa Wrote:Что происходит при присвоении kakoy_to_massive[5]? Ведь ее как бы не существует, сама создается? (или переходит снова на 0 элемент, затирая старое значение?)

Ты пытаешься обратиться к &kakoy_to_massive[4] + sizeof(int) адресу памяти. В данном случае тебе повезло, но в реальности по этому адресу может лежать всё что угодно.

packa Wrote:Я больше директив и классов боюсь =)

Каких ещё "директив" - компиляторных, что ли? Их и не нужно всё помнить, лишь с десяток самых распространённых. На классы пока забей - лучше вначале хорошо выучи "чистый" С, без "плюсовых" фич.

gamecreator Wrote:одной точкой выхода

Спасибо, кэп. Я про читабельность говорил.

gamecreator Wrote:у тебя он тоже есть, хоть и занимает немного меньше места. и его существование не очевидно.

Неправда, у меня никакого двумерного массива нету. Из всех char-строчек типа "Zero" инициализируется лишь одна - та, что и будет в итоге возвращена.

gamecreator Wrote:чтобы существовал после выхода из функции

Это я знаю. Я не понимаю, зачем ему "после выхода из функции" нужно существовать

gamecreator Wrote:мне же проще использовать сборщик мусора и создавать ВСЁ в куче, не парясь про утечки памяти при чем-угодно.

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

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

А причём тут отладка? Ведь всё равно нет 100% гарантии того, что в ней тебе удастся создать такую ситуацию, при которой исполнится незаметная на первый взгляд, но критичная строчка. Придётся писать юнит-тесты, в то время как компилятор даст тебе 100% уверенность в своей правоте.

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

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

Berserker Wrote:Отрицательный константный индекс будет запрещён при компиляции.

Кем запрещён? С какого это перепугу, кто-то запретит указывать мне отрицательный индекс в операторе "квадратных скобок" в моём собственном классе?

В Обероне. И там нет перегрузки операторов.

   
Как видно - никаких сложностей, ошибка будет обнаружена сразу. А что в Обероне будет? Ведь в нём в сигнатуре функции get_value_of_array должен стоять int...

Там будет ловушка на этапе выполнения.

Вот видишь - на этапе выполнения. А некоторые ошибки на этапе выполнения хрен отловишь, в то время как ошибки при компиляции видны сразу.
Поэтому unsigned - это гуд. И чего в нём такого "сложного", мне решительно непонятно.

(03.04.2012 19:14)Efrit Wrote:  Я про читабельность говорил.

компактность, прозрачность.

(03.04.2012 19:14)Efrit Wrote:  Неправда, у меня никакого двумерного массива нету. Из всех char-строчек типа "Zero" инициализируется лишь одна - та, что и будет в итоге возвращена.

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

(03.04.2012 19:14)Efrit Wrote:  Я не понимаю, зачем ему "после выхода из функции" нужно существовать

чтобы возвращаемый указатель указывал на строку, а не на мусор

(03.04.2012 19:14)Efrit Wrote:  Это не "сборщик мусора" - это ты, наоборот, руками всё убираешь. Я и не говорю, что это плохо (сам так постоянно делаю), но при громоздкой классовой структуре для меня проще работать со смарт-пойнтерами.

спасибо, я знаю, что в с++ нет сборщика мусора. к сожалению

(03.04.2012 20:29)Efrit Wrote:  Поэтому unsigned - это гуд. И чего в нём такого "сложного", мне решительно непонятно.

никто и не говорил, что в нем "что-то сложное"

gamecreator Wrote:чтобы возвращаемый указатель указывал на строку, а не на мусор

Ну ё-моё. Да не нужен там никакой static Ты ведь производишь копирование для указателя result, созданного в куче... Не веришь мне - запусти код без static и убедись.

gamecreator Wrote:спасибо, я знаю, что в с++ нет сборщика мусора. к сожалению

Тогда не стоит писать "мне же проще использовать сборщик мусора и создавать ВСЁ в куче"

gamecreator Wrote:никто и не говорил, что в нем "что-то сложное"

Как это "никто"? Берс это говорил, прямым текстом...

(03.04.2012 22:21)Efrit Wrote:  Ты ведь производишь копирование для указателя result, созданного в куче...

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

(03.04.2012 22:21)Efrit Wrote:  Не веришь мне - запусти код без static и убедись.

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

(03.04.2012 22:21)Efrit Wrote:  Тогда не стоит писать "мне же проще использовать сборщик мусора и создавать ВСЁ в куче"

так мне же проще на c# писать, чем на с++

(03.04.2012 22:21)Efrit Wrote:  Как это "никто"? Берс это говорил, прямым текстом...

а, точно. ничего сложного в изучении нет, здесь согласен

А при проектировании интерфейсов, структур и функций есть. Если использована int, то uint не подходят. Если uint, то любое int-рассчитанное значение не подходит. При сравнении/присваивании нужны либо проверки времени исполнения, либо потеря безопасности.

не всегда. если значения укладываются в диапазон от 0 до 2³¹-1, то разницы нет.

И как это проверить? Проверками времени исполнения.