Изучаю Си(до С++ пока дела нет), тема массивы переменной длины(стандарт С99), использую компилятор gcc, включенный в среду Dev-C++(WindowsXp). Это моя первая тема на форуме(надеюсь в правильном разделе) и я честно перелопатил форум в поисках подобных тем, но к сожалению ничего не нашел.
Необходимо было написать программу с использованием функций, в качестве аргументов которых использовалась бы запись в стиле массивов переменной длины - одна для отображения двумерного массива, другая для копирования одного массива в другой.
прототипы выглядят так:

определения так:

вызов функций вот так:

проблема заключена в том, что по отдельности, каждая из этих функций работает совершенно нормально( я проверял, закоментировав то одну то другую), но при попытке компиляции, когда они работают вместе, компилер выдает следующее:
 prior parameter's size depends on 'm' 
 prior parameter's size depends on 'n' 
 confused by earlier errors, bailing out 
Я честно пытался перевести эти мессаги, но всё что понял, так это то что компилер пытается сказать что-то типа: "размер предыдущего параметра зависит от ...", я не понимаю в чем дело, раздельно друг от друга функции работают, а если компилер хочет сказать что функции как-то связаны - то как такое может быть вообще? тем более что они используют разные переменные.
Если у кого-нибудь есть соображения, пожалуйста поделитесь.

замени в аргументах функции double arr[x][y] на double *arr

Chelovek, дружище по-моему ты не врубаешься, я же сказал это стиль массивов переменной длины, характеризующийся тем, что сначала объявляются переменные, а затем они используются в качестве значений размера соответствующего массива, тем более если ты изучал Си, то должен знать что указание в качестве параметра простого указателя ничего не даст потомучто имя массива это адрес его первого элемента, кот. сам в свою очередь может быть массивом, например 5-ти элементов типа int, и указатель на int , такй как int  *ptr работь не будет, но всё равно спасибо.

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

объяви указатель вот так: (*ptr)[ n ], где n - размерность твоего массива, ну например если массив int array[3][5], то нужный указатель будет (*ptr)[5] - и всё будет работать (скобки в (*) обязательны), НО пардон, мы отклоняемся от темы.

Cheloveck, 
Но с двухмерными, почему-то не работает
потому что вот это:
массива это адрес его первого элемента
неправда, и двумерный массив расположен в памяти не так как массив указателей.

Вот тут твоя проблема обсуждается. Почитай, может поможет. Практически то, что я и сказал))

Во-первых я не понял, для меня ли твой мессидж, во-вторых ссылка не открывается, в-третьих варианты с традиционной записью параметров в стиле указателей или в стиле обычных массивов меня просто В ДАННОМ случае не интересуют, если ты представляешь что есть массив переменной длины и почему он так называется, то подобные ссылки и советы - просто бесполезный флуд.

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

З.Ы. ссылка с другого форума, по ходу тут их лочат, но там предлагаются традиционные решения с указателями...

Cheloveck, ты, скорее всего, путаешь массив переменной длины с динамическим массивом, отсюда и непонятки. 

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

напрасное обвинение, повнимательнее надо быть, там  всего лишь пропущено двоеточие   
 вот исправленная ссылка: http://www.linux.org.ru/view-message.jsp?msgid=658543


Это сообщение отредактировал(а) mes - 24.4.2009, 23:33

Чистое предположение:
1. Связаны функции общими дефайнами - надо смотреть дефайны и где определены и как объявлены массивы.

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

но это ничего не меняет - прога не компилится...

Приведите полный текст, если он не большой

привожу полный код:

а ругается на др. фукцию:

У меня, допустим, не компилится даже одна (g++ 4.3.3-2)(gcc то же самое)... И ещё, компилятор от майкрософт вообще не потдерживает массивы с переменной длиной.

Это сообщение отредактировал(а) Cheloveck - 25.4.2009, 00:03

Как я и предполагал - это чудо на BDS компилиться не хочет.
Я бы делал так:

Anikmar,  а нафига тогда первые 2 параметра у этих ф-ций?

да всё бы хорошо, только аргументы функций заданные в начале( int x, int y и тд) и есть переменные, описывающие размерность массива, и именно поэтому они объявляются раньше массива, стандарт С99 даже регламентирует форму записи без указния имен переменных в прототипах функций, использующих массивы переменной длины - вот так:

я это тоже пробовал, но в этом случае gcc честно признался, что он ещё не поддерживает это нововведение стандарта С99

А фиг его знает!   

Я просто так никогда не делал.   

Chelovek, ты вот пишешь:

это и должно так быть потому что С99 это точка расхождения Си и С++, компилятор С++ и не будет это компилить, даже с одной такой функцией.Массивы переменной длины включены в стандарт си для облегчения исп. библиотек FORTRAN, кот. славится своими функциями для научных расчетов. Попробуй откомпилить задав компилятором по умолчанию Си, а не С++.

gcc-3.4 сломан:
http://gcc.gnu.org/gcc-3.4/c99status.html
http://gcc.gnu.org/ml/gcc-bugs/2004-04/msg02261.html

Добавлено через 2 минуты и 20 секунд
я вам вообще рекомендую забить на эту мертвую фичу - переходите на С++ и юзайте динамические массивы

J0ker, спасибо, я думаю это и есть ответ, а переходить на С++ мне рановато, там более я решил сначала в достаточной мере освоить чистый Си.

Я уже было руки опустил, но тут неожиданно посоветовали включить опцию командной строки -std=c99, в среде 
Dev-C++ это делается(для тех кому придется сталкиваться) через Сервис-Параметры компилятора- и на первой вкладке поставить галочку напротив "Добавить следующие команды к запуску компилятора", после чего в поле пониже написать -std=c99 (и ессно ОК). Но есть одна особенность - при включенной опции Оптимизации, компилер даже при исп. опции -std=c99 не компилит, так что её придется отключить.

Одним словом решение надено, я думаю тема закрыта!    

Это сообщение отредактировал(а) Pieris - 25.4.2009, 11:51

Золотые слова. Я даже сперва не врубился - что это за прикол.


Ох... Чем изучать умирающие фичи - лучше сразу на плюсы. ИМХО: гораздо тяжелее переходить на плюсы хорошо освоив С, чем его зная чисто поверхностно.

С++ не является расширением С - никакой связи тут нет, можете смело переходить

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

ну само-собой
автомобиль-то завсегда сложнее велосипеда   


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

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

Anikmar, 
не вижу преимуществ С++ перед С

ООП упоминать не стОит   

Точка расхождения - создание C++. В C++ модификаторы const, extern, static имеют другое значение чем в C.
const в C++ = static const в С
Предварительное объявление переменной extern и затем static даёт в C++ extern, а в C static.

я с Си плохо знаком, вот что напрашивается :
возможность перегрузки функций, типобезопасные шаблоны, средства разделения доступа (public, private в классе)
виртуальные функции и т.д.
  

счас выльется воды на 20 страниц и на этом всё закончится.. проходили уже..   

mes, 

преимущества где?

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



Это сообщение отредактировал(а) mes - 26.4.2009, 22:29

что делает его более эффективным во всех смыслах

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

mes, 

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

Вот так рождаются баяны   .

Это вопрос уже к религиозным войнам относится, хотя странно обсуждать и сравнивать Си и С++. Я понимаю С++ и С# или C++ и Делфи. Лично я, когда появился С++ считал, что Си мне хватит за глаза и незачем изучать какие-то дурацкие веяния типа ООП, классов, перегрузки и т.п. Но мнение свое изменил достаточно быстро.

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

еще как получится   

но с ручными затратами. Взять хотя бы тот самый динамический полиморфизм - на cpp практически ничего не надо делать для его воплощения, плюс легко добавлять новые полиморфные типы в иерархию.
А как с этим обстоит в Си ?

Единственное что в C сделать проще - инициализацию массивов и структур.

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

хорошо

я даже больше скажу
sysfs и реализация kobject/kset в ядре linux - это сплошной полиморфизм на С
там все предельно просто и эффективно

я вообще-то специально оговорил, что не стОит начинать споры про ООП, т. к ООП != ЯП

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

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


так вроде пока не затрагивали: в частности полиморфизм свойствен далеко не только  ООП.

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

да


да



ну как бы "полиморфизм-наследование-инкапсуляция"   


для меня все очевидно
я этих задач уже достаточно много решил

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

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

• Массивы переменной длины ДЕЙСТВИТЕЛЬНО существуют и называются ИМЕННО массивами переменной длины (подчеркиваю это, т.к. на другом форуме меня обвинили в том, что я использую терминологию своего препода).
• Массивы переменной длины применяются ТОЛЬКО в языке Си(без плюсов) и ТОЛЬКО при использовании компилятора, поддерживающего стандарт С99, и совершенно понятно что компиляторы С++ НЕ БУДУТ компилировать такой код ПО ОПРЕДЕЛЕНИЮ.
• Массивы переменной длины(как можно было-бы подумать) НЕ ИЗМЕНЯЮТ в действительности своей длины и будучи созданным, сохраняют свои размеры, а называются так из-за того, что размерность таких массивов задается не при помощи констант или константных выражений, а при помощи переменных, и именно поэтому, в отличие от традиционного синтаксиса наподобии
  int function(int *ptr, int n) или double function( double arr[][10], int n) - где n ОДНА из размерностей массива, используют запись, где размерность массива задается переменными, объявленными В ОБЯЗАТЕЛЬНОМ порядке РАНЬШЕ, чем объявление массива, использующего эти переменные в качестве размерностей, т.е. например: 
  void funct(int rows, int cols, double arr[rows][cols]) (понятно, что тип возвращаемого функцией значения, как и тип массива может быть любым).
• Использование МПД имеет ряд ограничений: они объявляются либо в (теле) функции, либо как параметры функции.Кроме того их нельзя инициализировать в объявлении.
• Приемуществом функций использующих запись в стиле МПД является то, что они могут использоваться для обработки массивов любых размерностей, и поскольку в действительности объявление такого массива в списке параметров функции на самом деле не приводит к созданию массива, фактически такая функция работает(как и в случае старого синтаксиса) с данными переданного ей исходного массива.
• По поводу ошибок компиляции при использовании синтаксиса в стиле МПД можно сказать следующее: конкретно компилятор GCC по умолчанию использует синтаксис последнего стандарта(т.е. С99), и ЕСЛИ у вас не компилится такой код, попробуйте поэксперементировать с опциями оптимизации, именно это явилось причиной моих злоключений, если вы используете другой компилятор, то убедитесь что он поддерживает стандарт С99, и если это имеет место, но программа попрежнему не компилится, то возможно компилятору нужно явно указать опцию, задействующую возможности стандарта С99(в gcc например это опция командной строки -std=c99, хотя как сказано выше её применение в данной конкретной среде излишне), ЕСЛИ и в этом случае результат отрицательный, попробуйте поиграть с опциями оптимизации, возможно причина кроется именно в этом.

Да простят мне модераторы, неумелое использование тегов.

Это сообщение отредактировал(а) Pieris - 27.4.2009, 23:55

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

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

Добавлено через 3 минуты и 2 секунды
это про массив исопльзуемый в функции. массив передаваемый через параметры может быть выделен где угодно - хоть статический, хоть на стеке, хоть с помощью malloc().

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

Выражение 
Я растолковал, что можно будет в функцию принимающую массив переменной длины, передать любой многомерный массив.  
Разница между многомерным статическим и динамическим массивом в Си, то что первый линеен, а второй представлен как многоуровневый массив указателей. (т.е **...)
Соответсвенно передать двухмерный динамический массив как массив переменной длины не возможно. Но можно передать одну из его размерностей и рассматривать ее как двухмерный массив.

Хотя вполне допускаю, что не совсем точно понял мысль. 

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

Добавлено @ 12:19
т.е. можно сделать так:

здесь при каждом вызове ф-ции размеры массива могут меняться.

Это сообщение отредактировал(а) Dov - 28.4.2009, 12:22

  это же не будет работать

Добавлено @ 14:16
  
Это шедевр  

тема началась с

развернулась дискуссия на 4 страницы..и на последней странице я вижу сообщение

  вы не загнули ребята?

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


может вот так имелось ввиду?

Это сообщение отредактировал(а) azesmcar - 28.4.2009, 14:17

Имелось ввиду не это

Здесь при каждом вызове (с разными аргументами) генерируется свой код. И кроме тог cols, rows должны быть константами.

azesmcar, 

будет

  

Выдаст что-то вроде expected constant expression.

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


даже если этот код где-то и работает - этот код непереносим.

не из того стандарта выдержка 

mes

аааа  
ну извиняйте..не прочитал все 4 страницы..я думал речь о С++ идет 
Развели дискуссию сам черт ногу сломает 

Как ни странно, работает, даже если файл дать расширение .cpp (компилятор gcc, естественно)

Ему наплевать на расширение.

этого хватит.

а вот на визуал студии - не работает.
1>c:\my projects\dd\dd\main.c(5) : error C2057: expected constant expression
1>c:\my projects\dd\dd\main.c(5) : error C2466: cannot allocate an array of constant size 0
1>c:\my projects\dd\dd\main.c(5) : error C2057: expected constant expression
1>c:\my projects\dd\dd\main.c(5) : error C2466: cannot allocate an array of constant size 0
1>c:\my projects\dd\dd\main.c(5) : error C2087: 'arr' : missing subscript
1>c:\my projects\dd\dd\main.c(5) : error C2133: 'arr' : unknown size

Добавлено через 14 минут и 19 секунд
Поскольку привел издержку из стандарта (привел из неправильного ) приведу теперь из правильного.



Но студия все равно не компилирует  

По этому поводу уже был один эпический holywar: http://forum.vingrad.ru/forum/topic-230321...+/view-all.html


Наверное, было бы правильнее сказать так: массивы переменной длины входят в текущий стандарт в C, но не входят в текущий стандарт C++. Некоторые гнутые компиляторы C++ поддерживают массивы переменной длины в качестве расширения.