Форум на Исходниках.RU

Вопрос к программистам на C

Flex Ferrum — Fri, 28 Jul 2006 11:17:24 +0000

Flex Ferrum:

Цитата linuxfan @ 28.07.06, 11:06

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

Ну в С++ с этим тоже не все так плохо. В С++ у тебя есть выбор - использовать временные объекты, или обходится без них. Т. е. никто мне не мешает написать так:

с4 += с[0];

c4 += c[1];

c4 += c[2];

c4 += c[3];

Таким образом я буду гарантирован от создания временных переменных (все передается по ссылке). А могу переложить работу по созданию хранению промежуточных результатов на компилятор и написать так, как было написано (c[0] + c[1] + c[2] + c[3]).

Вопрос к программистам на C

linuxfan — Fri, 28 Jul 2006 11:06:44 +0000

linuxfan:

Цитата Flex Ferrum @ 28.07.06, 10:50

А я - именно операции +, которая возвращает новый результат.

Посколькольку в C за меня никто не будет заниматься уничтожением временных объектов, такая реализация конкатенации "вполне в духе времени" :)
Ничто не не помешает мне, например, сделать так:

vector_conctat(&res1,a,vector_concat(&res2,b,c))

Вопрос к программистам на C

Flex Ferrum — Fri, 28 Jul 2006 10:50:22 +0000

Flex Ferrum:

Цитата linuxfan @ 28.07.06, 10:42

В конечном итоге все равно ведь пришлось отказаться от перегрузки оператора '+', т. к. лишний оверхед, а?

Не совсем так (ИМХО). Ты решил заменить "серийный" плюс (т. е. когда в одном выражении несколько операторов) на одну функцию, оптимизированную конкретно для этой задачи. Но (при этом) ты не можешь в одном выражении сделать, например, и конкатенацию и (ну предположим) векторное умножение или сложение векторов. Тебе все равно надо будет вводить временные "вектора", в которых ты будешь хранить промедуточные результаты.

Цитата linuxfan @ 28.07.06, 10:42

А как же копирование результата (конечно, легко исправляется добавлением еще одного аргумента в accumulate).

Дело в том, что ты реализовал аналог оператора +=, который модифицирует левый аргумент. А я - именно операции +, которая возвращает новый результат. В итоге я могу, например, сделать так:

c4 = accumulate((my_va_list<TestClass1>(0), 1, 2, 3, 4, 6, 7, 8, 9));

Т. е. сконкатенировать чисто константные значения (экземпляры) класса. А тебе нужен хотя бы один неконстантный.

Добавлено 28.07.06, 10:51
ЗЫ: А идею с таким переменным списком аргументов нужно будет довести до ума...

Вопрос к программистам на C

linuxfan — Fri, 28 Jul 2006 10:42:08 +0000

linuxfan:

Цитата Flex Ferrum @ 28.07.06, 10:29

Вот что будет, если я (в твоем варианте) забуду в качестве последнего параметра передать NULL?

Скорее всего, signal 11 ;)

Цитата Flex Ferrum @ 28.07.06, 10:29

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

А как же копирование результата (конечно, легко исправляется добавлением еще одного аргумента в accumulate).

В итоге мы пришли к тому, что я писал свой мини-вектор, а ты писал передачу переменного числа аргументов. Но, честно сказать, у меня велосипед побольше (в смысле объема кода) и пошустрее (потому что memcpy), а у тебя универсальней (потому что и не для POD покатит). В конечном итоге все равно ведь пришлось отказаться от перегрузки оператора '+', т. к. лишний оверхед, а? ;)

Вопрос к программистам на C

Flex Ferrum — Fri, 28 Jul 2006 10:29:32 +0000

Flex Ferrum:

Цитата linuxfan @ 28.07.06, 09:48

Раз нам всегда точно известно, что складывать, то почему бы не сделать функцию с переменным числом аргументов? Оверхеда практически 0%. Подходит исключительно для того, что в C++ называют POD-типами. Но вроде как ставилась задача исследования рантаймового оверхеда?

Хитрец. :) Подожди пару сек. Вот, что получилось у меня (код, в принципе, аналогичен твоему, только гораздо более безопасный):

template<typename T> struct va_list_t

