D-Quick - A GUI library written in D

• C 84.7%
  
• Shell 7.1%
  
• C++ 2.8%
  
• Objective-C 2.6%
  
• D 2.0%
  
• Other 0.8%

Я б не сказал... :)

Ох уж эта автоматика... Хреново она работает в данном случае - замучаетесь вы там искать сишные и прочие файлы. А вот дишные на каждом углу. Так что я бы не только сказал бы, но и утверждал бы что DQuick написан на D. Другое дело, что внимание к нему зря привлечено, он еще в глубокой преальфе.

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

Создание единого, Ди-нативного ГУЯ - крайне важная вещь, но вот смущает текущий статус:

Windows (Main target

...и тут же:

SDL (temporary as isn't really adapted to window applications, there is some resize issues)

Что тогда вообще SDL делает в проекте? Насколько я знаю, SDL (в противовес её позиционированию) вовсе не «кроссплатформенный движок», а какая-то бестолковая прослойка, в которой вообще ничего нет - всё равно нужно юзать какой-нибудь ОпенГЛ.
В любом случае, сначала написать говнокод, а потом из него выпиливать ненужное - скверный в перспективе подход.
Я скачал сорсы, обязательно попробую разобраться, но начало какое-то неважное. :(

Да не надо цепляться за DQuick, только обратную реакцию получите. Проект еще сырой и смотреть там не на что. Зачем разочаровываться в языке из-за того, что кто-то по незнанию? упомянул сырой проект? Я бы не рекомендовал даже пробовать DQuick в данный момент. SDL это действительно кроссплатформенная прослойка, но она дает действительно низкоуровневые абстракции. Тем не менее ее использование вполне оправдано так как позволяет сэкономить кучу времени. Ну а выпилить потом чтобы сделать что-то оптимальное для своего проекта когда появится возможность - почему бы и нет?

Создание единого, Ди-нативного ГУЯ - крайне важная вещь

Не понял постановки задачи. За гуй отвечает библиотека. Язык же программирования идет совершенно отдельно

а по-дефолту возвращать значение последнего выражения?

Это потенциальные грабли и источник неясных багов.

Потому что, ...

... если всё действительно так, как описано, то вот это:

Тем не менее ее использование вполне оправдано так как позволяет сэкономить кучу времени. Ну а выпилить потом чтобы сделать что-то оптимальное для своего проекта когда появится возможность - почему бы и нет?

Есть явный косяк. Особенно, если учитывать:

SDL (temporary as isn't really adapted to window applications, there is some resize issues)

Почему косяк? Да потому что в моей реальности SDL это GLUT на стероидах. Если GLUT предоставляет возможность работы с окошками-менюшками-клавиатурой-мышкой, но только явно через OpenGL, то в SDL добавлена работа с носителями типа CD-ROM, звуком, интегрирована работа с шрифтами и имиджами. А, да. Ну и сеть ещё прикрутили. Для полностью безруких.

В итоге я могу заметить что ресайзить окошки в OpenGL через SDL это какое-то, простите, фееричное изъё?ство в космических размерах.

Это даже за пределами Добра и Зла. Воспользоваться тем же GLUT (или, если уж такие мастера, то использовать OpenGL напрямую), не позволяет религия?

Ну вы явно не пробовали ни glut, ни SDL. Первый предназначен для упрощения работы с OpenGL на разных платформах, а второй предназначен для упрощения работы с мультимедиа на разных платформах. Чувствуете разницу?

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

Результат for, естественно. А он будет равен результату последнего выражения в теле цикла на последней итерации.

А почему результатом for'а является не коллекция элементов, состоящих из значений последнего оператора тела цикла в итерации? Это было бы более логично, нет?

for (i = 0; i < N; i++)
{
  // do_something
}

Что здесь последнее выражение?

Что здесь последнее выражение?

for

Нет. Здесь последнее выражение i < N, при том, что i равно N, т.е. вернет 0.

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

void fun2(x)
{
   ......
}

fun()
{
    x = 0;
    fun2(x);
}

что вернет fun?

Что здесь последнее выражение?

for

Нет

В expression-oriented языке - да. А то, что ты не знаешь ничего, кроме Си - твои личные проблемы.

И чему же равен for? Что возвращать-то?

И чему же равен for?

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

Что возвращать-то?

Это уже обсуждалось выше.

Нет. Вы не правы...

... в том-то и дело что пробовал.

мультимедиа

Это слишком широкое понятие. Как, например, SDL_Net связана с «мультимедиа»? Я ещё могу понять относительную мультимедийность SDL_gfx, SDL_image, SDL_ttf... Подчеркну — относительную мультимедийность. Тезис об этой вашей «мультимедии» просто ни чём.

на разных платформах

У меня нет этих Ваших «разных платформ». Вот такой код:

int main( int argc, char* argv[] )
{
   SDL_Event               event;              //used to poll for events and handle input
   LPDirect3D9             Direct3D_object;    //used to create a direct 3d device
   LPDirect3DDEVICE9       Direct3D_device;    //basic rendering object
   D3DPRESENT_PARAMETERS   present_parameters; //stores the important attributes and 
   D3DXMATRIX              projection_matrix;  //   properties your Direct3D_device will have
   LPDirect3DVERTEXBUFFER9 tri_buffer = NULL;  //data buffer which the Direct3D_device can draw from
   VOID* pData;                                //pointer to beginning of vertex buffer
   //actual data to be fed to the vertex buffer

у меня не сработает. Ибо нет банально DirectX. Так что, применительно к Linux (в моей реальности — подчёркиваю вторично) мы говорим только об OpenGL-related вещах.

Чувствуете разницу?

Я её не чувствую. Я её знаю. Именно по этой причине нужно расстрелять «разРабов», которые через SDL пытаются:

SDL (temporary as isn't really adapted to window applications, there is some resize issues)

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

Тут возможно два «правильных» варианта: или ничего(unit|void) или список значений итераций цикла. Разработчики языка должны принять решения исходя из остальных особенностей языка. Например, в нише Си логичнее возвращать void, а в ФП логичнее взять список.

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

или список значений итераций цикла.

Если конечно они есть.

Подобные неясности - очень и очень большие грабли. Язык должен быть ясен.

Короче, ясного универсального ответа нет

А универсальный и не нужен. Нужен конретный - для определенного языка.

Это и есть те самые потенциальные грабли и баги, которые возникают.

Эти грабли и баги существуют только в твоей голове. Ну ладно, не только в твоей.

А универсальный и не нужен. Нужен конретный - для определенного языка.

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

вот в этом случае возвращаем это

а вот в это - это

а в третьем еще что-то

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

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

В пределах языка он будет совершенно конкретным.

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

И весь этот гемморой исключительно из-за того, что кому-то не нравится слово return

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

Какие неясности?

Есть еще вариант Scala, где сделали unit для обычного for'а, и список для for'а с yield'ами.

scala> val x = for (i <- Array(1,2,3,4,5)) i
x: Unit = ()

scala> val x = for (i <- Array(1,2,3,4,5)) yield i
x: Array[Int] = Array(1, 2, 3, 4, 5)

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

Для одного языка? Нет, не привел.

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

Да неужели? И в каком языке такие разночтения?

И весь этот гемморой исключительно из-за того, что кому-то не нравится слово return

Ты либо толст, либо невежественен. Ставлю на второе.

Да неужели? И в каком языке такие разночтения?

В твоем гипотетическом языке, где возвращаем значение последнего выражения.

И в каком языке такие разночтения?

В твоем гипотетическом языке

Ахаха.

а по делу есть что сказать? В рамках процедурного и процедурно-ООП программирования все упомянутые проблемы возникнут.

В чистом ООП и функциональном там возможно и по-другому, но там и проблемы «лень писать return» не стоит

а по делу есть что сказать?

Ты придумываешь себе страшилки и веришь им. Объяснять тебе что-то - пустая трата времени.

В рамках процедурного и процедурно-ООП программирования все упомянутые проблемы возникнут.

Если бы они могли возникнуть, они бы возникли еще в Algol68. Но не возникли.

В Scala не возникают.

for. Дальше в язык либо говорит, что for возвращает void, либо что возвращает список, либо компромиссный в духе скала for возвращает void, for + yield возвращает список.

Никакой неоднозначности в рамках одного языка.

void, конечно. В чем, собственно, твой вопрос?

Никакой неоднозначности в рамках одного языка.

Никакой неоднозначности в рамках одного языка.

>> или список значений итераций цикла.
Если конечно они есть.

Если их нет, то он вернет пустой список. В чем тут проблема?

Никакой неоднозначности в рамках одного языка.

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

вот в этом случае возвращаем это

а вот в это - это

а в третьем еще что-то

А можно примеры таких «всяких». Выше я разобрал твои примеры - там этого нет.

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

Как оно там случайно окажется? Ты рэндомом код генерируешь что ли? А если ты указываешь тип функции явно как void/unit никаких проблем вообще нет.

Без множественного наследования не нужно.

В Си нет никакого наследования. Он тоже не нужен?

В Си нет ООП. В отличие от D и C++. Модель совсем без множественного наследования(хотя бы через линеаризацию как в Scala и Python) выглядит несколько убого.

Дело ведь не только в «лень писать ретурн», а вообще в концепции, когда все является выражением(в том числе и блок, результатом которого является последнее выражение в нем). Эта концепция обладает большей гибкостью и избавляет от костылей в виде наличие в языке двух «одинаковых» конструкций - одно для выражений, другой - для инструкций(например, if ... else и ?: ).

последнее выражение в нем

Далеко не всегда очевидно, что является. Если самое последнее, то это будет условие окончания цикла. И его результат заведомо известен

цикл - это отдельное выражение, а не просто блок.

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

http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm :

loop [name-clause] {variable-clause}* {main-clause}* => result*
result---an object.

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

Ух ты...

... правда? )))

В Си нет ООП.

Inheritance

struct base{
   int x;
   int y;
} 

struct derived{
   struct base;
   int z;
}

Method Polymorphism

struct something_scaler {
    /* Тут переменные. */

    /* А тут "методы". */
    int (*scale)(int, int*);
}

/* В коде где-то. */
struct something_scaler some_scale, some_outher_scale;
some_scale->scale = &one_scale;
some_outher_scale->scale = &two_scale;

Абстракцию/инкапсуляцию сами представите или показать?

Иии... чего там в С нет? )))

