Здравствуйте, мыщъх, Вы писали:

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

Здравствуйте, Abyx, Вы писали:

A>

A>import my_image_processing_lib
A>src = open('src.img', 'rb').read()
A>result = my_image_processing_lib.process()
A>open('out.img', 'wb').write(result)
A>

а чем этот способ плох?:

#include <my_image_processing_lib.hpp>

std::ifstream ifile('src.img');
auto result = my_image_processing_lib::process(ifile);
std::ofstream ofile('out.img');
ofile << result;

Здравствуйте, niXman, Вы писали:

X>а чем этот способ плох?:

Тем что тебе нужно написать как минимум CMakeFile, качать библиотеки и собрать my_image_processing_lib, разложить их по соответствующим путям. Ну и еще тем, что довольно хорошо совместимых между собой библиотек в Python до чертиков, а в C++ ты еще не маленький промежуток времени будешь детские болезни лечить, со флагами сборки играться.

Здравствуйте, tttraveler, Вы писали:


T>1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?

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

T>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

Ужас, ты серьезно?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, Abyx, Вы писали:

A>>

A>>import my_image_processing_lib
A>>src = open('src.img', 'rb').read()
A>>result = my_image_processing_lib.process()
A>>open('out.img', 'wb').write(result)
A>>

X>а чем этот способ плох?:
X>

X>#include <my_image_processing_lib.hpp>

X>std::ifstream ifile('src.img');
X>auto result = my_image_processing_lib::process(ifile);
X>std::ofstream ofile('out.img');
X>ofile << result;
X>

1) тем что тебе надо его перекомпилировать из за "" vs ''
2) в питоне для данных есть один тип — байты, а в плюсах тебе надо будет поконвертировать твой istream в какуюнить пару (void*, size_t) — одним словом больше бойлерплейта, больше возни

Здравствуйте, Abyx, Вы писали:

A>

A>import my_image_processing_lib
A>src = open('src.img', 'rb').read()
A>result = my_image_processing_lib.process()
A>open('out.img', 'wb').write(result)
A>

A>я могу набрать и выполнить его в REPL
За такой код надо по рукам бить тапком. Так как в PyPy или на других Питонах он будет работать только иногда.

Правильнее будет:

import my_image_processing_lib
with open('src.img', 'rb') as fl:
    src = fl.read()
result = my_image_processing_lib.process()
with open('out.img', 'wb') as fl:
    fl.write(result)

Здравствуйте, Cyberax, Вы писали:

A>>

A>>import my_image_processing_lib
A>>src = open('src.img', 'rb').read()
A>>result = my_image_processing_lib.process()
A>>open('out.img', 'wb').write(result)
A>>

A>>я могу набрать и выполнить его в REPL
C>За такой код надо по рукам бить тапком. Так как в PyPy или на других Питонах он будет работать только иногда.

всмысле если подсчета ссылок нет — файл не сразу закроется? да и пофиг, по завершении скрипта всё закроется

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, tttraveler, Вы писали:


T>>1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?
KP>Это труп с точки зрения коммерческой разработки, разве что палочкой потыкать можно прикола ради.

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

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

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

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

так что единственное, что меня может волновать, это возможно подключения к платформе Python+D каких-то сторонних готовых вещей

T>>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

KP>Ужас, ты серьезно?

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

таким образом я пришел к указанному выше вопросу

Здравствуйте, kaa.python, Вы писали:

KP>Тем что тебе нужно написать как минимум CMakeFile
не факт.

KP>качать библиотеки и собрать my_image_processing_lib
my_image_processing_lib — header-only библиотека. а libjpeg/libpng/libz/etc — у меня в системе уже есть.

KP>разложить их по соответствующим путям.
$ make install

KP>Ну и еще тем, что довольно хорошо совместимых между собой библиотек в Python до чертиков, а в C++ ты еще не маленький промежуток времени будешь детские болезни лечить, со флагами сборки играться.
ну, если учесть, что контекст у нас такой, что my_image_processing_lib — всего лишь клей для С/С++ либы, то для питона нам придется так же, собирать эту либу, писать этот самый клей, лечить болезни, етц...


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

Здравствуйте, Abyx, Вы писали:

A>всмысле если подсчета ссылок нет — файл не сразу закроется?
да, даже я это знаю =)

Здравствуйте, kaa.python, Вы писали:

T>>2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?

KP>Ужас, ты серьезно?

вот еще насчет окошек
смотрю тут помаленьку сайт D и вот список GUI-библиотек, которые можно из него использовать
http://wiki.dlang.org/GUI_Libraries