{

typedef va_list_t<T> this_type;

va_list_t(const T& v) : m_Val(&v), m_Next(NULL), m_Prev(NULL) {;}

va_list_t(const T& v, this_type& prev) : m_Val(&v)

{

prev.m_Next = this;

m_Prev = &prev;

m_Next = NULL;

}

const T* m_Val;

this_type* m_Next;

this_type* m_Prev;

friend this_type operator, (this_type& prev, const T& v)

{

return this_type(v, prev);

}

};

template<typename T> va_list_t<T> my_va_list(const T& v)

{

return va_list_t<T>(v);

}

TestClass1 accumulate(const va_list_t<TestClass1>& args)

{

size_t count = 0;

const va_list_t<TestClass1>* real_head = NULL;

for (const va_list_t<TestClass1>* head = &args; head != NULL; real_head = head, head = head->m_Prev)

{

count += head->m_Val->GetContainer().size();

}

TestClass1 ret_val;

ret_val.GetContainer().reserve(count);

for (const va_list_t<TestClass1>* head = real_head; head != NULL; head = head->m_Next)

{

ret_val += *head->m_Val;

}

return ret_val;

}

int main(int argc, char**)

{

TestClass1 c[5] = {

TestClass1(1),

TestClass1(2),

TestClass1(3),

TestClass1(4),

TestClass1(5)

};

TestClass1 c4;

c4 = accumulate((my_va_list(c[0]), c[1], c[2], c[3], c[4]));

c4.Print();

return 0;

}

Тут оверхед - это связывание списка, эмулирующего переменное количество аргументов. Но, ИМХО, оверхед оправдан тем, что в итоге мы точно знаем - где, что и сколько лежит. :) И не накосячим с точки зрения типов. Вот что будет, если я (в твоем варианте) забуду в качестве последнего параметра передать NULL?

Вопрос к программистам на C

linuxfan — Fri, 28 Jul 2006 09:48:23 +0000

linuxfan: Поскольку вектора в стандартной библиотеке C нет, то выглядело бы это примерно так (valid C99):

#include <stdio.h>

#include <stdlib.h>

#include <stdarg.h>

#include <string.h>

#define ELEMENT_FMT "%i"

typedef int velement_t;

struct vector_t {

size_t count;

velement_t *data;

};

void vector_init(struct vector_t *self)

{

self->count = 0; self->data = NULL;

}

velement_t* vector_push(struct vector_t *self,velement_t value)