Вы показали имитацию ООП, тем самым доказав мое утверждение.

Не-а...

... «парадигма» (в данном случае ООП) ни как не зависит от языка реализации. Вот в чём вся штука. Видел вполне себе асм-код в вполне ООП-стиле. ;)

Но речь-то в теме не о самой парадигме, а о ее поддержке/реализации в языке.

Я уже писал, но...

... повторю, пожалуй. В С (в том-то и уникальность языка) можно реализовать в принципе то, что Вам заблагорассудится и что нужно в рамках решения текущей задачи. Нужно ООП? Можно и ООП (я, кстати, там выше про vtables не обмолвился, просто потому, что не особо ими пользуюсь, но видел код на С с ними). Создайте требуемую Вам иерархию «классов» и используйте. Если нужно, то можете использовать элементы, аналогичные существующим в ЯФП. Ни кто ни чего не навязывает. Как можете, так и пищите.

Самое весёлое в том, что Вам ни кто не скажет (как это сделано на сайте про D) — «ну всё, 3.14здец, теперь-то Вы точно будете писать правильно» (утрирую). Если мой компилятор и splint со мной согласны, значит я и так пишу правильно и мнение разработчиков языка меня может не волновать, если всё работает как задумывалось.

... тьфу ты!

пишите*

Да я с этим и не спорю. Реализовать можно в Си многое. Но мы обсуждаем то, что реализовано в других языках. В обсуждаемых С++ и D вам не нужно реализовывать ООП, вы им просто пользуетесь.