Страница 1 из 4
ну чего, по-флеймим малек ?
Добавлено: 10 янв 2007, 23:27
ajkj3em
имеем два класса, оба описывают кусок памяти в хипе. спрашиваетcя,
какой вариант более кошерный чисто с точки зрения дизайна кода ..
то есть без учета перформанса, битности char, и т.п.
Код: Выделить всё
struct foo
{
char * ptr; // first byte of the block
char * end; // the byte after the last byte of the block
};
Код: Выделить всё
struct bar
{
char * ptr; // first byte
size_t len; // the size of the block
};
size_t as per <stddef.h>
Re: ну чего, по-флеймим малек ?
Добавлено: 10 янв 2007, 23:33
nemiga
ajkj3em писал(а):
struct foo
{
char * ptr; // first byte of the block
char * end; // the byte after the last byte of the block
};[/code]
Код: Выделить всё
struct bar
{
char * ptr; // first byte
size_t len; // the size of the block
};
// size_t as per <stddef.h>[/quote]
Мне нравится второй. Сам так писал.
.
Добавлено: 11 янв 2007, 08:17
Stanislav
Второй конечно
Все мувы работают с указателем и размером. В принципе и в первом случае - вычисляемо - но это гланды через ж... как в том анекдоте
Добавлено: 11 янв 2007, 09:55
dima
почти все APIs (и системные финкции) передают указатель на начало памяти и длинну в байтах.
Используй второй.
Добавлено: 11 янв 2007, 10:22
ajkj3em
dima писал(а):почти все APIs (и системные финкции) передают указатель на начало памяти и длинну в байтах.
Используй второй.
спасибо за ц.у., но оно мне не нужно :)
вопрос был почему один вариант лучше другого с точки зрения
абстрактного дизайна структур данных, без привязки к каким
бы то нибыло API
Добавлено: 11 янв 2007, 10:30
Marmot
А как преполагается это дело использовать?
Use-cases, так-сказать давай...
Хотя чисто интуитивно, мне второй вариант больше нравится, потому как он более традиционен...
Опять же всякие там network protocols многие так сделаны (BTW авторов HTTP надо приговорить к расстрелу, IMO
)
Добавлено: 11 янв 2007, 10:42
ajkj3em
Marmot писал(а):А как преполагается это дело использовать?
Use-cases, так-сказать давай...
hint нумер 1 - use-cases не принципиальны.
Добавлено: 11 янв 2007, 10:45
aissp
В первом случае максимальный размер блока будет только 2 гига когда во втором ажно 4
Добавлено: 11 янв 2007, 10:50
Marmot
ajkj3em писал(а):
hint нумер 1 - use-cases не принципиальны.
Ну тады всеравно нумбер два.
Чтобы второй указатель по ногами не болтался, а то кто нибудь захочет туда чего нибудь прописать...
Чисто для защиты от совсем дураков...
Добавлено: 11 янв 2007, 10:59
ajkj3em
marmot, получай пирожок :)
правильный ответ - во втором случае у структуры нет инварианта
Добавлено: 11 янв 2007, 11:20
aissp
Common
struct MemChunk {
size_t len;
char* block;
char* next;
}
Спрашивается что тут делает нехт?
если идиот может туда чего записать:) И есть ли тут инвариант с точки зрения чунка?
Добавлено: 11 янв 2007, 11:22
Marmot
ajkj3em писал(а):
правильный ответ - во втором случае у структуры нет инварианта
Пппереведи...
Добавлено: 11 янв 2007, 11:52
nemiga
ajkj3em писал(а):правильный ответ - во втором случае у структуры нет инварианта
Нифига себе. Я и словей (т.е., словов) таких не знаю
Но как-то интуитивно выбрал правильный вариант...
.
Добавлено: 11 янв 2007, 12:05
ajkj3em
aissp писал(а):Common :)
struct MemChunk {
size_t len;
char* block;
char* next;
}
Спрашивается что тут делает нехт? :) если идиот может туда чего записать:) И есть ли тут инвариант с точки зрения чунка? :)
инвариант здесь -
Добавлено: 11 янв 2007, 12:16
ajkj3em
Marmot писал(а):ajkj3em писал(а):
правильный ответ - во втором случае у структуры нет инварианта
Пппереведи...
инвариант - вто condition(s), который накладываетcя на содержимое
обьекта данных, чтобы он был в consistent/valid state. чем меньше у
класса инвариантов, тем лучше, потому что меньше шансов попасть
впросак.
более того, старик страуструп любит говорить, что
class should enforce invariant -
My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class
у первой структуры есть инвариант -
у второй - инвариантов нет (size_t is unsigned as per standard).