{

velement_t *old_data = self->data;

self->data = (velement_t*)realloc(self->data,(self->count+1)*sizeof(velement_t));

if (self->data) {

self->data[self->count] = value;

self->count++;

return self->data+(self->count-1);

} else {

self->data = old_data;

return NULL;

}

struct vector_t* vector_concat(struct vector_t *self,...)

{

va_list arg;

int grow = 0;

/* Precalculate number of elements being appended */

va_start(arg,self);

for (struct vector_t* v = va_arg(arg,struct vector_t*); v; v = va_arg(arg,struct vector_t*)) {

grow += v->count;

}

va_end(arg);

/* Append elements */

if (grow > 0) {

velement_t *ptr = self->data;

self->data = (velement_t*)realloc(self->data,(self->count+grow)*sizeof(velement_t));

if (!self->data) {

self->data = ptr;

return NULL;

}

ptr = self->data + self->count;

va_start(arg,self);

for (struct vector_t* v = va_arg(arg,struct vector_t*); v; v = va_arg(arg,struct vector_t*)) {

memcpy(ptr,v->data,v->count*sizeof(velement_t));

ptr += v->count;

}

va_end(arg);

self->count += grow;

}

return self;

}

void vector_print(struct vector_t *self)

{

putchar('{');

for (int i=0; i<self->count; i++) {

if (i < self->count-1) {

printf (ELEMENT_FMT ", ",self->data[i]);

} else {

printf (ELEMENT_FMT, self->data[i]);

}

puts("}");

}

int main()

{

struct vector_t res,v[5];

vector_init(&res);

for (int i=0; i<5; i++) {

vector_init(&v[i]);

vector_push(&v[i],i+1);

}

vector_concat(&res,v,v+1,v+2,v+3,v+4,NULL);

vector_print(&res);

return 0;

}

Вопрос к программистам на C

Flex Ferrum — Fri, 28 Jul 2006 08:43:00 +0000

Flex Ferrum: linuxfan, вообще, все очень сильно зависит от оптимизатора. И его возможностей. Кстати, мне (как и LuckLess'у) интересно посмотреть - сколько будет оверхеда в аналогичном коде на С. Т. е. сформулируем задачку так. Нам нужно написать операцию конкатенации (даже не сложения) двух векторов. На С++ я набросал такой код:

class TestClass1

{

std::vector<int> m_Vec;

public:

TestClass1() {;}

TestClass1(int v)

{

m_Vec.push_back(v);

}

TestClass1& operator += (const TestClass1& c)

{

m_Vec.insert(m_Vec.end(), c.m_Vec.begin(), c.m_Vec.end());

return *this;

}

friend TestClass1 operator + (TestClass1 c1, const TestClass1& c2)

{

//std::cout << "c1 = " << &c1 << ", c2 = " << &c2 << std::endl;

return c1 += c2;

}

void Print()

{

std::copy(m_Vec.begin(), m_Vec.end(), std::ostream_iterator<int>(std::cout, " "));

}

};

int main(int argc, char**)

{

TestClass1 c[5] = {

TestClass1(1),

TestClass1(2),

TestClass1(3),

TestClass1(4),

TestClass1(5)

};

TestClass1 c4;

c4 = c[0] + c[1] + c[2] + c[3] + c[4];

c4.Print();

return 0;

}

Как выглядел бы аналогичный код на С?

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 19:57:38 +0000

linuxfan: Я не знаю ни COM ни WinAPI :) Меня кормит Linux :)

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 19:32:19 +0000

LuckLess: Ну давай поиграемся с COM :D

Навай WinAPI + Чистый язык.

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 19:27:04 +0000

linuxfan: Ну на "чистом" языке проблематично реализовать что-либо отличное от примитивной однопоточной числодробилки, а на таких задачах я не вижу преимущества ни одного из языков.
Думаю, что очень сложно придумать такую демо-задачу.

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 19:08:54 +0000

LuckLess:

Цитата linuxfan @ 27.07.06, 19:06

А пример сходу придумать сложно. Ведь в крайнем случае можно в C++ всегда написать точно так же как и в C.

Чистый С++ как и Чистый С(С99).
на С++ собстно будут использоватся STL и ООП в разумных ессесно пределах.
на С соответственно сруктурное программирование и сишная библиотека.

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 19:06:45 +0000

linuxfan:

Цитата LuckLess @ 27.07.06, 18:53

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

Именно так.
А пример сходу придумать сложно. Ведь в крайнем случае можно в C++ всегда написать точно так же как и в C. Или мы ограничиваемся чистым C++? :) Тогда прошу уточнить степень "чистоты" :)
Потому как есть некоторые нестандартизованные стандартом трюки (alloca, например -- в чистом C++ подобных вещей вообще нет), за счет которых "не совсем чистый" C может вырваться вперед.

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 18:53:55 +0000

LuckLess:

Цитата linuxfan @ 27.07.06, 18:45

Ну так это один из провалов идеологии C++. Импиративная парадигма с A& sum(const A&,const A&,A&) тут гораздо оптимальнее.

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

class BigObject

{

private:

bool temp;

std::vector<int> BigBuffer;

public:

BigObject () : temp(false){}

BigObject operator+ (const BigObject& obj)

{

BigObject tempObj(obj);

//тут сложение.

tempObj.temp = true;

return tempObj;

}

BigObject& operator= (BigObject& bf)

{

if (bf.temp)

BigBuffer.swap (bf.BigBuffer);//очень быстро выполняется

else

BigBuffer.assign (bf.BigBuffer.begin(), bf.BigBuffer.end());//копирование данных

}

};

и вообще. давай уже покажи где оверхед в СРАВНЕНИИ с С!
покажи код(а не надуманный пример) на С который сложно написать на С++ не потеряв в производительности.

Добавлено 27.07.06, 18:58
вообще такого рода проблема - это не проблема С++ а проблема архитектуры в целом.
если бы возвращаемое значение передавалось не через регистр. а вместо этого в вункцию push-ился доп. параиетр с адремов того мета, куда надо вернуть значение, то былоб значительно оптимальней.

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 18:45:15 +0000

linuxfan: Ну так это один из провалов идеологии C++. Импиративная парадигма с A& sum(const A&,const A&,A&) тут гораздо оптимальнее.
Надо пример объектов, для которых такое поведение operator+ проблема? std::string. Там неспроста с прокси-объектами и подсчетом ссылок заморачивались. Без gc с памятью при таком поведении операторов один геморрой (скажем спасибо boost::shared_ptr :))

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 18:35:14 +0000

