» Вопросы по программированию на C/С++

Код: char line_ch[3000];
...
delete line_ch;

gygant
1. Советую почитать, что такое delete и для чего он нужен, прежде чем втыкать его куда ни попадя) Может плохо кончиться
2. Причем тут гигабайты и терабайты, когда у вас уже стоит циферка - 3000 байт. Можете сколько угодно размеры файлов менять - циферка эта так и останется, никто ваш исходный код править не будет) Это размер строки файла, никак не зависящий от размера файла. Также советую при копировании все-таки проверять - хватит ли места на приемной стороне, для этого есть strcpy_s или можно свой макрос сделать.
3. К тому же я как то не впитал, зачем вообще нужен этот буфер. В line.c_str() вроде бы все есть, нужно ли еще куда-то копировать?

gygant

можно извратиться в одну строчку

std::copy(std::istream_iterator<std::string>(std::cin), std::istream_iterator<std::string>(), std::ostream_iterator(std::cout));

akaGM
хз.. у меня заработало и нормально

kotlomoy
1. Спасибо, почитаю обязательно.
2. Ну я по результату смотрю. 15-30 МБ текста обрабатывается и вылетает. Или не вылетает если сделать так. Я же не понимаю, почему так - вот и спросил. Если бы меня просто устраивала эта ситуация - плюнул бы и махнул рукой
3. Суперская мысль, отдельное спасибо. Еще cp58 на это намекал, но я не догнал, ему тоже спасибо

karakurt2
О_о ничотак))

need help...
Как вывести всю символьную строку, т.е. до конца памяти отведенной на строку, а не до нуль-термитора?
надеюсь меня поняли))
приведу пример:
есть строка char str[100]
в ней есть, допустим "1234asdf\0qwer5678"
вывод на экран у меня получается "1234asdf"
хочу видеть остальную часть, что для этого сделать?

kenny5705
За один прием не получится, надо выводить по очереди каждую часть

kenny5705
Может быть при обнаружении символа i=="\" и i+1=="0" вырезать (не копировать, а вырезать) предыдущий кусок строки до \ включительно в отдельную переменную, чтобы дальше считывание продолжить уже с 0 и дальше до следующего \0. Я бы так попробовал, сейчас просто другим занят, сорь.

kenny5705
например, так:

Код: #define STR_LEN 100

char str[STR_LEN] = "1234asdf\0qwer5678";

for (i = 0; i < STR_LEN; i++)
printf("%d --> %c\n", i, str[i]);

kenny5705

Код: for (int i=0;i<MAX_SIZE;i++)
    if (isprint(str[i]))
        printf("%c", str[i]);
    else
        if (!str[i])
            continue;
        else
            break;

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

А если ими оперировать как-то надо? Или в одну строку вывести?

cp58
Пишу в C++ Builder 6

gygant

Цитата:

Пишу в C++ Builder 6

Проверьте отладчиком, если умеете пользоваться тот цикл, есть подозрение, что компилятор решил по своему разместить буфер и положил в кучу, то есть сделал равносильным этому:
char *line_ch=new char[3000];

всем спасибо за примеры, завтра проверю...

Цитата:

только непонятно зачем...

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

возможно еще завтра вопросов придумаю

kenny5705
Ну раз уж пошла такая пьянка, предложу и я варианты)

Вариант 1

Код: ...
int i = 0;

while (i < BUF_LEN)
{
ptintf( "%s\n", &str[ i ] );
i += strlen( &str[ i ] ) + 1;
}
...

cp58
Честно говоря, я принял к сведению, что delete использовать не стоило. А также, что в c_str() хранится та же чарина, которую я просто дублировал. Все это учел, исправил, работает. Теперь моё внимание сконцентрировано на продолжении другой программы, там фильтрацию прикручиваю - сроки давят, завтра обещался показать начальству

gygant

Цитата:

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

это я пример привожу...

kenny5705

Цитата:

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

бинарные данные выводят на экран в виде их аски-кодов. для примера посмотри на какой-нибудь хекс-редактор или FAR...

что-то типа:
Код:
for (i = 0; i < STR_LEN; i++)
if (str[i] < 33)
printf("%2d --> %2Xh\n", i, (unsigned char)str[i]);
else
printf("%2d --> %c\n", i, str[i]);

akaGM
Не всегда, если например дамп 4 ГБ? Все строки искать долго.
kenny5705

Цитата:

да тут читаю бинарные данные с харда

Задачу следовало писать заранее.

Код: #define MAX_SIZE 0x100000
int i=0;
for (;i<MAX_SIZE;i++)
    !isprint(str[i])?:printf("%c", str[i]);

cp58

Цитата:

Не всегда, если например дамп 4 ГБ?

конечно не всегда... но 4 Гига на экран -- это уже перебор, хотя... пусть выводит...

Цитата:

