[C++] code style

> Зато это встроенный механизм, а не велосипед.

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

>если отказаться от rai (что на мой взгляд большое зло)

А не могли бы вы объяснить, что такое «rai» и почему это большое зло?

> тут никаких сверхусилий прикладывать не надо

Может не «сверх-», но надо. Надо помнить к примеру, что всё, что на букуву «м» - это должно быть членом класса и поэтому локальную переменную в методе нельзя называть на букву «м» - не поймут-с, и вместе с тем любую переменную-член класса надо называть на «м». Так что в коде будут исключены имена типа «mount_point». Надо либо «local_mount_point» либо «mmount_point».


:3

> А не могли бы вы объяснить, что такое «rai»

http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

Во-первых, это RAII

Во-вторых, это чуть ли не единственная годная фича в плюсах

> Во-первых, это RAII

А я с этим спорю?

это чуть ли не единственная годная фича в плюсах

Мне-то ты зачем это рассказываешь?

Не угадал. Питонер. self._private = ... =)

>если отказаться от rai (что на мой взгляд большое зло)

А не могли бы вы объяснить, что такое «rai» и почему это большое зло?

resource acquisition on initialization

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

PS это касается, в основном, С++

Может не «сверх-», но надо. Надо помнить к примеру, что всё, что на букуву «м» - это должно быть членом класса и поэтому локальную переменную в методе нельзя называть на букву «м» - не поймут-с, и вместе с тем любую переменную-член класса надо называть на «м». Так что в коде будут исключены имена типа «mount_point». Надо либо «local_mount_point» либо «mmount_point».

1) в случае с this для членов класса нужно помнить, что перед ними нужно писать this
2) члены класса пишутся либо начиная с m_, либо после m идет большая буква, так что mount_point - это очевидно локальная переменная, а не член класса

в общем, как я и говорил, усилий прикладывать не надо, а писать быстрее и удобнее, это в общем-то и определило, что в c++ this-> не рулит

> 1) в случае с this для членов класса нужно помнить, что перед ними нужно писать this

Наглое 4.2!! Ты можешь этого не помнит, и даже более того - вообще не писать.

либо начиная с m_, либо после m идет большая буква

Т.е. префикс аж из двух (!!) символов. Ололо.

помнить*

> Наглое 4.2!! Ты можешь этого не помнит, и даже более того - вообще не писать.

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

Т.е. префикс аж из двух (!!) символов. Ололо.

в this-> их вообще 7

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

«Метод исключения» в сочетании с практикой не создавать 100500 локальных переменных в коде легко и не принужденно решают эту «проблему». Не говоря уже об избежании таких идиотских ситуаций, как просмотр метода класса без предварительного просмотра его определения, что а-приори бессмысленно.

в this-> их вообще 7

И поэтому «this->» надо использовать тогда, когда этого требуется, как например в задаче ТС.

Всегда ваш, Кэп.

Тут тоже можно поспорить. Запись foo(&a) сразу говорит о том что «a» меняется.

Все верно, кроме этого в таком методе/функции этот параметр можно сделать необязательным:

void foo(int _a, int* _b = 0);

void foo(int _a, int* _b)
{
   m_a = _a;
   if(_b)
   {
      // do something useful with *_b
   }
}

The upcoming C++0x standard is due to make auto_ptr deprecated, replacing it with the unique_ptr class template.

http://en.wikipedia.org/wiki/Auto_ptr

в данной задаче это не важно

Интересно, а если переменная в поле «protected», тоже _ ?

> «Метод исключения» в сочетании с практикой не создавать 100500 локальных переменных в коде легко и не принужденно решают эту «проблему».

на словах оно всегда хорошо, только реальность отличается от идеальной картины

И поэтому «this->» надо использовать тогда, когда этого требуется, как например в задаче ТС.

гораздо проще всегда использовать m_ и не заморачиваться

Интересно, а если переменная в поле «protected», тоже _ ?

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

Ясно, спасибо.
Поскольку говорим о coding style. То вот ещё есть вопрос.
Насколько есть нормальным/ненормальным является использование выделение
памяти из стека путём void* malloc(size_t) в C++?
Я не нашел замены таким полезным функциям, как memmove(...), realloc(..) .
Недавно вот написал небольшой контейнер данных для своих нужд
(ссылки на WebSVN, длинные, но кода немного и с подсветкой):
xydata.h xydata.cpp qpointf.h
(эти 3 файла компилируются независимо от чего-либо, Qt4 можно использовать опционально)
Всюду использую функции void *realloc(void *ptr, size_t size); void *memmove(void *dest, const void *src, size_t n);