LuckLess:

Цитата linuxfan @ 27.07.06, 18:30

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

Он и возвращает сразу lvalue для рядом стоящего присваиваня.
и это присваивание это лвалуе использует.

да, для присвоения и operator+ есть незначительный оверхед.
но кто использует большие обхекты с operator+ в связке??
ну тут дело рук опять в общем :D

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 18:30:54 +0000

linuxfan:

Цитата LuckLess @ 27.07.06, 18:21

Я тебе дал пример с копированием.

Ну пардон, если я некорректно выразился. Я-то имел ввиду именно присваивание при использовании бинарного оператора. Там оверхед в создании временного объекта для хранения результата операции. По уму бы хотелось так:

....

const A& operator +(const A& arg,A& res) {

/* складываем как-нибудь *this и arg, помещая значение в res */

return res;

}

Но такая запись добавляет дополнительных хлопот по возможной очистке предварительной результата, но избегает создания временного объекта. пусть бы лучше компилер озабачивался выбором res: либо временный объект, либо сразу lvalue для рядомстоящего присваивания.

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 18:21:36 +0000

LuckLess:

Цитата linuxfan @ 27.07.06, 18:07

Вот тебе и оверхед: Два временных объекта, потому что operator + .

подругому сделать нельзя никак. оверхеда тут нет, так как оверхед == лишнее действие, а тут лишнего ничего нет.
хочеш подругому - использую функции и ссылки или operator+=.

Добавлено 27.07.06, 18:22

Цитата linuxfan @ 27.07.06, 18:07

я тебе внушаю, что оверхед именно на копировании при '+' вызывается.

Я тебе дал пример с копированием.
ты дал пример не с копированиема с присвоение.

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 18:07:23 +0000

linuxfan: LuckLess, видимо ты меня не понимаешь: я тебе внушаю, что оверхед именно на копировании при '+' вызывается.

#include <iostream>

class A

{

public:

static bool silent;

A() {if (!silent) std::cout << "def\n";}

A(const A&) {if (!silent) std::cout << "copy\n";}

const A operator+ (const A &arg)

{

A res;

if (!silent) std::cout << "operator +\n";

return res;

}

A& operator= (const A&) {

if (!silent) std::cout << "operator = \n";

return *this;

}

};

bool A::silent = true;

int main()

{

A a1,a2;

A a3;

A::silent = false;

std::cout << "First pass\n";

a3 = a1 + a2;

std::cout << "Second pass\n";

a3 = a1 + a2;

return 0;

}

Вот результат от gcc:

First pass

def

operator +

operator =

Second pass

def

operator +

operator =

Вот тебе и оверхед: Два временных объекта, потому что operator + . Или ты думаешь, что написал изотерическое сложение гипотетического хрена с несуществующей редькой и доказал высокую эффективность C++?

Цитата LuckLess @ 27.07.06, 17:30

И более чем уверен что такое извращение в серъезных проектах не используют.

Конечно нет. Но ведь можно же.

Добавлено 27.07.06, 18:08
В серьезных проектах макросы иногда используют, чтобы избежать копипаста.

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 17:30:05 +0000

LuckLess:

Цитата BugHunter @ 27.07.06, 17:29

обычно присваивание отличается от конструктора копирования только тем, что возвращает const A &.

у присвоения A& возвращается...
int a,b,c;
(a = b) = c;

Добавлено 27.07.06, 17:31
linuxfan
На вот тебе такой код.. а то подумаеш еще что там operator= вызовется..

class A

{

public:

A() {std::cout << "def\n";}

A(const A&) {std::cout << "copy\n";}

A operator+ (const A&)

{

return A();

}

A& operator= (const A&)

{

std::cout << "=\n";

return *this;

}

};

int main()

{

A a1,a2;

A a3 = a1 + a2;

}

Добавлено 27.07.06, 17:33

Цитата linuxfan @ 27.07.06, 17:10

Лень :P Или ты не веришь, что можно написать qsort макросом?

Верю. Но я бы не хотел пользоваться программой(тем более ОС) в которой сортировка делается при помощи макроса.
И более чем уверен что такое извращение в серъезных проектах не используют.

Вопрос к программистам на C

BugHunter — Thu, 27 Jul 2006 17:29:01 +0000

BugHunter:

Цитата