Задачу следовало писать заранее.

а я всё равно не понял, на фига всё это надо...

сделал что хотел... благодарствую за помощь


Цитата:

бинарные данные выводят на экран в виде их аски-кодов. для примера посмотри на какой-нибудь хекс-редактор или FAR...

это само собой разумеется


Цитата:

printf("%2d --> %2Xh\n", i, (unsigned char)str[i])

а вот за это, отдельное спасибо, не знал что можно сразу в 16ном формате выводить


Цитата:

Задачу следовало писать заранее.

да это пока лишь часть той требуемой задачи... да и самому ее охота решить


Цитата:

а я всё равно не понял, на фига всё это надо...

как сделаю окончательно все что хотел, или застопорюсь где-нибудь, объясню поподробней

kenny5705
а вот матчасть надо учить...


Цитата:

застопорюсь где-нибудь, объясню поподробней

телеграмма:
"Волнуйтесь!
подробности письмом..."

Цитата:

а вот матчасть надо учить...

ну вот я ее и изучаю, только на реальных полезных примерах...

akaGM

Цитата:

конечно не всегда... но 4 Гига на экран -- это уже перебор, хотя... пусть выводит...

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

4 ГБ

Цитата:

да тут читаю бинарные данные с харда

если дни уже есть на харде, почему бы просто их не посмотреть, например, HexEdit'ом и
Цитата:

затем с помощью регулярных выражений искать нужные данные

, на фиг их из файла в файл гонять...

cp58

Цитата:

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

В файл действительно не стоит. Файл размера 4 Гб проще отобразить в память (весь файл будет трактован как большой массив), и искать в этом массиве что надо. Ведь этот механизм придуман именно для таких случаев

cp58

Цитата:

С ходу других объяснений не придумал, у вас есть?

Например, такое: компилятор не проверяет, что ему подсунули в delete.

TeXpert,akaGM
Возьмем ситуацию, у меня 1 Гигабайт памяти. Я получил некий дамп 4 ГБ и хочу найти e-mail адреса утерянные после того, как диск испортился.

Чтобы начать поиск через регулярные выражения мне придется отбросить все 0(и сделать конкатенацию строк). Все в память я загрузить не могу, поэтому я читаю блоками, ну пусть будет вся память в 1024 мегабайта, я произвожу операцию поиска в блоке, далее я освобождаю память, загружаю след. и т.д.
После этого я захотел найти еще что-то(ну забыл), операцию повторять?

Теперь по поводу неоптимальности хранения моего варианта на жестком диске.
isprint возвращает положительный результат только для 83 символов, что примерно равно 1/3 от общего числа возможных значений одного байта, получается что сохранится 1/3 общего объема дампа, не так уж и много, зато работать с этим файлом будет быстрей.

kotlomoy

Цитата:

Например, такое: компилятор не проверяет, что ему подсунули в delete.

А как работает delete вы представляете?

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

cp58
Цитата:

Возьмем ситуацию, у меня 1 Гигабайт памяти. Я получил некий дамп 4 ГБ и хочу найти e-mail адреса утерянные после того, как диск испортился

Да хоть 10 Гб --- система сама позаботится насчет деталей. Правда, подкачка будет весьма активной

Ещё раз: тебе не надо будет ни выделять буфера, ни считывать в память блоками, ни освобождать. Настоятельно советую почитать Рихтера

Кстати, у Рихтера и найдёшь примеры работы с такими файлами. Вообще, изучение исходников весьма иногда помогает

P. S. Как и ожидалось, в Linux' е существует тот же механизм, с тем же названием: Memory Mapped Files (отображение файлов на память) (mmap gcc ipc file)

TeXpert

Цитата:

Да хоть 10 Гб --- система сама позаботится насчет деталей. Правда, подкачка будет весьма активной

А вы знаете что ОС будет отлавливать #PF(page fault) исключение при каждом отсутствии страницы в памяти и загружать страницу с жесткого диска? Подгрузка программистом работает намного быстрее.
akaGM
Я предложил один из вариантов решения, возник вопрос зачем это надо ->

Цитата:

, на фиг их из файла в файл гонять...

Я ответил примером.

cp58
Цитата:

А вы знаете что ОС будет отлавливать #PF(page fault) исключение при каждом отсутствии страницы в памяти и загружать страницу с жесткого диска?

А вот представьте, знаю). И, уже писал --- у тебя не болит голова про все это. В твоем распоряжении --- массив байт, с которым, кстати, ты можешь работать с функциями типа str*
Цитата:

Подгрузка программистом работает намного быстрее

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

Впрочем, посравни сам

cp58

Цитата:

А как работает delete вы представляете?

Как работает delete я представляю. Но чтобы компилятор на этапе сборки проверял аргумент delete'а на корректность и выдавал ошибку компиляции еще до запуска программы - не представляю.