C/C++ linux разработчик. Ищу удалённую работу.

тебе прямая дорога к майклу видениусу )

>На данный момент наибольший опыт имеется в C/C++

>Понимание STL изнутри, опыт разработки аллокаторов, опыт использования boost::lexical_cast, boost::tokenizer, boost::filesystem

Анонимус не забывает!

Кому ты нужен с такими вопросами?

Ничего страшного в этих вопросах не вижу вообще.

Они демонстрируют твой недалёкий уровень. Особенно феерично с ();.

И в чём заключается недалёкость уровня? Сформулируй )

Банальное незнание языка.

На вопрос про скобки там никто так и не ответил. Сказали, что получилось объявление функции Zuzuzu z();, а не вызов конструктора Zuzuzu::Zuzuzu(), но как компилятор делает выбор между

1. Определением функции, возвращающей Zuzuzu.
2. Созданием автоматического объекта типа Zuzuzu с использованием конструктора Zuzuzu :: Zuzuzu()

Никто так и не ответил. Так что, вопрос не «банальный».

как компилятор делает выбор между

1. Определением функции, возвращающей Zuzuzu.
2. Созданием автоматического объекта типа Zuzuzu с использованием конструктора Zuzuzu :: Zuzuzu()

ё-ный стыд.

Почитай стандарт, хотя бы этот, 3.1 Declarations and definitions (стр. 31)

Знания языка - наверное редко у кого зазубренная копия стандарта, так что забывание какой-то тонкости у меня стыда не вызывает (-;

Названия реализованных проектов - конечно же тайна за семью печатями?

Нет, всего-лишь за шестью.

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

Ничего страшного нет в том, чтобы забыть о базовой, но очень редко используемой особенности языка. Как и в любом другом деле. Вот вы мне скажите, кто помнит целый стандарт С++ наизусть? Таких людей нет, даже среди авторов стандарта (-; Если вам никогда не приходило в голову попробовать явно указать вызов основного конструктора класса при создании автоматического объекта данного класса, то явно не оттого, что вы помните весь стандарт ) В такое нельзя поверить (-;

Это ты дома будешь втирать, что удаление объектов редко используемая часть. Она то как раз очень часто используемая. Либо ты не писал софта сложнее хелло ворлд. Значит еще хуже дела, раз так.

Я буду рад, если вы сможете ответить, в чём отличие выполнения оператора delete[] от delete для char *p = new char [ 1200 ];

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

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

delete-expression:
::opt delete cast-expression
::opt delete [ ] cast-expression

...

If it is not a null pointer value, in the first alternative (delete
object), the value of the operand of delete shall be a pointer to a
non-array object or a pointer to a subobject (1.8) representing a
base class of such an object (Clause 10). If not, the behavior is
undefined. In the second alternative (delete array), the value of the
operand of delete shall be the pointer value which resulted from a
previous array new-expression. If not, the behavior is undefined.

мдя. Ты не индус случаем, не? Как в анекдоте прям - неплохое резюме и _такие_ вопросы задаешь. А потом еще и споришь что «типа не в базе стандарта». Да блин, любой кто хоть что нить писал на плюсах знает, что скрывается под этими командами.

Объяснит кто-нибудь из хаящих меня, наконец, разницу между delete и delete[] конкретно для char *p = new char[ 1200 ]; без цитат стандарта, который, ясное дело, знает всё?

delete удаляет объект.

delete[] удаляет группу объектов, именуемую массивом.

Под объектом понимай экземпляр любого типа.

По стандарту если сделал someType *ptr = new someType[..], то и удалять его надо через delete[]. Там черным по белому так и написано.

Вопрос «а почему же delete не может и массивы грохать?» задавай уже дизайнеру языка.

не хитри. Ты задал другой вопрос:

Почему для ClassName* p = new ClassName(); рекомендуется вызывать «delete p;», а для «char *p = new char[1200];» рекомендуется вызывать «delete[] p;»

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

Олсо прошу прощения за некоторую грубость в моих постах сегодня до 12-00.

Ребята, я ведь не о разнице между delete и delete[] в целом спрашивал, а применительно к конкретному типу char!

выделение памяти под класс и под массив - разные вещи, особенно в debug-версии. Этим и отличается. Дальше думай сам.

>применительно к конкретному типу char!

Чем он так примечателен? Правила едины для всех.

Примечателен тем, что я не вижу разницы в работе delete и delete[] применительно к нему. А к правилам у меня вопросов нет.

>Объяснит кто-нибудь из хаящих меня, наконец, разницу между delete и delete[] конкретно для char *p = new char[ 1200 ]; без цитат стандарта, который, ясное дело, знает всё?

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

«delete p» в твоём примере может сделать что угодно. возможные сценарии (меняются от архитектуры к архитектуре, от компилятора к компилятору, от версии к версии)

когда выделяется память под массив менеджеру памяти надо где-то хранить размер блока. когда выделяется память под один объект - размер блока известен компилятору и может не сохраняться. Если бы new, new[], и delete и delete[] были тупо обёртками над malloc и free - проблем бы не было, но это сейчас редко когда так. «delete p» может пометить как свободный только первый из 1200 байт. Или даже первый байт из 4хбайтной переменной, хранящей длину блока памяти. Или дать ошибку invalid free, потому что в данной версии рантайма используются разные кучи для массивов и одиночных объектов (для уменьшения фрагментации). Или delete специально перегружен в этой программе. Да что угодно может пойти не так, нельзя это предугадать.

Да, вот, про debug-версию правильно подсказывают. Всякие там отступы, зануления, проверки границ и прочее.

>Примечателен тем, что я не вижу разницы в работе delete и delete[] применительно к нему

Ок.

for (int i = 0; i < 100500; i++) {
      char *ptr = new char[1048576];
      delete ptr;
}

Оформи, скомпиляй, открой htop и запусти. Удачи.

О, legolegs, спасибо! Но позврольте немного порассуждать )

Нормальные менеджеры памяти хрянят просто адрес куска и его размер. Ну как ещё? Не битовую карту же по всем БАЙТАМ держать? )) То есть, размер кусочка уже сохранён во время выполнения кода new. Зачем компилятору выводить размер освобождаемой памяти из типа операнда оператора delete, если размер уже есть? Я не пишу про менеджер памяти ОС, это относится и к нашему локальному менеджеру, который пилит большие блоки, выделенные через системный mmap2... То есть, если бы мы разрабатывали компилятор, зачем же нам из операНда delete выводить размер освобождаемой памяти?