Там же не присваивание, а конструктор копирования

:)
обычно присваивание отличается от конструктора копирования только тем, что возвращает const A &.
И то это делать необязательно, а лишь для ситуаций, когда нам хочется писать a = b = c;

Добавлено 27.07.06, 17:29
(тфу ты блин, Неудачник опередил)

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 17:26:51 +0000

LuckLess:

Цитата linuxfan @ 27.07.06, 17:10

Разводишь меня чтоли? Там же не присваивание, а конструктор копирования. Такое можно (и нужно) оптимизировать. Ты мне соптимизируй a = b + c.

Не развожу. Что тебе запустить уже лдень да?? Так вот.. если лень, то скажу так.. конструктор копирования не выполняеться.. 3 раза выполняется конструктор по умолчанию и ВСЕ!

Вопрос к программистам на C

BugHunter — Thu, 27 Jul 2006 17:26:26 +0000

BugHunter: Ну, если ты враг народа, то давай писать макросами :yes:

Вопрос к программистам на C

linuxfan — Thu, 27 Jul 2006 17:10:21 +0000

linuxfan:

Цитата LuckLess @ 27.07.06, 16:53

Ооочень интересно. ты про оптимизацию возвращаемого значения слышал? Нет? Ну тогда ясно..

Цитата LuckLess @ 27.07.06, 16:53

Ну изобрази.. сравним кто шустрее.

Лень :P Или ты не веришь, что можно написать qsort макросом?

Вопрос к программистам на C

LuckLess — Thu, 27 Jul 2006 16:53:56 +0000

LuckLess:

Цитата linuxfan @ 26.07.06, 10:38

Пример? Пожалуйста: бинарные операторы (+,-,*,/,&,| и т.д.) должны вернуть значение, после чего при присваивании произойдет копирование этого значения в результат. Т. е. запись

MyClass a,b,c;

/*инициализируем b и c */

a = b+c;

Цитата

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

Да ну временное значение?? Копирование?
Ооочень интересно. ты про оптимизацию возвращаемого значения слышал? Нет? Ну тогда ясно..
эту оптимизацию даже в режиме дебаг не выклчиш(в студии 8-й)

class A

{

public:

A() {std::cout << "def\n";}

A(const A&) {std::cout << "copy\n";}

A operator+ (const A&)

{

return A();

}

};

int main()

{

A a1,a2;

A a3 = a1 + a2;

}

Цитата linuxfan @ 26.07.06, 10:38

Какие языки кроме C/C++ ты знаешь, чтобы выдвигать столь смелое утверждение?

А зачем мне еще что знать для сравнения С и С++ ??

Цитата linuxfan @ 26.07.06, 10:38

Можно. qsort пишется макросом в заголовке, в качестве аргумента передается inline-функция для сравнения.

Ну изобрази.. сравним кто шустрее.

Вопрос к программистам на C

Flex Ferrum — Thu, 27 Jul 2006 07:42:13 +0000

Flex Ferrum:

Цитата BugHunter @ 26.07.06, 21:41

Flex, не занимайся фигнёй, Шад практик, но не теоретик, его всякими э.. софизмами не купишь :).

Ну а раз практик (а не теоретик), то зачем к стандартам пытается аппелировать?

Цитата BugHunter @ 26.07.06, 21:41

Займёмся лучше делом. За компиляторы, господа.

Что-то сишная сторона притихла... :) Наверное, задачи придумывают.... :)

Вопрос к программистам на C

BugHunter — Wed, 26 Jul 2006 21:41:56 +0000

BugHunter: Flex, не занимайся фигнёй, Шад практик, но не теоретик, его всякими э.. софизмами не купишь :).
Займёмся лучше делом. За компиляторы, господа.

Добавлено 26.07.06, 21:42
!!!

Вопрос к программистам на C

trainer — Wed, 26 Jul 2006 11:59:29 +0000

trainer: Кстати, а почему это IEEE подкомитет ISO? Это вроде две разные организации.
http://www.ieee.org About the IEEE IEEE history
http://www.iso.org Технические комитеты ISO

Добавлено 26.07.06, 12:04
Подкомитеты ISO, занимающиеся информационными технологиями называются ISO JTC1/SCxx

Вопрос к программистам на C

Flex Ferrum — Wed, 26 Jul 2006 11:50:01 +0000

Flex Ferrum:

Цитата the_Shadow @ 26.07.06, 11:43