Насколько есть нормальным/ненормальным является использование выделение памяти из стека путём void* malloc(size_t) в C++?

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

Я не нашел замены таким полезным функциям, как memmove(...), realloc(..) .

memmove/memcopy используйте пожалста, только на POD типах данных

realloc, а на что он Вам? напишите свой, через new/delete, если что, там будет 2-3 строчки

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

Недавно вот написал небольшой контейнер данных для своих нужд

Всюду использую функции void *realloc(void *ptr, size_t size); void *memmove(void *dest, const void *src, size_t n);

ну, Вы там используете обычные c-style массивы, с ними такая техника работы может быть оправдана, но часто бывает так, что сложно отследить все нюансы, и, соответственно, легко допустить ошибку

я Вам рекомендую, в качестве эксперимента, попробовать заюзать std::vector<double> в качестве px и py

Спасибо за советы!

я Вам рекомендую, в качестве эксперимента, попробовать заюзать

std::vector<double> в качестве px и py

вот тот класс xydata_class и без того заталкивается в std::vector<xydata_class*> т.к. удобно там держать классы,
я подумал, что в случае дальнейшего изображения данных с «вектора векторов» на дисплее(т.е. каждый раз нужен доступ ко всем элементам массивов) это будет работать медленно, поэтому написал всё в C массивах.

Также привлекло это (man memmove):
void *memmove(void *dest, const void *src, size_t n);
The memmove() function copies n bytes from memory area src to memory area dest. The memory areas may overlap: copying takes place as though the bytes in src are first copied into a temporary array that does not overlap src or dest, and the bytes are then copied from the temporary array to dest.

memmove/memcopy используйте пожалста, только на POD типах данных

Использую его для обычного (double), PODходит :-)

> Насколько есть нормальным/ненормальным является использование выделение памяти из стека путём void* malloc(size_t) в C++

Боюсь вас разочаровать, но через malloc в _стеке_ ничего выделить нельзя.

> выделение памяти из стека путём void* malloc(size_t) в C++?

Если вычеркнуть упоминание про стек, то у new есть два главных преимущества глядя на которые malloc нервно курит в сторонке:

1) возвращаемое значение не требует приведения типов

2) автоматически вызываются конструкторы создаваемых объектов

Кроме этого в случае необходимости new можно и переопределить.

Недавно вот написал небольшой контейнер данных для своих нужд

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

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

Я подумал... Думать меньше нужно, соображать больше )))

может это не у new над malloc преимущество в том что не надо приводить возвращаемый указатель а просто в костыльном цепепе даже нужное как вохдух автоприведение из void * в другой тип и тот сделали через жопу требуя явного кастинга после того как попишеш на сишечке эта долбанутая говнофича плюсов ужасно бесит потому что в системной апи сплош и рядом функции возвращают void * в сишечке пролучается красивый код без кастинга а в цепепе говно напичканное кастингами и по другому то ненапишеш потому что добанутый страус или его подельники сказал а давай запретим автокастинг void * в другой тип мне вот интересно они видели какое говно получается с кастингами если писать на низком уровне хоть вставляй в проект отдельный модуль на сишечке и собирай там всю низкоуровневую работу

realloc, а на что он Вам? напишите свой, через new/delete, если что, там будет 2-3 строчки

если не требуется юзать new (обычные pod) то только извращенец заюзает new а потом будет писать свой аналог realloc через new delete мастер заюзает malloc и realloc

> просто в костыльном цепепе даже нужное как вохдух автоприведение из void * в другой тип

Такое автоприведение абсолютно не нужно т.к. в общем случае оно неправильное и чревато ошибками.

сделали через жопу требуя явного кастинга

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

после того как попишеш на сишечке эта долбанутая говнофича плюсов ужасно бесит

Эта фича тебе как бы намекает что ты говнодер и вот от этого ты и бесишься.

потому что в системной апи сплош и рядом функции возвращают void * в сишечке

Примеры где сплошь и рядом возвращают void * приведите.

просто в костыльном цепепе даже нужное как вохдух автоприведение из void * в другой тип

Такое автоприведение абсолютно не нужно т.к. в общем случае оно неправильное и чревато ошибками.

теоретикам вообще ничего не нужно

сделали через жопу требуя явного кастинга

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

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

после того как попишеш на сишечке эта долбанутая говнофича плюсов ужасно бесит