Анонимус! Я скомпилил этот код, немного понизив бронебойность:

#include <iostream>
#include <string.h>

int main ( void )
{
    for (int i = 0; i < 50; i++)
    {
        char *ptr = new char[ 1024*1024*10 ];
        memset ( ptr, 0xff, 1024*1024*10 ); // to ensure memory usage.
        delete ptr;
    }

    char *ptr = new char[ 1024*1024*10 ]; // mark1
    memset ( ptr, 0xff, 1024*1024*10 );

    char c;
    std::cin >> c; // Wait.

    return 0;
}

В режиме ожидания нажатия клавиши, htop показывал, что выделено 12 MB (строка mark1)... Если mark1 и следущую убрать, будет выделено 2 MB. Цикл после себя 500 MB не оставил.

Я тебе уже все что ты должен хотел понять сказал. Но ты все о своем.

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

В стандарте языка не описаны и не могут быть описаны такие вещи как поведение менеджера памяти. Как то так.

т.е. вызовы С++ new/delete new[]/delete[] - сферические кони в вакууме, и malloc/free совсем не причем? :))))) Тогда как вообще процессу выделяется память, не важно на чем он писан? Кстати, если обратить внимание на изложения Страуструпа, он все время повторяется - «зависит от реализации», что собсно подтверждается в реализации MSVC для delete/delete[] код один

>в реализации MSVC для delete/delete[] код один

Пруфлик показал бы хоть

> Пруфлик показал бы хоть

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

именно. Более того тупая перегрузка new/new[] delete/delete[] с помощью malloc free работает корректно

>Нормальные менеджеры памяти хрянят просто

Нормальные менеджеры памяти

просто

/0

Зачем компилятору выводить размер освобождаемой памяти из типа операнда оператора delete, если размер уже есть?

Затем, что память надо экономить.

Я не пишу про менеджер памяти ОС

Само собой.

Суть в том, что ты не можешь быть уверен, что delete, delete[] и free взаимозаменяемы. А раз не уверен, то и рисковать попусту ни к чему.

А почему она должна была бы работать не корректно?

> т.е. вызовы С++ new/delete new[]/delete[] - сферические кони в вакууме, и malloc/free совсем не причем?

Зависит от реализации. В g++ malloc/free совсем ни причём.

>Зависит от реализации. В g++ malloc/free совсем ни причём.

Да неужели? Чисто для эксперимента определи в приложении extern «C» void *malloc(size_t size) и вызови new. Узнаешь что-то новое.

#include <stdio.h>
#include <stdlib.h>

extern "C" void *__libc_malloc(size_t size);

extern "C" void *malloc(size_t size)
{
    printf("Allocating %u bytes\n", (unsigned)size);
    return __libc_malloc(size);
}

int main()
{
    char *data = new char[10];
    delete []data;
    return 0;
}

legolegs

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

Я ковырял исходники. Ну может плохо ковырял :) Но это всё равно детали реализации.

>А напиши что-нибудь на тему экономии памяти

Вечером в пятницу? Нет уж.

>Но это всё равно детали реализации.

Ну, в общем, да. Особенно с учетом перегрузки new/delete.

Как ни крути а упрешься в malloc и free. ибо системные вызовы

>malloc и free. ибо системные вызовы

Не путаем стандартную библиотеку си и системные вызовы.

смысл ясен, не суть

Как ни крути а упрешься в malloc и free. ибо системные вызовы

системные вызовы

4.2

> Вечером в пятницу? Нет уж.
Когда будет время.

>>системные вызовы

4.2

(s)brk и mmap, если быть точнее. В win32 может быть вообще HeapAlloc?

linuxfan, а твоё определение malloc почему не конфликтует с уже имеющимся?