LINUX.ORG.RU

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


0

0

Здравствуйте!

На данный момент наибольший опыт имеется в C/C++ - разработке серверных многопоточных backend-приложений для высоконагруженных проектов, выполняющих роль специализированных СУБД. Очень интересует работа в области разработки СУБД, задачи, связанные с подбором или разработкой алгоритмов, структур данных, нестандартных решений, с вдумчивой проработкой базовых деталей систем.

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

Опыт:
- работы с POSIX sockets, pthreads, epoll, libcurl, libmysql, FastCGI, Qt, xlib, MySQL, PostgreSQL.
- реализации собственных сетевых протоколов, синтаксических анализаторов, интерпретатора простого скриптового языка.
- проектирования распределённых систем, применения MapReduce.

Английский - письменный и устный.

Пишите пожалуйста на:

mriadus
gmail
com

Телефон: +7 921 57 98 994

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

heisenberg ★★ ()

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

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

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

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

anonymous ()
Ответ на: комментарий от mriadus

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

anonymous ()
Ответ на: комментарий от anonymous

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

mriadus ()
Ответ на: комментарий от anonymous

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

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

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

mriadus ()
Ответ на: комментарий от mriadus

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

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

ё-ный стыд.

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

anonymous ()
Ответ на: комментарий от anonymous

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

mriadus ()

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

anonymous ()

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

Pantserovik ()
Ответ на: комментарий от Pantserovik

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

mriadus ()
Ответ на: комментарий от mriadus

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

Pantserovik ()
Ответ на: комментарий от Pantserovik

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

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

mriadus ()

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

heisenberg ★★ ()
Ответ на: комментарий от mriadus

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.

anonymous ()
Ответ на: комментарий от mriadus

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

FollowTheRabbit ()
Ответ на: комментарий от FollowTheRabbit

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

mriadus ()
Ответ на: комментарий от mriadus

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

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

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

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

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

anonymous ()
Ответ на: комментарий от mriadus

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

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

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

FollowTheRabbit ()
Ответ на: комментарий от mriadus

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

anonymous ()
Ответ на: комментарий от anonymous

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

mriadus ()
Ответ на: комментарий от mriadus

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

FollowTheRabbit ()
Ответ на: комментарий от mriadus

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

mriadus ()
Ответ на: комментарий от mriadus

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

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

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от legolegs

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

legolegs ★★★★★ ()
Ответ на: комментарий от mriadus

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

Ок.

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

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

anonymous ()
Ответ на: комментарий от anonymous

О, 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 не оставил.

mriadus ()
Ответ на: комментарий от mriadus

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

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

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

FollowTheRabbit ()
Ответ на: комментарий от legolegs

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

PETER ★★ ()
Ответ на: комментарий от PETER

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

ahonimous ()
Ответ на: комментарий от ahonimous

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

PETER ★★ ()
Ответ на: комментарий от mriadus

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

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

просто

/0

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

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

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

Само собой.

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

legolegs ★★★★★ ()
Ответ на: комментарий от PETER

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

LamerOk ★★★★★ ()
Ответ на: комментарий от PETER

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от legolegs

>Зависит от реализации. В 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;
}
linuxfan ()
Ответ на: комментарий от legolegs

legolegs

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

mriadus ()
Ответ на: комментарий от linuxfan

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

legolegs ★★★★★ ()
Ответ на: комментарий от mriadus

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от legolegs

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

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

linuxfan ()
Ответ на: комментарий от legolegs

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

PETER ★★ ()
Ответ на: комментарий от PETER

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

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

legolegs ★★★★★ ()
Ответ на: комментарий от PETER

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

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

4.2

Dudraug ★★★★★ ()
Ответ на: комментарий от Dudraug

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

4.2

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

linuxfan ()
Ответ на: комментарий от linuxfan

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

mriadus ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.