Эта фича тебе как бы намекает что ты говнодер и вот от этого ты и бесишься.

типичный дибил что еще сказать отупел от плюсов ?

потому что в системной апи сплош и рядом функции возвращают void * в сишечке

Примеры где сплошь и рядом возвращают void * приведите.

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

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

Хитрость выделения памяти заключается не в выборе между malloc/mmap/new/etc, а в организации структуры и управления участками памяти. То есть хитрость с гибкостью ортогональны базовому механизму выделения памяти.

memmove/memcopy используйте пожалста, только на POD типах данных

Не только POD. Фэйл будет только, если хранить в передвигаемом блоке взаимосвязанные по указателями ячейки (или внешние связи с ними). Вообще говоря перемещатор на базе new/delete тоже ничем не поможет, только кастомный алгоритм. Остальные объекты спокойно переживают memmove/memcmp.

realloc, а на что он Вам? напишите свой, через new/delete, если что, там будет 2-3 строчки

Сказочная глупость. Задача переместить данные, а не стопицот раз удалить и создать новые.

...

Основная фича new/delete в автоматическом вызове конструкторов и деструкторов. Когда это не требуется, начинают рулить malloc/free. И еще не забывайте, что всегда можно любым образом выделить блок памяти и вызвать на нем конструктор какого-то типа для инициализации и деструктор для финализации. Всякие vector (и в зависимости от аллокаторов) именно так и работают.

> Когда это не требуется, начинают рулить malloc/free

Расскажете почему malloc/free рулят по сравнению с new/delete?

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

За вызовом конструктора для выделенного блока памяти к кому обратитесь? Правильно к new )))

Проще говоря ни по одному из пунктов ты ничего сказать не можешь. Слив засчитан )))

да ты слепой баран тебе хоть ссы на лоб это для тебя божья роса будет или ты просто включил режим троля

> да ты слепой баран тебе хоть ссы на лоб это для тебя божья роса будет или ты просто включил режим троля

Беспомощный человек не годует. Слабак. Ха-ха-ха )))

>Расскажете почему malloc/free рулят по сравнению с new/delete?

В первую очередь потому, что позволяют делать realloc (memmove кстати на выделенных new объектах обычно тоже не делают). И как следствие из того, что не вызываются конструкторы, в общем случае выделение памяти будет чуть более быстрым.

За вызовом конструктора для выделенного блока памяти к кому обратитесь? Правильно к new )))

Разумеется. Но речь шла о способах выделении памяти, а new()T - лишь средство вызова конструктора.

какая ты все таки дибилушка

какая ты все таки дибилушка

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

Если для тебя type safety «долбанутая говнофича», то тебе уже ничто не поможет.

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

Если для тебя type safety «долбанутая говнофича», то тебе уже ничто не поможет.

ну ты и ослоеб даже комментировать такие тупые посты не хочется

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

школоло такое школоло

Если для тебя type safety «долбанутая говнофича», то тебе уже ничто не поможет.

сишники всю жизнь юзают автоконверт void * а какая то школьница говорит что им уже ничто не поможет (совершенно неясно почему она приравняла void * ко всему type safety в целом)

Кастуешь в тред фанатов m_depth и... m_Depth (и фэйсрукосуев.жпг)?

Хитрость выделения памяти заключается не в выборе между malloc/mmap/new/etc, а в организации структуры и управления участками памяти. То есть хитрость с гибкостью ортогональны базовому механизму выделения памяти.

непонятная фраза и ещё более непонятный вывод

Не только POD. Фэйл будет только, если хранить в передвигаемом блоке взаимосвязанные по указателями ячейки (или внешние связи с ними). Вообще говоря перемещатор на базе new/delete тоже ничем не поможет, только кастомный алгоритм. Остальные объекты спокойно переживают memmove/memcmp.

я Вас категорически не понимаю, поясните примером что-ли?

>realloc, а на что он Вам? напишите свой, через new/delete, если что, там будет 2-3 строчки

Сказочная глупость. Задача переместить данные, а не стопицот раз удалить и создать новые.

ну, сделайте сказочную умность, вот отсюда:

std::vector<MyClass> v;

Основная фича new/delete в автоматическом вызове конструкторов и деструкторов. Когда это не требуется, начинают рулить malloc/free.

о чём я и сказал

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

не стоит искусственно усложнять код, ни к чему хорошему это не приведёт

Всякие vector (и в зависимости от аллокаторов) именно так и работают.

а теперь почитайте что я написал