вообще же, при оценке возможности использования D для оконных десктопных приложений сравнение идет явно не с дельфи и дот нет, а с аналогичной разработкой оконных приложений на C++ с использованием того же набора GUI-библиотек, что перечислены выше

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

А чем C++ не угодил?

Здравствуйте, tttraveler, Вы писали:
T>очевиден выбор питона для бизнес логики
T>и вдобавок нужно что-то для системной части
T>с/с++ по ряду личных соображений использовать не хочу
T>но нужно что-то близкое

Нет ничего близкого. Если нужно что бы было все легко и кроссплатформенно, да еще и десктоп, то это java, тут сам бог велел,
при условии что c|c++ мы не рассматриваем, потому что если бы рассматривали то GTK+ и QT это несомненные лидеры в этой области.
Для примера можно посмотреть на rubymine от джетбрейнс. Сделано на java и весьма сносно.

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

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

Здравствуйте, tttraveler, Вы писали:

может быть все же пояснишь реальные причины поиска альтернативы? возможно, не все так плохо?

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, tttraveler, Вы писали:
T>>очевиден выбор питона для бизнес логики
T>>и вдобавок нужно что-то для системной части
T>>с/с++ по ряду личных соображений использовать не хочу
T>>но нужно что-то близкое

N>Нет ничего близкого. Если нужно что бы было все легко и кроссплатформенно, да еще и десктоп, то это java, тут сам бог велел,
N>при условии что c|c++ мы не рассматриваем, потому что если бы рассматривали то GTK+ и QT это несомненные лидеры в этой области.

близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, tttraveler, Вы писали:

X>может быть все же пояснишь реальные причины поиска альтернативы? возможно, не все так плохо?

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

однако нужна (на перспективу) возможность писать летающий нативный код на серверах и летающие нативные десктопные приложения

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

Здравствуйте, tttraveler, Вы писали:
T>близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
T>java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

T>и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

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

а вот что мненравится в D
цитаты из вики статьи
надеюсь это правда

D's design goals attempt to combine the performance of compiled languages with the safety and expressive power of modern dynamic languages. Idiomatic D code is commonly as fast as equivalent C++ code, while being shorter and memory-safe.

D is designed with lessons learned from practical C++ usage rather than from a theoretical perspective. Even though it uses many C/C++ concepts it also discards some, and as such is not compatible with C/C++ source code. It adds to the functionality of C++ by also implementing design by contract, unit testing, true modules, garbage collection, first class arrays, associative arrays, dynamic arrays, array slicing, nested functions, inner classes, closures, anonymous functions, compile time function execution, lazy evaluation and has a reengineered template syntax. D retains C++'s ability to do low-level coding, and adds to it with support for an integrated inline assembler. C++ multiple inheritance is replaced by Java style single inheritance with interfaces and mixins. D's declaration, statement and expression syntax closely matches that of C++.

http://en.wikipedia.org/wiki/D_(programming_language)

Здравствуйте, -n1l-, Вы писали:

N>Здравствуйте, tttraveler, Вы писали:
T>>близкое в том, что D позиционирует себя для написания нативного кода, который должен летать
T>>java никогда так себя не позиционировала в принципе, и имидж у нее совсем не тот (хотя во многом проблема как обычно в кривых руках)

T>>и GTK+ и QT можно использовать и из D, как я писал выше давая ссылку на сайт языка

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

на перспективу

Здравствуйте, tttraveler, Вы писали:
T>на перспективу

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

Вот смотри, если ты работаешь с данными, какими-то, которые приходят и уходят, отображаются на других компах, плюс нужна кроссплатформенность, то бери что-то, что охватит полностью всю задачу. Т.е. и сервер и клиент и все-все-все на одной и той же платформе. Ну как вариант java, да?
В java ксати очень много готовых решений, связанных с математикой. Вот я например как-то искал средство для отображения 3-х мерных поверхносте, созданных из моих данных. Ну сварганил все быстренько на java и забыл. До серьезной работы над проектом даже не дошло, так как его просто напросто отложили до лучших времен.
Если бы задачуначали детально разбирать, что-то там меня бы не устроило, то я бы высказал свое веское мнение о том, что java не подходит. Но пока она подходила по всем параметрам, а такая графическая обработка данных, как ты наверное догадываешься дело объемное. Но все летало.

Была другая задача, у меня было 2мб оперативной памяти, и нужно было этот буффер использовать для транспортировки более ста тысяч значений из разных источников.
Плюс нужно было действовать быстро, раз, два принял, обработал, вывел в stream вывода, взял оттуда, отчистил память там уже на очереди еще приплыли значения и так далее. Вот тут я делал уже все на си++, хотя подошел бы и обычный си, но я захотел плюсы.

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