А другого ты не видел? К примеру, того, что POSIX есть tm ISO?

Звизеж.

Цитата

POSIX ® is a registered Trademark of The IEEE.

Взято из футера к POSIX. Ты сам говорил, что IEEE - это подкоммитет ISO. Т. е. подчиненная ISO организация. Но не само ISO.

Цитата the_Shadow @ 26.07.06, 11:43

Кроме того, я задолбался уже объяснять то, что POSIX 1003.1, предоставляет функции С и ни чего более.

"Предоставляет функции С" - абсолютно ничего не значащая фраза. Что значит "предоставляет"? Кому предоставляет?

Цитата the_Shadow @ 26.07.06, 11:43

Таким образом, твоё изначальное высказывание относительно того, что мы разделяем POSIX & C -- бред. Мне это важнее, т.к. с этого всё и началось. Что, собственно, и дало повод сомневаться в твоей компетенции, т.к. как можно разделить эти две веши -- мне не понятно.

Разделить легко - на уровне стандартов. IEEE 1003.1.x и ISO 9899:1999 - это разные стандарты, у них разные области применения, разное назначение, разные цели. Все. Точка. Как человек с твоим уровнем знаний может их "не разделять" - мне не понятно.

Цитата the_Shadow @ 26.07.06, 11:43

Если ты рассказываешь про стандарт ISO, то извини, оно либо ссылается на POSIX 1003.1 (как ты искал, если нашёл (по твоим же словам выше)) -- всего одну ссылку и ту в библиографии -- мне не ясно.

Соответствущие ссылки в студию. В противном случае - звиздеж.

Вопрос к программистам на C

the_Shadow — Wed, 26 Jul 2006 11:43:56 +0000

the_Shadow:

Цитата Flex Ferrum @ 26.07.06, 11:29

Если проблема в том, что я неправильно интерпретировал эти твои слова - то выражайся яснее. :)

А другого ты не видел? К примеру, того, что POSIX есть tm ISO?

Извини, я, кроме того, что в форуме общаюсь, ещё и работаю. Кроме того, я задолбался уже объяснять то, что POSIX 1003.1, предоставляет функции С и ни чего более. Причём, объявлен, знаешь ли, как единственный базовый интерфейс для POSIX-совместимых систем.

Таким образом, твоё изначальное высказывание относительно того, что мы разделяем POSIX & C -- бред. Мне это важнее, т.к. с этого всё и началось. Что, собственно, и дало повод сомневаться в твоей компетенции, т.к. как можно разделить эти две веши -- мне не понятно. Если ты рассказываешь про стандарт ISO, то извини, оно либо ссылается на POSIX 1003.1 (как ты искал, если нашёл (по твоим же словам выше)) -- всего одну ссылку и ту в библиографии -- мне не ясно. Впрочем, и не интересно.

Вопрос к программистам на C

Flex Ferrum — Wed, 26 Jul 2006 11:29:26 +0000

Flex Ferrum:

Цитата the_Shadow @ 26.07.06, 11:19

ГДЕ ИМЕННО Я СКАЗАЛ, ЧТО POSIX ОПРЕДЕЛЯЕТ ЯЗЫК С?

Пожалуйста. У нас все ходы записаны:

Цитата the_Shadow @ 20.07.06, 23:05

Есть стандарт. Он явно описывает нечто. С, если быть точным. И там нет описания того, что я могу, а чего не могу.

Цитата the_Shadow @ 20.07.06, 21:34

Всё здорово. Но сам по себе С основан на POSIX 1.x ("x" -- по причине того, что комитет меняет "номер версии").

(после прочтения этой цитаты я долго выползал из под стула)
Так что ты там говоришь по поводу попытки приписать оппоненту то, чего он не говорил?

Добавлено 26.07.06, 11:30
Если проблема в том, что я неправильно интерпретировал эти твои слова - то выражайся яснее. :)

Вопрос к программистам на C

the_Shadow — Wed, 26 Jul 2006 11:22:15 +0000

the_Shadow:

Цитата linuxfan @ 26.07.06, 11:19

А что не понравилось-то?

Тяжёлое оно. Для цинды. Как-никак -- переопредление поведения объетов на экране... Нет. Лучше уж нативные вещи.

Вопрос к программистам на C

linuxfan — Wed, 26 Jul 2006 11:19:33 +0000

linuxfan:

Цитата the_Shadow @ 26.07.06, 11:06

И, замечу, добавленный в общее дерево кода довольно недавно

Юзал его года полтора назад :D

Цитата the_Shadow @ 26.07.06, 11:06

Лучше бы. Этого. Не делали.

:no: Категорически не согласен. Очень полезная штука, когда надо кроссплатформенное приложение замутить. На меня тогда сильное впечатление произвело, что один и тот же код компилился и работал и в винде и в линуксе, при том что там юзался OpenGL и подгружаемые плагины.
С тех пор я укрепился во мнении, что GTK рулит :)

Цитата the_Shadow @ 26.07.06, 11:06

Есть некоторый опыт в использовании.

А что не понравилось-то?

Вопрос к программистам на C

the_Shadow — Wed, 26 Jul 2006 11:19:00 +0000

the_Shadow:

Цитата Flex Ferrum @ 26.07.06, 11:02

Так там и С не описан. А если описан - то прошу привести раздел стандарта POSIX, в котором он описан. Без этого вся твоя аргументация - чистой воды звиздежь.

Итак, читай по буквам -- ГДЕ ИМЕННО Я СКАЗАЛ, ЧТО POSIX ОПРЕДЕЛЯЕТ ЯЗЫК С?
Я, в части спора по поводу POSIX & C явно оговорил, что данный вопрос мною не рассматривается, как не рассматривается и то, откуда вообще С взялся.

Я СКАЗАЛ И ГОВОРЮ, ЧТО POSIX 1003.1 ОПРЕДЕЛЯЕТ ФУНКЦИИ ДЛЯ БАЗОВОГО ИНТЕРФЕЙСА POSIX-СИСТЕМ. И ОПИСАНИЕ ДАНО НЕ "НА ЧЁМ УГОДНО", А НА С. По этой причине, аппеляции к стандарту ISO -- бред и попытка увести спор в сторону.

Равно, замечу, как и попытка приписать оппоненту то, что он не говорил, не делает чести Модератору.

Вопрос к программистам на C

Flex Ferrum — Wed, 26 Jul 2006 11:17:56 +0000

Flex Ferrum:

Цитата the_Shadow @ 26.07.06, 11:06

Flex, изначальное замечание, с чего всё началось, процитировать?

Процитируй.

Вопрос к программистам на C

the_Shadow — Wed, 26 Jul 2006 11:06:06 +0000

the_Shadow:

Цитата linuxfan @ 26.07.06, 11:02

GThread в glib

Довольно, замечу, редкоиспользуемый.

Flex, изначальное замечание, с чего всё началось, процитировать?

Добавлено 26.07.06, 11:07
2 linuxfan.
И, замечу, добавленный в общее дерево кода довольно недавно. Когда GTK+ стали портировать на ту же цинду. Лучше бы. Этого. Не делали. Есть некоторый опыт в использовании.

Вопрос к программистам на C

Flex Ferrum — Wed, 26 Jul 2006 11:02:21 +0000

Flex Ferrum:

Цитата the_Shadow @ 26.07.06, 10:39

Уф. Ты этой простыней пытался сказать, что, де, POSIX описывает язык С. Потому что все перечисленные в нем методы описаны на С. Я же тебе в ответ задал достаточно простой вопрос - какой раздел/пункт стандарта POSIX описывает синтаксис языка С. Ответа на этот вопрос я не получил. Кроме того, тебе было сказано, что WinAPI тоже описано на С. Но это не значит, что WinAPI описывает язык С.

Цитата the_Shadow @ 26.07.06, 10:39

Какого вообще хрена аппелировать к тому, что там не описано?

Цитата the_Shadow @ 26.07.06, 10:39

Функции какого языка там перечислены?

Попытайся задаться вопросом - почему они там перечислены.

Цитата the_Shadow @ 26.07.06, 10:39

Если это не функции языка С, определяющие системный API для POSIX-совмеситмых ОС

Это не функции языка С. Это описание системного API для POSIX-совместимых ОС, в терминах языка С.
А если ты настаиваешь на том, что это именно функции языка С (в том числе и те, которые в стандарте ISO C не упомянуты - оговорка для того, чтобы дать понять, что я прекрасно осознаю тот факт, что часть раздела System Interface пришла в POSIX из стандарта ISO C), то покажи мне место в стандарте POSIX, в котором написано, что эти функции должны быть реализованны именно на языке С. Со своей стороны приведу цитату из стандарта, где об этом ни слова не сказано:

Цитата

Use and Implementation of Functions
Each of the following statements shall apply unless explicitly stated otherwise in the detailed descriptions that follow:

If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined.

Any function declared in a header may also be implemented as a macro defined in the header, so a function should not be declared explicitly if its header is included. Any macro definition of a function can be suppressed locally by enclosing the name of the function in parentheses, because the name is then not followed by the left parenthesis that indicates expansion of a macro function name. For the same syntactic reason, it is permitted to take the address of a function even if it is also defined as a macro. The use of the C-language #undef construct to remove any such macro definition shall also ensure that an actual function is referred to.

Any invocation of a function that is implemented as a macro shall expand to code that evaluates each of its arguments exactly once, fully protected by parentheses where necessary, so it is generally safe to use arbitrary expressions as arguments. Likewise, those function-like macros described in the following sections may be invoked in an expression anywhere a function with a compatible return type could be called.

Provided that a function can be declared without reference to any type defined in a header, it is also permissible to declare the function explicitly and use it without including its associated header.

If a function that accepts a variable number of arguments is not declared (explicitly or by including its associated header), the behavior is undefined.

Раздел System Interfaces: General Information/Use and Implementation of Functions.
Что (в том числе) говорит о том, что любая функция из System Interface может быть представлена в коде на С (если разработка ведется с применением языка С) простым макросом.

Вопрос к программистам на C

linuxfan — Wed, 26 Jul 2006 11:02:16 +0000

linuxfan: Поскольку оба этих тулкита претендуют на кроссплатформенность, то свой wrapper для тредов есть и там и там. QThread в Qt и GThread в glib. Иначе что бы это были за кроссплатформенные тулкиты, если бы при их использовании код вырождался в кучу ifdef'ов?
Кстати, в этом же glib'е есть gmodule -- wrapper для работы с динамическами библиотеками (сильно меня выручил в свое время). Интересно, а в Qt такое есть?

Вопрос к программистам на C

the_Shadow — Wed, 26 Jul 2006 10:39:00 +0000

the_Shadow:

Цитата Flex Ferrum @ 26.07.06, 10:10

Сейчас для меня (в дискуссии с тобой) имеет значение только стандарты. И ничего кроме стандартов.

Извини, уже приводились. Не произвели на тебя ни какого впечатления, т.к. ты постоянно аппелируешь к ISO, описывающему язык С, но "забиваешь" на то, что тебе приводилось выше. К примеру, сообщение # 283.
Дана ссылка на документ и приведено содержимое страницы. Где там хоть что-то, отличное от С?

Какого вообще хрена аппелировать к тому, что там не описано? Где там Ada, Java, C++, asm? Функции какого языка там перечислены? И, в данном контексте, при чём здесь "можно описать на всём, на чём угодно?", если оно уже описано? И, если оно не описано, что же всё-таки, описывает POSIX 1003.1 System Interfaces и каким именно образом? Если это не функции языка С, определяющие системный API для POSIX-совмеситмых ОС, то... В принципе, вопросы уже сейчас риторические.

Ой, чесслово -- думай и делай и говори что угодно. Твой "профессионализьм" меня слабо волнует...

Добавлено 26.07.06, 10:40

Цитата linuxfan @ 26.07.06, 10:38

Если ты думаешь, что плагины можно реализовывать исключительно на C++, то посмотри на:

Видимо, linuxfan, он не знает о существовании семейства dl-функций... :D:D:D

Добавлено 26.07.06, 10:51

Цитата linuxfan @ 26.07.06, 10:38

Плохое утверждение.

После работы с GTK+/GNOME (писанными на С по большей части) -- никудышное, уж извини, LuckLess, но вообще никудышное. Довольно сложные проекты описаны прямо и руками. С минимумом бреда.

Как пример -- проект на С++ (Qt) имеет класс QThread. А зачем оно там? posix_threads уже перестали работать? А вот в GTK+/GNOME попыток "описать всё" просто нет. Есть набор либ. Каждая описывает какой-то аспект (gnet -- позволяет работать с сетью, есть либы по работе с БД, и т.д. и т.п.), но именно и чисто "системный уровень" остаётся за самой системой. Как, в принципе, и должно быть.

Вопрос к программистам на C

linuxfan — Wed, 26 Jul 2006 10:38:41 +0000

linuxfan: