Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | |
Да. Ошибся. Причем ошибся именно в заголовке [updated] 17.10.03 14:58 Число просмотров: 1639
Автор: amirul <Serge> Статус: The Elderman Отредактировано 17.10.03 15:02 Количество правок: 1
|
> > Потому как первый максимальным будет 1, потом оно > станет > > старым. А нового максимума не появится. Так что > результат - > > 1. ^^^^^^^ Внутри все правильно написал :-) И это именно то, что я и имел в виду :-)
> > C++ ему соотвествует класс deque. > > ДЕКи (double ending queue) тоже разные бывают: возможна > реализация простой очереди, а возможно с очередью "для тех, > кто вне очереди", то есть вставить в начало. Со стандартным > классом не знаком. А я и сказал, что именно в C++ deque - кольцевой буфер. :-) Потому как стандартизировано время доступа const к рандом элементу, а не O(n), как получится для реализации дека на списке. Больше стандарт по этому поводу ничего не говорит, но едиственная возможность получить два конца очереди и при этом константное время для произвольного доступе - кольцевой буфер.
> Ну а для самого веского аргумента предлагаю подумать над > реализацией программы находящей корни квадратного > уравнения. Попробуйте описать эту программу, которая будет > адекватно реагировать на любые "хакерские" уловки. А из уловок там могу вспомнить только отрицательный детерминант (мнимые корни, то бишь нерешаемое уравнение) и нулевой знаменатель (то бишь линейное, а не квадратное уравнение). Реализовывать лень, но я бы делал проверки только на это.
Вспомнил еще одну уловку - переполнение double числа в обе стороны (к нулю и бесконечности). Ее просто выловить из ошибок мат библиотеки
|
<programming>
|
[C++] Динамический многомерный массив/японский кросворд. 13.10.03 21:45
Автор: oleaster Статус: Незарегистрированный пользователь
|
1. В массиве int A[10][10] ,- является ли A типом (int **) ?
(Я так понял, что не является ,- он у меня функциями void a (int ** b) наотрез не принимается
и кроме того я последовательно память просмотрел ,- мой вывод - массив размещен последовательно)
В конечном счете мне нужно было динамически выделить int A[10][10].
Как я понял new может выделить только последовальную область, поэтому пришлось бы самому A[a][a*10+b];
int ** GG, ee=0;
GG = new (int *) [10];
while (ee<10) GG[ee++] = new int [10];
Странно, но это у меня работает как int GG[10][10], т. е. как аналог int A[10][10], при том, что и void a (int ** b) его принимает.
Я в принципе не до конца понимаю ситуацию, поэтому расчитываю, что вы что-нибудь умное скажите и у меня все станет на свои места.
Что по этому поводу говорит стандарт языка C/C++
и как решаются проблемы с динамическими многомерными массивами (предполагаю, что все решается как-то более элегантно) ?
2. Если кто реализовывал алгоритм разгадывания "японского кросворда" (числа преобразовывать в картинки)
(делали это простым перебором или логическим анализом).
|
|
[C++] Динамический многомерный массив/японский кросворд. 15.10.03 15:33
Автор: sem4a Статус: Незарегистрированный пользователь
|
Lu4she vsego STL kone4no no,
eshe mojno tak:
int a = 2, b =2; // [2][2]
//Alokazia:
// VC++
int* p = (int*)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(int) * a * b);
ili
// All
char* pCh[] = new char[a * b];
p = (int*)pCh;
// Ovrashenie
(&(p[0]))[0] = 1;
(&(p[0]))[1] = 2;
(&(p[1 * a]))[0] = 3;
(&(p[1 * a]))[1] = 4;
|
| |
[C++] Динамический многомерный массив/японский кросворд. 15.10.03 17:40
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Это не беда, если память криво выделить придется:
int *p = (int *)malloc( x * y * sizeof( int ) );
А, вот обращаться к элементу хочется именно через скобочки без упоминания о количестве строк/столбцов.
p[ 1 ][ 1 ] = 0;
а не так извратно, как ниже.
> (&(p[0]))[0] = 1; > (&(p[0]))[1] = 2; > (&(p[1 * a]))[0] = 3; > (&(p[1 * a]))[1] = 4;
|
| | |
[C++] восползуйса operator overload 15.10.03 17:43
Автор: sem4a Статус: Незарегистрированный пользователь
|
|
| | | |
[C++] Я вот думаю 15.10.03 18:11
Автор: amirul <Serge> Статус: The Elderman
|
На фига писать свой класс-массив, если в STL уже все есть.
Или правда все таки в той истории про русского программиста: "Переделать все нах"
ЗЫ: Повторю: пользуйся <vector<vector<int> >, если не нравится такая запись, один typedef может все исправить
|
| | | | |
[C++] и еше о STL 15.10.03 18:41
Автор: sem4a Статус: Незарегистрированный пользователь
|
Легче свой один маленький клас написат,
если ето единственое использование
|
| | | | | |
[C++] Легче как следует выучить классы и алгоритмы STL и уметь их правильно применять. 15.10.03 19:03
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Легче свой один маленький клас написат, > если ето единственое использование Это оно сейчас единственное. А через год может быть уже не единственное. А STL как раз на масштабируемость упирает.
|
| | | | | | |
Не обобшай 15.10.03 19:29
Автор: sem4a Статус: Незарегистрированный пользователь
|
|
| | | | | | | |
Сорри, согласен, слишком огульно сказал. 15.10.03 19:48
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
Но STL программисту на C++ в наше время знать все же надо :)
|
| | | | | | | | |
Сорри, согласен, слишком огульно сказал. 15.10.03 19:54
Автор: sem4a Статус: Незарегистрированный пользователь
|
> Но STL программисту на C++ в наше время знать все же надо > :)
То что касается меня я о4ен часто ползуус,
List, Map, vector, iterator'i i tak dalee
|
| | | | |
[C++] STL 15.10.03 18:38
Автор: sem4a Статус: Незарегистрированный пользователь
|
> На фига писать свой класс-массив, если в STL уже все есть.
STL плохая библиотека, много memory leaks, но удобная
|
| | | | | |
[C++] STL 15.10.03 21:45
Автор: amirul <Serge> Статус: The Elderman
|
> > На фига писать свой класс-массив, если в STL уже все > есть. > > STL плохая библиотека, много memory leaks, но удобная В STL (да и вообще при использовании шаблонов) инстанцируется только то, что используется. Не думаю, что в реализации vector::vector и vector::operator[] так уж много ликов. Даже в MSVC6. А в данном случае именно эта функциональность нужна.
Так что смело мы в бой пойдем :-)
|
| | | | | |
[C++] STL 15.10.03 19:02
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> STL плохая библиотека, много memory leaks, но удобная В какой именно реализации STL много memory leaks? ;)
|
| | | | | | |
[C++] STL 15.10.03 19:25
Автор: sem4a Статус: Незарегистрированный пользователь
|
> > SL плохая библиотека, много меморы леакс, но удобная > В какой именно <б>реализации</б> STL много > меморы леакс? ;)
VC++ 6.0 SP 5
Запусти с BoundsCheker'ом
|
| | | | | | | |
[C++] Извините за грубость... (updated) 15.10.03 19:43
Автор: Ktirf <Æ Rusakov> Статус: Elderman Отредактировано 15.10.03 19:52 Количество правок: 2
|
> > В какой именно <б>реализации</б> STL много > > меморы леакс? ;) > > VC++ 6.0 SP 5 бееееееееее....
А я-то думал что-то новое... Ну что сказать, это одна из самых печальных реализаций STL, которые я видел :) (кстати, сервис-паки на этот предмет не слишком помогают).
Рекомендую STLPort либо (если по каким-то причинам хочется именно MS) STL из VC7, правда, если я не путаю, VC 6 она не собирается.
|
|
Никак. 14.10.03 12:37
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Сам когда-то сталкивался с этой проблемой.
Метод, предлженный Вами, вполне работоспособен и ни чему не противоречит. Единственное, что он не удобен, поскольку требует создание и инициализацию массива указателей.
В оригинале, когда многомерный массив согдается не динамически, отводится память только под данные. Компилятор "знает" о размере строки и о количестве столбцов и генерит соответствующий код.
На сколько я знаю ни в каком из стандартов С, ни в С++ не предусмотрен необходимый для этого оператор (динамически определяющий размерности массива для указателя).
Может помочь С++, только индексы придется передавать по-другому. Не array_ptr[ i ][ j ], а, например, array.ref( i, j ), где метод ref будет возвращать ссылку на элемент массива.
А все-таки было бы удобно, если бы в С эта возможность была бы предусмотрена, хотя по возможности следует вообще не прользоваться массивами. Но это уже философия.
|
| |
а можно немного философии?? 15.10.03 22:28
Автор: zelych Статус: Member
|
..
> бы предусмотрена, хотя по возможности следует вообще не > прользоваться массивами. Но это уже философия.
чем массивы так не угодили??
|
| | |
Можно. 16.10.03 12:08
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 16.10.03 12:10 Количество правок: 1
|
> чем массивы так не угодили??
Каким бы большим не был массив, его размера может не хватить.
Каким бы маленьким не был массив, обязательно найдуться неиспользуемые элементы.
Если задачу можно решить без массива, то так и следует поступить.
Пример: Напишите програмку, которая делает следующее - последовательно вводятся числа (количество введенных чисел немзвестно/неограничено), при вводе заранее оговоренного числа программа должна выдать второе по максимальности число (именно не самое максимальное, а второе по величине) и закончить работу.
Так и хочется завести массив, считывать циклически введенные числа в последовательные ячейки массива, при вводе ключевого числа вывалиться из цикла ввода, отсортировать массив и выдать значение второго элемента. Проблема в том, что надо обойтись без массива, поскольку количество введенных чисел неограничено.
Из ностальгии: Смотрел когда-то на исходники программы математического моделирования динамических систем, где под параметры звеньев и связей были отведены приличного размера массивы и понимал, что программа может столкнуться с проблемой нехватки свободных элементов массива при большом количистве исходных данных. Благо массивы были огромные, а задачи решались в основном элементарные. И програмка эта была очень жирная в памяти - очень неудобно было.
Разумеется исключением из этих правил будут являться хакерские задачи типа: решить систему из ЧЕТЫРЕХ линейных уравнений с ЧЕТЫРЬМЯ неизвестными матричным методом.
|
| | | |
Можно. 22.10.03 00:01
Автор: zelych Статус: Member
|
> Каким бы большим не был массив, его размера может не > хватить. > Каким бы маленьким не был массив, обязательно найдуться > неиспользуемые элементы.
кажется это основное свойство памяти - она частенько заканчивается..
а всякие списки и очереди здорово ударяют как по эффективности использования памяти, так и по производительности..
|
| | | |
Интересно ;-) 16.10.03 13:24
Автор: HandleX <Александр М.> Статус: The Elderman
|
> Пример: Напишите програмку, которая делает следующее - > последовательно вводятся числа (количество введенных чисел > немзвестно/неограничено), при вводе заранее оговоренного > числа программа должна выдать второе по максимальности > число (именно не самое максимальное, а второе по величине) > и закончить работу. > > Так и хочется завести массив, считывать циклически > введенные числа в последовательные ячейки массива, при > вводе ключевого числа вывалиться из цикла ввода, > отсортировать массив и выдать значение второго элемента. > Проблема в том, что надо обойтись без массива, поскольку > количество введенных чисел неограничено. Гы. Ну не знаю, мне не хочется ;-)
Program Sort;
Var aValue, Max, oldMax, stopValue: Integer;
Begin
Max := Low(Integer);
Write('Введите значение для остановки>');
ReadLn(stopValue);
Repeat
Write('Input value>');
ReadLn(aValue);
If aValue > Max Then
Begin
OldMax := Max;
Max := aValue;
End;
Until aValue = stopValue;
WriteLn('oldMax = ', oldMax, ', Max = ', Max);
WriteLn('Enjoy and good bye... There was no any arrays!');
End.
---
|
|
|