Comments 153
ИМХО, конечно, но если вы используете printf, то вы пишете не на С++. Есть же iostream.
А вы когда-нибудь сравнивали скорость работы printf/scanf и cin/cout?
Если нет — попробуйте, будете очень удивлены, насколько iostream медленнее работает.
Если нет — попробуйте, будете очень удивлены, насколько iostream медленнее работает.
С std::cout.sync_with_stdio(false) вроде уже не так тормозит. Но дизайн iostream все равно считается плохим, поэтому все рано или поздно переходят на самописные или third-party C++ потоки (т.е. более безопасные, чем printf/scanf).
iostream работает не медленнее.
По умолчанию включена синхронизация буферов/кэшей в iostream и stdio, её можно (и нужно, если нет каши из scanf+printf/cin+cout) отключать вызовом sync_with_stdio(0). После этого скорости становятся одинаковыми. К сожалению, некоторые компиляторы/реализации STL не поддерживают её правильно и всё равно тормозят в iostream (некоторые версии от MS говорят страдают)
буду обновлять страницу перед отправкой комментария
По умолчанию включена синхронизация буферов/кэшей в iostream и stdio, её можно (и нужно, если нет каши из scanf+printf/cin+cout) отключать вызовом sync_with_stdio(0). После этого скорости становятся одинаковыми. К сожалению, некоторые компиляторы/реализации STL не поддерживают её правильно и всё равно тормозят в iostream (некоторые версии от MS говорят страдают)
буду обновлять страницу перед отправкой комментария
Ваш комментарий все таки более расширенный и информативный, чем предыдущий.
Так что, даже если обновляете перед отправкой — все равно отправляйте в таких случаях. :)
Так что, даже если обновляете перед отправкой — все равно отправляйте в таких случаях. :)
И как будет работать
int main()
{
puts(«input integers A and B»);
int a, b;
scanf("%d%d", &a, &b);
printf(«sum of two = %ld», a+b);
return 0;
}
в вашей трактовке с потоками?
int main()
{
puts(«input integers A and B»);
int a, b;
scanf("%d%d", &a, &b);
printf(«sum of two = %ld», a+b);
return 0;
}
в вашей трактовке с потоками?
Прекрасно. Так же как и
А вот
ваще никак, потому что кашу нельзя делать с выключенной синхронизацией.
int main() {
cout << "input integers A and B" << endl;
int a, b;
cin >> a >> b;
cout << "Sum of two = " << a + b << endl;
}
А вот
int main() {
puts("input integer A and B");
int a, b;
cin >> a;
scanf("%d", &b);
cout << "sum of two = %d", a + b);
}
ваще никак, потому что кашу нельзя делать с выключенной синхронизацией.
Скорость работы ввода/вывода в консоль важна только в олимпиадных задачках (ну или в специфических сценариях, когда вы передаете кучу данных в каком-нибудь пайпе). С перегрузкой же оператора << работать куда удобнее.
комментарии
Вот «правильный» вариант с точки зрения операционной системы:
#include <stdio.h>
int main() { printf( "Hello, world!" ); return 0; }
А вот вы и попались, не знающей стандартов Си :)
http://stackoverflow.com/questions/22239/why-does-int-main-compile
Я — не знаю стандартов Си и не знаю человека, который их (полностью) знает… Стандарт может завтра поменяться, но архитектура CPU вряд ли завтра поменяется, а программа должна работать…
Если вы не знаете стандартов языка, то о какой оценке навыков программирования может идти речь? Поведение CPU не имеет значения, если уровень выше (в данном случае — компилятор языка) ведет себя так, как ему сказано в стандарте.
Компилятор пишут люди, а они могут ошибаться… Это не спор о стандартах, и не о моем уровне их знания. Я лишь говорю о том, что даже простейшая программа (даже, наверное, самая простая) не так проста (что, кстати, данная дискуссия и показывает). И данный факт можно использовать для оценки навыков программирования автора данной программы.
Компилятор пишут люди, а они могут ошибаться…
Если предположить, что компилятор ошибается, мы вообще не можем рационально рассуждать о поведении написанного нами кода. Поэтому в подобных "заданиях" либо дается конкретный компилятор (если мы опираемся на его известное поведение), либо конкретный стандарт (и мы предполагаем, что компилятор ему полностью соответствует), либо предполагается некое — корректное! — усредненное поведение.
Я лишь говорю о том, что даже простейшая программа (даже, наверное, самая простая) не так проста.
Вы никак не подтвердили это свое высказывание. Три приведенных в статье пункта — это бессмысленные усложнения.
И данный факт можно использовать для оценки навыков программирования автора данной программы.
… только в рамках программирования аналогичных простых программ.
Не понимаю, почему столько минусов? Вполне честный ответ… Если кто-то говорит, что знает стандарты языка С полностью… Конечно, к этому надо стремиться. Если есть в чем-то сомнения, проще открыть стандарт и уточнить спорный момент. Вот несколько фактов:
1. Официальные издания стандартов языка С публикуется ISO, и стоят денег.
2. Существуют следующие международные стандарты (ISO):
2.1 C90, определен в ISO/IEC 9899:1990.
2.2 C99, определен в ISO/IEC 9899:1999.
2.3 C11, определен в ISO/IEC 9899:2011.
Объемы стандартов близки к 1’000 страниц английского текста.
По поводу функции main:
1. C11, ISO/IEC 9899:2011. (Черновик здесь http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):
The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /*… */ }
or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /*...*/ }
or equivalent; or in some other implementation-defined manner.
«UNIX прост. Но надо быть гением, чтобы понять его простоту.» — Деннис Ритчи.
1. Официальные издания стандартов языка С публикуется ISO, и стоят денег.
2. Существуют следующие международные стандарты (ISO):
2.1 C90, определен в ISO/IEC 9899:1990.
2.2 C99, определен в ISO/IEC 9899:1999.
2.3 C11, определен в ISO/IEC 9899:2011.
Объемы стандартов близки к 1’000 страниц английского текста.
По поводу функции main:
1. C11, ISO/IEC 9899:2011. (Черновик здесь http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):
The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /*… */ }
or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /*...*/ }
or equivalent; or in some other implementation-defined manner.
«UNIX прост. Но надо быть гением, чтобы понять его простоту.» — Деннис Ритчи.
Не понимаю, почему столько минусов?
Потому что вы пренебрежительно относитесь к изучению языка, на примере которого рассуждаете об оценке навыков программирования. А еще потому, что ваш ответ никак не связан с тем комментарием, на который вы отвечаете.
По поводу функции main:
- C11, ISO/IEC 9899:2011. (Черновик здесь http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf):
Угу, там же, раздел 5.1.2.2.3, Program termination (всего лишь на страницу ниже вашей цитаты):
reaching the}that terminates themainfunction returns a value of 0.
Поэтому да, прежде, чем писать о том, какая программа правильна с точки зрения операционной системы, неплохо бы уточнить, что по этому поводу думает стандарт. И да, то, что
return x из main прокидывает значение как код возврата программы целиком — не имеет никакого отношения к операционной системе, она об этом не знает. Это поведение целиком и полностью определяется компилятором (который опирается на стандарт).Если вы не знаете стандартов языка, то о какой оценке навыков программирования может идти речь? и Потому что вы пренебрежительно относитесь к изучению языка, на примере которого рассуждаете об оценке навыков программирования. — Это ваше личное высказывание, которое нарушает требование данного ресурса: оскорблять других пользователей, не следить за эмоциями.
Далее
Угу, там же, раздел 5.1.2.2.3, Program termination (всего лишь на страницу ниже вашей цитаты):
reaching the } that terminates the main function returns a value of 0.
Также нарушает правила: Путать «Хабр» с Твиттером. Если я не прав, то я не так понимаю данные правила. Пусть тогда мне пояснят их пользователи с большими полномочиями. От вас я вижу много неконструктивной критики, с переходом на личности.
Далее
Угу, там же, раздел 5.1.2.2.3, Program termination (всего лишь на страницу ниже вашей цитаты):
reaching the } that terminates the main function returns a value of 0.
Также нарушает правила: Путать «Хабр» с Твиттером. Если я не прав, то я не так понимаю данные правила. Пусть тогда мне пояснят их пользователи с большими полномочиями. От вас я вижу много неконструктивной критики, с переходом на личности.
Если вы не знаете стандартов языка, то о какой оценке навыков программирования может идти речь? и Потому что вы пренебрежительно относитесь к изучению языка, на примере которого рассуждаете об оценке навыков программирования.
Это ваше личное высказывание, которое нарушает требование данного ресурса: оскорблять других пользователей,
А вы видите оскорбление в процитированных вами высказываниях? Вообще-то, не всякая оценка является оскорблением.
Угу, там же, раздел 5.1.2.2.3, Program termination (всего лишь на страницу ниже вашей цитаты):
reaching the } that terminates the main function returns a value of 0.
Также нарушает правила: Путать «Хабр» с Твиттером.
Это правило относится к публикациям, а не к комментариям.
От вас я вижу много неконструктивной критики, с переходом на личности.
Отнюдь, никакого перехода на личности. Это вы (а не я) написали "Я — не знаю стандартов Си". Я всего лишь говорю, что незнание стандартов ограничивает возможности корректно оценивать навыки программирование (в рамках конкретного языка), что и видно в конкретных примерах в посте.
Ну и да, если вы перешли на обсуждение правил, то, вероятно, по сути вам ответить нечего.
(удалено)
void main
А кто из современных компиляторов это проглотит? По стандарту
main возвращаетint и в C и в C++, и clang и gcc это проверяют.Можно кстати по стандарту не писать
return 0; компилятор встроит его аналог за вас.printf( "%s", "Hello, world!" );
Зачем? Если бы вы "Hello, world!" брали откуда-то извне, а так это бесмысленно.
Опять же gcc/clang печатают предупреждение если строка форматирования не соотвествует
аргументам, а с
-Werror=format просто не скомпилируют такой код.Поставил минус статье.
Вы расписали в подробностях, почему важен return 0, хотя он не важен абсолютно в данном контексте.
Но при этом читать про небезопасность printf отправляете в гугл — хотя это как раз тема о которую мнгие спотыкаются.
Вы расписали в подробностях, почему важен return 0, хотя он не важен абсолютно в данном контексте.
Но при этом читать про небезопасность printf отправляете в гугл — хотя это как раз тема о которую мнгие спотыкаются.
Во первых, return 0 важен, так как показывает связь CPU->asm->C->C++ (в контексте такой простой задачи), и это явно через гугл не найдешь. Во-вторых, безопасность printf — избитая тема, которая уже находится в другой плоскости.
Да, но вот только printf("…") — безопасен, а автор утверждает, что printf( "%s", "Hello, world!" ); безопаснее, чем printf( "Hello, world!" );.
Вот, например, описание из Википедии:
Так как printf (и остальные функции семейства) могут выводить текст строки форматирования без изменений, если он не содержит управляющих последовательностей, то возможен вывод текста командой
printf(text_to_print);
В случае, если text_to_print получается из внешних источников (читается из файла, получается от пользователя или операционной системы), то наличие в получаемой строке знака процента может приводить к крайне нежелательным последствиям (вплоть до зависания программы).
Пример некорректного кода:
printf(" Current status: 99 % stored.");
В этом примере содержится управляющая последовательность «% s», содержащая признак управляющей последовательности (%), флаг (пробел) и тип данных «строка» (s). Функция, приняв управляющую последовательность, попытается прочитать из стека указатель на строку. Так как функции не передавались дополнительные параметры, значение, которое будет прочитано со стека, не определено. Полученное значение будет интерпретировано как указатель на строку с завершающим нулём. Вывод такой «строки» может привести к выводу произвольного дампа памяти, ошибке доступа к памяти и разрушению стека.
Таким образом, printf( «Hello, world!» ) — потенциально опасная строка, модификация «Hello, world!» может привести к ошибке.
Так как printf (и остальные функции семейства) могут выводить текст строки форматирования без изменений, если он не содержит управляющих последовательностей, то возможен вывод текста командой
printf(text_to_print);
В случае, если text_to_print получается из внешних источников (читается из файла, получается от пользователя или операционной системы), то наличие в получаемой строке знака процента может приводить к крайне нежелательным последствиям (вплоть до зависания программы).
Пример некорректного кода:
printf(" Current status: 99 % stored.");
В этом примере содержится управляющая последовательность «% s», содержащая признак управляющей последовательности (%), флаг (пробел) и тип данных «строка» (s). Функция, приняв управляющую последовательность, попытается прочитать из стека указатель на строку. Так как функции не передавались дополнительные параметры, значение, которое будет прочитано со стека, не определено. Полученное значение будет интерпретировано как указатель на строку с завершающим нулём. Вывод такой «строки» может привести к выводу произвольного дампа памяти, ошибке доступа к памяти и разрушению стека.
Таким образом, printf( «Hello, world!» ) — потенциально опасная строка, модификация «Hello, world!» может привести к ошибке.
Ну так и в «безопасном» варианте
модификация строки формата "%s" может привести к ошибке :-)
printf( "%s", "Hello, world!" );
модификация строки формата "%s" может привести к ошибке :-)
Тогда любой код потенциально опасен. Его модификация может привести к ошибке. :)
Но, printf( «Hello, world!» ) — безопасен. А если вы добавите управляющую последовательность — получите warning с информацией об этом.
Но, printf( «Hello, world!» ) — безопасен. А если вы добавите управляющую последовательность — получите warning с информацией об этом.
Не совсем: printf( «Hello, world!» ) так же безопасен как int s = 2; int b = 4/s. Смотрите на мою статью как на взгляд на то, имеет ли смысл ожидать зеленого сигнала светофора если машин не видно, или не дожидаясь перейти на красный? Опыт желательно строить на ошибках других, не я один утверждаю что надо стремится к красивому (безопасному) коду.
Хм. А я этот ответ частично принимаю.
Действительно, в большом проекте, который использует printf(), легче заставить всех писать printf("%s", "…") вместо printf("…") чем ждать, пока кто-то случайно туда управляющую последовательность вставит.
Но:
- Вот на это уже действительно наорёт компилятор (а на
printf("Hello, World")— не наорёт). Так что можно не париться и доверять компилятору. - Если уж вы так беспокоитесь и почему-то не доверяете варнингам компилятора — можно завернуть в функцию-хелпер.
Я вот ничего не нагуглил на тему printf с выводом константной строки. И ни один компилятор у меня не выводит варнингов на printf с константной строкой…
Если написать, например:
можно получить предупреждение, что формат не является строковым литералом. Лучше заменить на
А что не так с printf( «Hello, world!» )?
void my_print(const char *msg)
{
printf(msg);
}
можно получить предупреждение, что формат не является строковым литералом. Лучше заменить на
printf("%s", msg);
А что не так с printf( «Hello, world!» )?
Я так понял, что в случае какой-нибудь иньекции, если в вашем приложении изменят строку в ресурсах на «Hello, % sword!» то приложение на ровном месте получит проблемы. Это как важные документы хранить в мусорной корзине. Лежат они там довольно уютненько, до поры до времени.
Ну, да, тогда printf захватит недостающий аргумент из стека, что явно было предназначено не для него. Но если есть возможность изменить литерал в статической памяти, то ничего не мешает натворить кучу других нехороших дел. Подправить таблицу виртуальных методов, например.
Зачем давать программе ещё один способ вызвать неприятности?
К тому же литерал может быть доступен для изменения а таблица виртуальных методов в защищённой области памяти.
К тому же литерал может быть доступен для изменения а таблица виртуальных методов в защищённой области памяти.
Затем, что читаемость кода падает. А для атакующего нет никакой разницы, менять printf("Hello, world") на printf("%s"), или printf("%s", "Hello, world") на printf("%s %s", "Hello, world"), поэтому польза от такой "защиты" ничтожна.
Программа пишется один раз, а модифицируется много… Если предполагается развитие программы, то лучше писать безопасно, тем более, зная о явных проблемах printf. Это как с заземлением — может убить и при его наличии, не без него убьет точно.
Если предполагается развитие программы, то лучше писать безопасно
Как уже неоднократно говорилось, запись
printf("Hello, world") — безопасна.Пишите тогда в Maйкрософт — для них само использование printf уже не безопасно…
… тем не менее в вашем примере эта функция оставлена. Что же вы не прислушались к Майкрософту?
Этот пример придумали до меня, когда Майкрософт еще не было. Я его осмыслил и интерпретировал в некоторой новой плоскости.
Тогда не ссылайтесь на мнение Майкрософта о безопасности printf.
Лично для меня использование форматирующей функции со строкой, не требующей форматирования, вообще означает, что надо менять функцию целиком на неформатирующую, тогда уж точно поведение будет корректным и ожидаемым. Но нет, вы просто добавляете параметр, тем самым ничего не улучшая.
Дело в том, что когда кто-нибудь изменит строку (как вы говорите) и включит туда управляющую последовательность, но не добавит аргумент — компилятор наругается. Если кто-то подставит туда переменную (и строка сможет измениться в рантайме) — компилятор наругается.
Если подставить туда строковый литерал, как "Hello World!" — он не наругается. И это не опасно.
Чтобы не получить на свою голову проблем, достаточно просто смотреть на варнинги компилятора в данном случае, а не превращать каждый printf("whatever") в громоздкую конструкцию.
У вас во всех программах ошибка — отсутствует переход на новую строку.
И не совсем понятно, о каких замечаниях (и какого конкретно) компилятора вы говорите при выводе вшитой строки. Показали бы, вместо отсылания в гугл.
И да, если бы передо мной действительно стояла задача оценки навыков программирования по Hello World (уф), то мне бы ваша программа не понравилась =).
int/void и наличие/отсутствие return 0; приводят к одному результату: «ConsoleApplication.exe» завершилась с кодом 0 (0x0).
Такая простейшая задача показывает только стокгольмский синдром у ментальных заложников описанного выше языка программирования и продуктов (ОС) написанных на этом языке.
С++ сложен.
Я пишу на нем уже около 10 лет в профессиональной деятельности. А когда начал изучать — даже и не вспомню.
Но вот прямо в данный момент читаю Мейерса и каждая страница открывает мне новые грани и понимание.
С++ сложен и многогранен. И не знать его на 100% — нормально. Это не мешает писать на нём.
Откровенно говоря, писать на С++ можно начать в первый же день знакомства с ним, если вы хотя бы чуть чуть понимаете что такое программирование.
Основная фишка С++ в том, что он позволяет делать как простые конструкции в С стиле, так и создавать сложные арзитектурные решения с шаблонами и ООП.
Просто с ростом знаний улучшается и упрощяется код и всё.
int main(){printf(«Hello, world!»);} прекрасно справляется со своей задачей. И даже без знания нюансов вы напишите код, который убдет работать. Но глубокое знание С++ позволит быстро писать быстрый, качественный и легко расширяемый код.
Если вы не понмиаете прелестей С++ — вероятнее всего именно вы заложник своего языка. И, готов биться об заклад, основное что вам нравится в вашем языке(каким бы он ни был) — это GC. Почему-то именно привержены C# и Java больше остальных не любят С++.
Я пишу на нем уже около 10 лет в профессиональной деятельности. А когда начал изучать — даже и не вспомню.
Но вот прямо в данный момент читаю Мейерса и каждая страница открывает мне новые грани и понимание.
С++ сложен и многогранен. И не знать его на 100% — нормально. Это не мешает писать на нём.
Откровенно говоря, писать на С++ можно начать в первый же день знакомства с ним, если вы хотя бы чуть чуть понимаете что такое программирование.
Основная фишка С++ в том, что он позволяет делать как простые конструкции в С стиле, так и создавать сложные арзитектурные решения с шаблонами и ООП.
Просто с ростом знаний улучшается и упрощяется код и всё.
int main(){printf(«Hello, world!»);} прекрасно справляется со своей задачей. И даже без знания нюансов вы напишите код, который убдет работать. Но глубокое знание С++ позволит быстро писать быстрый, качественный и легко расширяемый код.
Если вы не понмиаете прелестей С++ — вероятнее всего именно вы заложник своего языка. И, готов биться об заклад, основное что вам нравится в вашем языке(каким бы он ни был) — это GC. Почему-то именно привержены C# и Java больше остальных не любят С++.
UFO just landed and posted this here
А если грузится, то фич давай, а если с фичами, то рыночную ценность покажите… Плавали, знаем.
http://www.ocp.inf.ethz.ch/wiki/OCP/Home
http://www.ocp.inf.ethz.ch/wiki/OCP/Home
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
При этом это заблуждение, поскольку бывают ещё и логические ошибки.
А по моему, это подмена понятий. Разве кто-то обещает избавить от "вообще всех" ошибок? Я таких утверждений в отношении упомянутого раста не видел. А вот обобщений в духе "не защищает от всего -> защита в принципе не нужна" хватает.
их программы с безопасным языком работают в ОС написанной на типа не безопасном языке
Мы живём в реальном мире со всеми его недостатками. (:
Как по мне, так это наоборот хорошо, что авторы не бросаются "заменять всё" — дополнительное доказательство того, что у них есть определённые цели, а не просто фанатизм в духе "напишем всё на нашем чудо-языке".
Если честно, вообще не понимаю сути претензий. Можно подумать, что у вас кто-то С насильно отбирает. Вот я пишу на С++ и хотя его принято ругать (причём не безосновательно) мне язык нравится. Но нравится и раст, хотя в нём недостатки тоже вижу. Нравится и как непосредственно язык и как "идея" — если не взлетит, то всё равно что-то в существующие языки войдёт и/или даст толчок чему-то новому. В конце концов, это просто интересно. (:
И да, вижуал бейсик не родился в пятой версии, а дошёл до неё не сразу. И документация для раста имеется, ну а ИДЕ — дело наживное, хотя что-то имеется и сейчас.
UFO just landed and posted this here
UFO just landed and posted this here
когда весь мир пишет на Си и догоняется питоном/перлом/пхп.
Вот так мило взяли и изничтожили весь .net, весь JVM и все функциональные языки.
Си в компах как английский в реальном мире.
М? Третий по распространенности после?..
Вообще-то в этой ветке именно вы зачем-то заговорили о Go и Rust.
Извините, но у меня есть большие сомнения относительно вашего хождения. По крайней мере, в том плане, что оно было хоть сколь-нибудь основательным. Свой опыт я привёл.
Могу только порадоваться, что не все разделяют ваше мнение, но давайте уточним: вы отрицаете прогресс в целом или только относительно языков программирования? Если второе, то чем они хуже всего остального? Неужели никогда не возникало мысли, что можно было бы сделать лучше и что принятые решения зачастую вызваны имеющимися обстоятельствами и что ситуация могла измениться?
Я уже ходил по этому пути и больше не хочу.
Извините, но у меня есть большие сомнения относительно вашего хождения. По крайней мере, в том плане, что оно было хоть сколь-нибудь основательным. Свой опыт я привёл.
Можно придумывать сколько угодно ещё языков, лучше всё равно не станет.
Могу только порадоваться, что не все разделяют ваше мнение, но давайте уточним: вы отрицаете прогресс в целом или только относительно языков программирования? Если второе, то чем они хуже всего остального? Неужели никогда не возникало мысли, что можно было бы сделать лучше и что принятые решения зачастую вызваны имеющимися обстоятельствами и что ситуация могла измениться?
UFO just landed and posted this here
Наверное, продолжать спор нет смысла — слишком уж много тут субъективного окажется. Я пишу на С++ и крайне рад, что не приходится использовать "голый С". И да, раст, несмотря на то, что там нет кое-чего (может даже "много чего") из плюсов, мне всё равно кажется прогрессом.
Но дело даже не в этом. Из интереса брался за разные языки: за тот же лисп/ракет, например. Естественно, ниша у него другая, но это не мешало мне видеть удобные и крутые возможности, которые могли бы и в более низкоуровневые языки попасть. Да хотя бы (нормальные, не сишные) макросы. И я очень рад, что раст делает шаги в этом направлении.
Не стоит забывать ещё о том, что новым языкам сложнее пробиться: на существующих немало написано уже, есть литература, разнообразные курсы, готовые специалисты, их преподают в учебных заведениях. У них есть поддержка ИДЕ, профайлеров, отладчиков и прочих полезных вещей. На них написаны кучи библиотек и имеется биндинги к "чужим". Для новых языков это всё надо делать и оно не так просто, особенно учитывая, что некоторые из них делаются энтузиастами. Да даже мозилла весьма скромно смотрится на фоне майкрософта продвигающего C# или эпла со свифтом. Тем более, что "своей платформы" у них нет. А у какого-нибудь Nim есть тупо пару активных разработчиков и всё. Плюс инертность, которая зачастую оправдана — переписывать существующие проекты нет смысла за крайне редкими исключениями.
Си живёт так долго не только потому что на нём столько всего написано, но и потому что лучше особо ничего не выходит для данного спектра задач.
Какого "данного"? Особенно учитывая, что ниже вы пишете, что этот язык лучше "во всем в среднем"?
Под лучше я понимаю не в чём то одном конкретном, а во всём в среднем.
Если у меня конкретная задача, зачем мне брать язык, который с ней справляется "средне", если можно взять язык, который справляется с ней хорошо?
UFO just landed and posted this here
> printf( «Hello, world!» );
Не стоит доверять сообщениям компилятора, который ЭТО обзывает небезопасным. И уж тем более не надо втыкать костыли типа
> printf( "%s", «Hello, world!» );
> ///@file hello_world.cpp
Бессмысленно — это часть метаданных файла, и ее не стоит дублировать в данных файла. Особенно если учесть, что файл потом могут переименовать
> ///@author idimm
Бессмысленно — если уж мы тут следуем лучшим практикам, то эта информация есть в системе контроля версий. Особенно если учесть, что файл потом могут редактировать другие люди
Не стоит доверять сообщениям компилятора, который ЭТО обзывает небезопасным. И уж тем более не надо втыкать костыли типа
> printf( "%s", «Hello, world!» );
> ///@file hello_world.cpp
Бессмысленно — это часть метаданных файла, и ее не стоит дублировать в данных файла. Особенно если учесть, что файл потом могут переименовать
> ///@author idimm
Бессмысленно — если уж мы тут следуем лучшим практикам, то эта информация есть в системе контроля версий. Особенно если учесть, что файл потом могут редактировать другие люди
> ///@author idimm
Бессмысленно — если уж мы тут следуем лучшим практикам, то эта информация есть в системе контроля версий. Особенно если учесть, что файл потом могут редактировать другие люди
Не соглашусь. Особенно, если речь идет об Open Source.
Особенно это относится к Open Source:
1) Подавляющая часть проектов использует систему контроля версий, и по git/mercurial/whatever репозиторию можно всегда посмотреть полную историю файла — кто написал первую версию, кто и что поправил и т.д. В случае git даже посылка изменений через патчи сохраняет правильную историю. Запись в заголовке файла в лучшем случае дублирует информацию, в худшем — просто недостоверна. Исключение составляют проекты со «сложной» историей — странные форки, мержи и т.д., когда информация из оригинального репозитория может быть утеряна
2) Большая часть проектов также содержит файл README, или CREDITS, или MAINTAINERS, или что-то похожее, который указывает на людей, отвечающих за проект или за интересующую его часть.
3) Как продолжение мысли из предыдущего пункта — очень часто в Open Source человек, который когда-то написал файл, уже давно им не занимается, а занимаются другие люди.
1) Подавляющая часть проектов использует систему контроля версий, и по git/mercurial/whatever репозиторию можно всегда посмотреть полную историю файла — кто написал первую версию, кто и что поправил и т.д. В случае git даже посылка изменений через патчи сохраняет правильную историю. Запись в заголовке файла в лучшем случае дублирует информацию, в худшем — просто недостоверна. Исключение составляют проекты со «сложной» историей — странные форки, мержи и т.д., когда информация из оригинального репозитория может быть утеряна
2) Большая часть проектов также содержит файл README, или CREDITS, или MAINTAINERS, или что-то похожее, который указывает на людей, отвечающих за проект или за интересующую его часть.
3) Как продолжение мысли из предыдущего пункта — очень часто в Open Source человек, который когда-то написал файл, уже давно им не занимается, а занимаются другие люди.
Важно превоначальное авторство.
А код часто используется не целиком, а в виде отдельных файлов. А там, ни информции из VCS, ни README. Вообще ничего, кроме файла с кодом.
Вы никогда не задумывались, почему GPL требует о себе писать в начале каждого текстового файла? Вот авторство надо писать по тем же причинам.
А код часто используется не целиком, а в виде отдельных файлов. А там, ни информции из VCS, ни README. Вообще ничего, кроме файла с кодом.
Вы никогда не задумывались, почему GPL требует о себе писать в начале каждого текстового файла? Вот авторство надо писать по тем же причинам.
Я что-то плохо себе представляю такой часто встречающийся use case, который требует выдергивания отдельных файлов из проекта.
Кроме того, зачем нужно первоначальное авторство файла? Как пример — замечательный 165Kb файл ffmpeg.c из одноименного проекта. Сверху как часть преамбулы GPL написано «Copyright © 2000-2003 Fabrice Bellard». Ну вот первоначальный автор указан, а толку с того? 13 лет с тех пор прощло, Беллард уже лет 10 как не касался FFmpeg вообще, файл был переписан чуть более, чем полностью десятками людей (буквально, git blame показывает, что за авторством Белларда в этом файле остались только пустые строчки и строчки из одного символа скобочки).
Про GPL — подозреваю, требует такое для защиты от «включения дурака» по типу «ой а я не знал что этот файл был под лицензией, на нем же не написано».
Кроме того, зачем нужно первоначальное авторство файла? Как пример — замечательный 165Kb файл ffmpeg.c из одноименного проекта. Сверху как часть преамбулы GPL написано «Copyright © 2000-2003 Fabrice Bellard». Ну вот первоначальный автор указан, а толку с того? 13 лет с тех пор прощло, Беллард уже лет 10 как не касался FFmpeg вообще, файл был переписан чуть более, чем полностью десятками людей (буквально, git blame показывает, что за авторством Белларда в этом файле остались только пустые строчки и строчки из одного символа скобочки).
Про GPL — подозреваю, требует такое для защиты от «включения дурака» по типу «ой а я не знал что этот файл был под лицензией, на нем же не написано».
Я что-то плохо себе представляю такой часто встречающийся use case, который требует выдергивания отдельных файлов из проекта.
Мнге странно такое читать, потому что я постоянно встречаю цельные куски библиотек не в виде отдельных проектов, а в виде исходников засунутых в проект.
Например, вот прямо сейчас я фрилансю над чужим проектом, внутри которого лежат libpng, libjpeg, openssl, tinyxml, ffmpeg. Каждый из них лежит в своем отдельном каталоге. Но в них только h и с файлы. Никаких readme и в помине нет. И я такое вижу постоянно. Мне даже немного завидно, что есть программисты которых это удивляет. :)
Ну извините, это не open source, а какой-то говнокод. Любые нормальные проекты либо вообще не включают в свое дерево другие библиотеки (а требуют их как зависимости), либо берут все дерево целиком со всеми файлами и просто подтачивают билд-машинерию под свои нужды (и трекают все изменения в своем репозитории).
Брать только *.[ch]* — это как минимум некорректно по отношению к разработчикам, а как максимум — нарушает лицензию. К примеру, тот же GPL требует включить в каждый файл преамбулу, а в проект — полный текст лицензии. Взять файлы с преамбулой, выкинуть файл с текстом лицензии и распространять результат — нарушение прав разработчиков.
С прагматичной точки зрения — пусть есть такой проект. Даже в нем очевидно, что файлы из каталога tinyxml относятся к tinyxml (да и в самих файлах написано, что это tinyxml); всё, можно закрывать проект и идти на сайт tinyxml — там вся информация по ответственным людям есть. Зато неочевидно, что весь код в этих файлах был написан авторами tinyxml, т.к. хрен его знает, что в этом проекте натворили еще, помимо собственно «кражи» кода из чужих проектов.
И даже в этом примере информация о собственно авторе файла (физическом лице) не нужна. Максимум нужно знать проект, к которому относится файл (а ее обычно пишут как часть лицензионной преамбулы).
Брать только *.[ch]* — это как минимум некорректно по отношению к разработчикам, а как максимум — нарушает лицензию. К примеру, тот же GPL требует включить в каждый файл преамбулу, а в проект — полный текст лицензии. Взять файлы с преамбулой, выкинуть файл с текстом лицензии и распространять результат — нарушение прав разработчиков.
С прагматичной точки зрения — пусть есть такой проект. Даже в нем очевидно, что файлы из каталога tinyxml относятся к tinyxml (да и в самих файлах написано, что это tinyxml); всё, можно закрывать проект и идти на сайт tinyxml — там вся информация по ответственным людям есть. Зато неочевидно, что весь код в этих файлах был написан авторами tinyxml, т.к. хрен его знает, что в этом проекте натворили еще, помимо собственно «кражи» кода из чужих проектов.
И даже в этом примере информация о собственно авторе файла (физическом лице) не нужна. Максимум нужно знать проект, к которому относится файл (а ее обычно пишут как часть лицензионной преамбулы).
К примеру, тот же GPL требует включить в каждый файл преамбулу, а в проект — полный текст лицензии. Взять файлы с преамбулой, выкинуть файл с текстом лицензии и распространять результат — нарушение прав разработчиков.
GPL лицензия — общая на проект. GPL не требует включать все файлы проекта в свой проект.
GPL требует, чтобы вы публиковали свой проект в котором используете GPL код тоже под GPL. И копирайт нельзя менять. ТО что вы там придумали по впихиванию всех файлов исходного проекта — к реальности не имеет никакого отношения.
Иными словами — если вы берете проект GPL и берете из него кусок кода — это ок, если ваш проект тоже GPL. Вы не имеете права удалять преамбулу из этого файла и вы не имеете права удалять копирайт(именно поэтому в файл и надо добавлять авторство).
Вы придумываете какие-то свои правила использования Open Source. Практика от ваших правил использования отличается.
И самое смешное, что совершенно не важно, говнокод там или не говнокод использует ваши исходники. Потому что суть всех этих пометок и лицензий как раз в том, чтобы независимо от качество использующих проектов сохранялся копирайт и лицензия.
Пример из того же FFMpeg (в заголовке каждого файла):
> You should have received a copy of the GNU Lesser General Public
> License along with FFmpeg; if not, write to the Free Software
> Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
В самой лицензии есть требование, что каждая копия программы или ее части должна сопровождаться полной копией лицензии. Соответственно, если «взяли только исходные файлы» и не положили куда-то в другое место в исходниках копию лицензии, то лицензия нарушена (если заимствующий проект уже под той же лицензией, то, конечно, не обязательно).
Копирайт — штука, не эквивалентная авторству; некоторые проекты требуют явного отказа от копирайта в пользу какой-либо компании.
А теперь самое главное:
> ///@author idimm
это не копирайт и не лицензия, а просто комментарий об авторе кода. Который, по-моему, не имеет смысла. Я выдал аргументы, почему так считаю. Аргументов о противном пока не видел. Расскажите, пожалуйста, в чем польза этого комментария? Как вам он может быть полезен и для чего вы эту информацию можете использовать?
> You should have received a copy of the GNU Lesser General Public
> License along with FFmpeg; if not, write to the Free Software
> Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
В самой лицензии есть требование, что каждая копия программы или ее части должна сопровождаться полной копией лицензии. Соответственно, если «взяли только исходные файлы» и не положили куда-то в другое место в исходниках копию лицензии, то лицензия нарушена (если заимствующий проект уже под той же лицензией, то, конечно, не обязательно).
Копирайт — штука, не эквивалентная авторству; некоторые проекты требуют явного отказа от копирайта в пользу какой-либо компании.
А теперь самое главное:
> ///@author idimm
это не копирайт и не лицензия, а просто комментарий об авторе кода. Который, по-моему, не имеет смысла. Я выдал аргументы, почему так считаю. Аргументов о противном пока не видел. Расскажите, пожалуйста, в чем польза этого комментария? Как вам он может быть полезен и для чего вы эту информацию можете использовать?
В самой лицензии есть требование, что каждая копия программы или ее части должна сопровождаться полной копией лицензии. Соответственно, если «взяли только исходные файлы» и не положили куда-то в другое место в исходниках копию лицензии, то лицензия нарушена (если заимствующий проект уже под той же лицензией, то, конечно, не обязательно).
Еще раз:
«GPL лицензия — общая на проект.»
Одна.
И я по прежнему не улавливаю связи между указанием авторства и файлом лицензии. Авторство не в лицензии пишут, а в README. GPL не обязывает копировать README.
это не копирайт и не лицензия, а просто комментарий об авторе кода.
Подпись авторства — частный случай копирайта.
Подпись авторства — частный случай копирайта.
Вообще-то, нет. Между копирайтом и авторством связь весьма косвенная.
Да нет, вполне прямая. Указание своих данных позволяет вам доказать, что авторское право на произведение принадлежит вам.
Подпись является частью авторского права(копирайта).
«Подпись авторства — частный случай копирайта.» Копирайт здесь как «обозначение авторского права, а не как само право».
Подпись является частью авторского права(копирайта).
«Подпись авторства — частный случай копирайта.» Копирайт здесь как «обозначение авторского права, а не как само право».
Указание своих данных позволяет вам доказать, что авторское право на произведение принадлежит вам.
Авторское право или право авторства? Для доказательства авторства подпись не обязательна. А для доказательства наличия (всех) авторских прав подписи, наоборот, недостаточно.
Не обзятельно и не достаточно. Это просто способ успросить себе жизнь и не более того.
FSF рекомендует добавлять подпись в каждый исходник(но не требует), и запрещает удалять или изменять подпись в форках.
FSF рекомендует добавлять подпись в каждый исходник(но не требует), и запрещает удалять или изменять подпись в форках.
Это просто способ успросить себе жизнь и не более того.
Это способ подумать, что ты упростил себе жизнь. Авторское право в его конкретной реализации может с тобой в этот момент не согласиться.
Я не юрист. Не вижу смысла глубоко в этом разбираться.
Есть GPL, есть FSF, есть их рекомендации. Зачем что-то выдумывать, если можно просто им следовать?
Есть GPL, есть FSF, есть их рекомендации. Зачем что-то выдумывать, если можно просто им следовать?
Я не юрист. Не вижу смысла глубоко в этом разбираться.
Вот отсюда и появляются утверждения "Подпись является частью авторского права(копирайта)", хотя подпись — это просто подпись.
Есть GPL, есть FSF, есть их рекомендации. Зачем что-то выдумывать, если можно просто им следовать?
Затем, что надо понимать границы применимости этих рекомендаций. В частности, GPL явно ограничивает авторские права автора (простите) исходного кода.
В частности, GPL явно ограничивает авторские права автора (простите) исходного кода.
Вы бред несете. GPL не распространяется на автора. Только на пользователей.
Видимо вы «не юрист» еще больше чем я.
Вы бред несете. GPL не распространяется на автора
Правда? То есть любой исходный код может быть выпущен под GPL?
Угу, а теперь на конкретном примере.
Вот я автор, и у меня есть написанная мной программа. Бинарники, чтобы не связываться с вопросами распространения исходников. Программа написана только и исключительно мной, не по рабочему заданию, не в рабочее время, не использует чужой код — короче говоря, все авторские права бесспорно принадлежат мне. И вот я выпустил эту программу в мир под GPL.Внимание, вопрос: как этот выпуск изменил мои авторские права?
Никак.
То есть я могу воспользоваться своими исключительными правами и продать эту — напоминаю, лицензированную по GPL — программу, запретив покупателю ее дальнейшее распространение?
Верно. Гуглите ситуацию с Emacs, который долгое время будучи под GPL распространялся без исходников.
Такие штуки нарушают «этические нормы Open Source», но не саму лицензию GPL.
Повторюсь(в третий раз?) GPL на автора не распространяется. Можете делать что угодно, но нарушить GPL не можете, потому что она на вас не распространяется.
Такие штуки нарушают «этические нормы Open Source», но не саму лицензию GPL.
Повторюсь(в третий раз?) GPL на автора не распространяется. Можете делать что угодно, но нарушить GPL не можете, потому что она на вас не распространяется.
Подождите, при чем тут исходники вообще? Я задал конкретный вопрос: можно ли, не нарушая GPL, продать программу, запретив ее дальнейшее распространение покупателем?
Как при чем тут исходники? GPL предполагает возможность править исходники продукта.
Если вы отдали бинарники кому-то лицензированные по GPL, но не дали возможности получить исходники — этот кто-то не в праве рапространять бинарники!
Я еще раз повторю — гуглите ситуацию с Emacs. Там как раз пробелма была в том, что по сути кучу людей сделали нарушителями GPL, т.к. они рапространяли GPL EMacs и при этом исходников Emacs не было.
Я понимаю что вам лениво чё-то гуглить, тем более когда вы считаете себя правым. Но вот вам цитата от Столмана из-за той ситуации с EMacs:
Если вы отдали бинарники кому-то лицензированные по GPL, но не дали возможности получить исходники — этот кто-то не в праве рапространять бинарники!
Я еще раз повторю — гуглите ситуацию с Emacs. Там как раз пробелма была в том, что по сути кучу людей сделали нарушителями GPL, т.к. они рапространяли GPL EMacs и при этом исходников Emacs не было.
Я понимаю что вам лениво чё-то гуглить, тем более когда вы считаете себя правым. Но вот вам цитата от Столмана из-за той ситуации с EMacs:
If the Emacs release contains a compiled program and not its source code, anyone redistributing that release by itself would violate the GPL. We must not lead people to violate the GPL!
GPL предполагает возможность править исходники продукта.
Правда? А я думал, что GPL — это про свободное программное обеспечение.
Если вы отдали бинарники кому-то лицензированные по GPL, но не дали возможности получить исходники — этот кто-то не в праве рапространять бинарники!
Где в тексте GPL это явно написано? Я там вижу иное:
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
You may make, run and propagate covered works that you do not convey, without conditions
The GPL is a free software license, and therefore it permits people to use and even redistribute the software without being required to pay anyone a fee for doing so.
Другой вопрос в том, могу ли я вообще выложить (свои!) бинарники, не выкладывая исходников, и оставаясь в рамках GPL.
Окей, мне не сложно. Предположим, что я продаю GPL-лицензированную программу вместе с исходниками. Могу ли я запретить всем, купившим ее у меня, продавать — или иным образом распространять — эту программу дальше, как с исходниками, так и без них?
Где в тексте GPL это явно написано?
Вам не понятен пример с Emacs? Слова лидера FSF вас не убидели? :)
Это явно не написано, но это следует из самой сути лицензии.
Да и в FAQ этот вопрос разобран:
«I downloaded just the binary from the net. If I distribute copies, do I have to get the source and distribute that too? (#UnchangedJustBinary)
Yes. The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too. The exception for the case where you received a written offer for source code is quite limited.»
Окей, мне не сложно. Предположим, что я продаю GPL-лицензированную программу вместе с исходниками. Могу ли я запретить всем, купившим ее у меня, продавать — или иным образом распространять — эту программу дальше, как с исходниками, так и без них?
Вы можете распространять свой софт как вам угодно, но для того чтобы сделать ограничение на дальнейшее распространение — вам придется модифицировать лицензию. А её нельзя модифицировать. Можно только создать новую на её основе. Это уже не будет GPL. Так что нет, вы не можете сделать то что описываете. Но не из-за ограничений вашего авторского права, а из-за ограничений в использовании лицензии GPL. Это будет нарушением прав авторов лицензии.
Так что нет, вы не можете сделать то что описываете.
Это значит, что мои исключительные авторские права ограничены — до применения GPL я мог это сделать, а теперь не могу. О чем и речь.
Ерунда.
Это тоже самое, что сказать «Я сделал программу. Теперь я могу людей убивать?».
Нет, не можете. Но не из-за ограничения авторских прав.
Вы не ограничены в своих авторских правах. Вы не можете модифицировать GPL. Это касается не ваших авторских пра, а прав авторов GPL.
Модификация GPL вообещ с вашим продуктом не связана. Если вы ее отдельно модифицируете — это все равно будет нарушением. Также как и убийство кого нибудь никак не связано с вашей программой.
Это тоже самое, что сказать «Я сделал программу. Теперь я могу людей убивать?».
Нет, не можете. Но не из-за ограничения авторских прав.
Вы не ограничены в своих авторских правах. Вы не можете модифицировать GPL. Это касается не ваших авторских пра, а прав авторов GPL.
Модификация GPL вообещ с вашим продуктом не связана. Если вы ее отдельно модифицируете — это все равно будет нарушением. Также как и убийство кого нибудь никак не связано с вашей программой.
Вы не ограничены в своих авторских правах.
Как же так? У меня есть исключительное авторское право (закрепленное в ГК РФ) как угодно ограничивать распространение своего произведения. Если я приму решение выложить свое произведение под GPL, я потеряю это право.
Вы не можете модифицировать GPL.
Я не хочу модифицировать GPL, я хочу выложить свой продукт под GPL, но чтобы мне платили деньги за каждую копию.
У меня есть исключительное авторское право (закрепленное в ГК РФ) как угодно ограничивать распространение своего произведения. Если я приму решение выложить свое произведение под GPL, я потеряю это право.
Да нет же, вы вольны ограничивать как захотите. Вот только те, кто уже получил ваш продукт под GPL — не попадут под ограничение, т.к. такое решение не может иметь обратной силы. Если вы предоставили продукт под одной лицензией — уже предоставленному продукту лицензию сменить нельзя.
Я не хочу модифицировать GPL, я хочу выложить свой продукт под GPL, но чтобы мне платили деньги за каждую копию.
И как вы это сделаете без модификации GPL?
Да нет же, вы вольны ограничивать как захотите. Вот только те, кто уже получил ваш продукт под GPL — не попадут под ограничение, т.к. такое решение не может иметь обратной силы. Если вы предоставили продукт под одной лицензией — уже предоставленному продукту лицензию сменить нельзя.
А нет никакой "обратной силы", я хочу установить лицензионные ограничения сразу при выпуске.
И как вы это сделаете без модификации GPL?
Очевидно, написав в лицензионном соглашении "предоставляется по GPL, за исключением..." Текст GPL не изменен.
Очевидно, написав в лицензионном соглашении «предоставляется по GPL, за исключением...» Текст GPL не изменен.
В каком лицензионном соглашении? Если это GPL соглашение, то так делать нельзя. Если это НЕ GPL — то это НЕ GPL.
так делать нельзя
Про это и речь. Выпуск программы под GPL ограничивает мои исключительные права (или, если переформулировать, в момент выпуска программы под GPL я добровольно отказываюсь от части своих исключительных прав).
ROFL.
Еще раз написать?
Ок:
вы вправе делать с вашим продуктом все что захотите. Вы не вправе модифицировать GPL. GPL не имеет котношения к вашему продукту — это самостоятельный и отдельный продукт, не вашего авторства. Ограничения GPL — накладываются на использование GPL и к вашему продукту отношения не имеют, т.к. влияют на саму лицензию и только.
Если вы по любым условиям(GPL, не GPL) отдаете продукт кому-то, то вы даете этому «кому-то» права, которыми он может воспользоваться. В конкретно вашем примере вы даете человеку право работать с вашим продуктом и распространять его. Это НЕ является ограниченим вашего права на рапространение, т.к. вы и пользуетесь этим правом отдавая продукт под определенные условия.
Еще раз написать?
Ок:
вы вправе делать с вашим продуктом все что захотите. Вы не вправе модифицировать GPL. GPL не имеет котношения к вашему продукту — это самостоятельный и отдельный продукт, не вашего авторства. Ограничения GPL — накладываются на использование GPL и к вашему продукту отношения не имеют, т.к. влияют на саму лицензию и только.
Если вы по любым условиям(GPL, не GPL) отдаете продукт кому-то, то вы даете этому «кому-то» права, которыми он может воспользоваться. В конкретно вашем примере вы даете человеку право работать с вашим продуктом и распространять его. Это НЕ является ограниченим вашего права на рапространение, т.к. вы и пользуетесь этим правом отдавая продукт под определенные условия.
Это НЕ является ограниченим вашего права на рапространение, т.к. вы и пользуетесь этим правом отдавая продукт под определенные условия.
Да ну? До того момента "воспользования", у меня был один набор исключительных прав, а после этого момента — другой, меньший набор исключительных прав. Это не ограничение, по-вашему?
Да никуда ваши права не делись. Вы вправе делать с вашим продуктом что захотите.
Если автор печатает книгу и продает — он получает какие-то ограничения? Нет. Но те книги, котоыре он уже продал являются собственностью тех кому он их продал. А обственники могут книгку кому-то еще отдать или перепродать. По вашей логике — это тоже нарушение права автора на распространение?
Если автор печатает книгу и продает — он получает какие-то ограничения? Нет. Но те книги, котоыре он уже продал являются собственностью тех кому он их продал. А обственники могут книгку кому-то еще отдать или перепродать. По вашей логике — это тоже нарушение права автора на распространение?
Вы вправе делать с вашим продуктом что захотите.
Нет. Например, я не могу продать этот продукт кому-то, указав в договоре продажи, что покупатель получает единоличное и исключительное право использования продукта.
Если автор печатает книгу и продает — он получает какие-то ограничения?
Да, он больше не сможет заключить на эту книгу исключительный контракт.
Более того, "продукт" — это конкретный набор бинарников и исходников с включенной в него лицензией, на него права ограничены "от рождения" этой самой лицензией.
Вы не теряете никаких исключительных прав на продукт.
Теряете вы часть прав на копию продукта, которую на каких -то условиях передали другому лицу.
С чего бы это вдруг? Лицензия не распространяет свое действие на продукт автора и на самого автора. Лицензия рапространяет своей действие только на копии продукта переданные третьи лицам.
Теряете вы часть прав на копию продукта, которую на каких -то условиях передали другому лицу.
Более того, «продукт» — это конкретный набор бинарников и исходников с включенной в него лицензией, на него права ограничены «от рождения» этой самой лицензией.
С чего бы это вдруг? Лицензия не распространяет свое действие на продукт автора и на самого автора. Лицензия рапространяет своей действие только на копии продукта переданные третьи лицам.
Теряете вы часть прав на копию продукта, которую на каких -то условиях передали другому лицу.
Вот только для объекта авторского права "копия" семантически эквивалентна продукту. Если я продал "копию" с правом бесконечного распространения, фактически, в бесконечное распространение попал продукт.
Лицензия не распространяет свое действие на продукт автора и на самого автора.
Да как же? Если в лицензионном договоре написано, что исключительные права такие-то передаются покупателю, то продавец (автор) их теряет.
Авторские права появляются автоматически при создании «произведения». Если хочется заявить о своих правах явно, то Doxygen комментарий с ником автора — это неправильный способ. Правильный способ — этого использовать знак копирайта © или ©, имя автора и год публикации. Есть аргументы, не относящиеся к правовым вопросам?
Это не меняет сути. Речь про подпись авторства, а не про формат.
Знак копирайта © рядом с подписью роли не играет, как вы верно заметили. Как хочет так и записывает.
Знак копирайта © рядом с подписью роли не играет, как вы верно заметили. Как хочет так и записывает.
Я как бы совершенно наоборот заметил. Правда, https://www.gnu.org/licenses/gpl-howto.en.html со мной не совсем согласны, но и с вами тоже. В любом случае надо указывать имя автора, а не ник, и год публикации. Если нет этих атрибутов — это не заявление о копирайте с правовой точки зрения, и его можно спокойно вырезать.
Давайте определимся — к моему первоначальному комментарию есть какие-либо возражения, помимо правовых вопросов? Если есть — давайте обсудим. Если нет — то я считаю, что Doxygen команда author сама по себе не несет правовых последствий, равно как и Doxygen команда copyright.
Давайте определимся — к моему первоначальному комментарию есть какие-либо возражения, помимо правовых вопросов? Если есть — давайте обсудим. Если нет — то я считаю, что Doxygen команда author сама по себе не несет правовых последствий, равно как и Doxygen команда copyright.
Если ваш первоначальный комментарий читать как «не надо оставлять подпись в файлах», то я с вами не согласен. Я именно так прочитал и именно с этим спорил.
Если же читать как «подписывать надо подругому», то ок. Вопросов нет.
Если же читать как «подписывать надо подругому», то ок. Вопросов нет.
Я имел в виду буквально то, что написал — что именно та или такая же строчка комментария смысла не имеет. Про вопросы правового характера я тогда вообще не думал и спорил исключительно в разрезе того, что эта строчка не дает полезной информации ни для истории изменений, ни для того, чтобы найти контакты к кому-то, кто этим кодом занимается и поддерживает.
такая же строчка
Это какая?
2016 Иванов Сергей
Это такая же?
Если нет, то где ключевое отличие?
Из рекомендаций по использованию GPL:
The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.
…
Always use the English word “Copyright”; by international convention, this is used worldwide, even for material in other languages. The copyright symbol “©” can be included if you wish (and your character set supports it), but it's not necessary. There is no legal significance to using the three-character sequence “©”, although it does no harm.
\author serge — никак не работает
2016 Иванов Сергей — тоже не работает.
Copyright 2016 Иванов Сергей — работает.
PS: и еще раз — дискуссия с моей стороны изначально велась без учета особенностей копирайта. Если отбросить всё, что связано с копирайтом, то остается только информация об авторе, которая доступна из других мест, или не имеет значения вообще
The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.
…
Always use the English word “Copyright”; by international convention, this is used worldwide, even for material in other languages. The copyright symbol “©” can be included if you wish (and your character set supports it), but it's not necessary. There is no legal significance to using the three-character sequence “©”, although it does no harm.
\author serge — никак не работает
2016 Иванов Сергей — тоже не работает.
Copyright 2016 Иванов Сергей — работает.
PS: и еще раз — дискуссия с моей стороны изначально велась без учета особенностей копирайта. Если отбросить всё, что связано с копирайтом, то остается только информация об авторе, которая доступна из других мест, или не имеет значения вообще
Даже если отбросить копирайт — информация об авторстве может быть нужна. А может быть не нужна. Решать может только сам автор.
«доступна из других мест». Не доступна. Примеры приводил.
Кстати, GPL была упомянута изначально как раз из-за того, что в ней и говорит о «доступности из других мест». Вернее о том, что этой доступности может не быть.
«доступна из других мест». Не доступна. Примеры приводил.
Кстати, GPL была упомянута изначально как раз из-за того, что в ней и говорит о «доступности из других мест». Вернее о том, что этой доступности может не быть.
> «доступна из других мест». Не доступна. Примеры приводил.
Мы ходим по кругу. Ну давайте еще раз. В вашем примере есть файл, скажем, 3rdparty/ffmpeg/libavutil/sha512.c. Хочется узнать, кто автор. Хм, откуда взяли этот файл? Может быть из (внезапно) ffmpeg? Идем на гитхаб, смотрим в репозиторий ffmpeg, находим там этот файл и смотрим его историю. Готово, задача решена.
Мы ходим по кругу. Ну давайте еще раз. В вашем примере есть файл, скажем, 3rdparty/ffmpeg/libavutil/sha512.c. Хочется узнать, кто автор. Хм, откуда взяли этот файл? Может быть из (внезапно) ffmpeg? Идем на гитхаб, смотрим в репозиторий ffmpeg, находим там этот файл и смотрим его историю. Готово, задача решена.
Господа, на мелкие нападки нет времени отвечать (и смысла тоже). Предлагайте свой вариант «Привет, мир» с обоснованием.
Предлагаю:
Простой и лаконичный код, прекрасно работающий и никогда не вызывающих никаких ошибок или неопределенного поведения. Не загроможденный лишними конструкиями, что тоже важно.
#include <stdio.h>
void main(){
printf( "Hello, world!" );
}
Простой и лаконичный код, прекрасно работающий и никогда не вызывающих никаких ошибок или неопределенного поведения. Не загроможденный лишними конструкиями, что тоже важно.
Как С — соберётся, как C++ — 1.cpp:2:11: ошибка: «::main» должна возвращать «int». Это в стандарте, который g++ сейчас по умолчанию использует.
А после сборки:
$ ./test
Hello, world![chalker@pc tmp] $Моя оценка по вашему коду:
1. есть проблемы с комментированием и документированием: программа без комментария ничего не стоит, а ваша программа без комментариев.
2. есть доверие компилятору разрешать много делать по умолчанию: любая процедура (функция) возвращает результат в регистре еаx (x86), здесь компилятор это делает за вас (если делает, то добавляет следующий ассемблерный код — xor eax, eax).
3. на любое ваши замечание могу на спор придумать в 5-ть раз больше замечаний.
А вообще ваш вариант вполне себе хорош.
1. есть проблемы с комментированием и документированием: программа без комментария ничего не стоит, а ваша программа без комментариев.
2. есть доверие компилятору разрешать много делать по умолчанию: любая процедура (функция) возвращает результат в регистре еаx (x86), здесь компилятор это делает за вас (если делает, то добавляет следующий ассемблерный код — xor eax, eax).
3. на любое ваши замечание могу на спор придумать в 5-ть раз больше замечаний.
А вообще ваш вариант вполне себе хорош.
1) Излишнее документирование вредно. За комментарии в кэп-стиле a+=b; //К a приблавляется b можно получить от старшего, который будет ревьювить по шее за засорение кода. Я, кстати, ваш код именно по этой причине не пропустил бы.
Хороший код документирует себя сам. Исключение — это API, сложные алгоритмы и т.п.
2) Я доверяю компелятору. Особенно в рамках стандарта. Если я не могу доверять компилятору — я им не пользуюсь.
3) Аналогично.
Хороший код документирует себя сам. Исключение — это API, сложные алгоритмы и т.п.
2) Я доверяю компелятору. Особенно в рамках стандарта. Если я не могу доверять компилятору — я им не пользуюсь.
3) Аналогично.
программа без комментария ничего не стоит
Это высказывание ничем не обосновано. Если вы не можете по приведенному коду понять, что он делает, то вам нечего делать в программистах. Если можете — то зачем вам комментарии?
Не согласен — важен не только факт понимания программы, но и время, потраченное на это. Комментарий можно рассматривать как средство борьбы со сложностью программы.
Вот только комментарий не обязательно уменьшает время понимания программы.
Повторю — комментарий можно рассматривать как средство борьбы со сложностью программы.
… и как любое средство, оно может быть применено как в пользу, так и во вред. Что означает, что не любая программа без комментария ничего не стоит (собственно, я бы даже сказал обратное: нет такой программы, которая бесполезна без комментария, но это уже вопрос философский).
Повторю — программа без комментариев ничего не стоит. Это законченное утверждение. Как аксиома в геометрии — параллельные прямые не пересекаются. Не я его придумал — вот где это упоминается — Ален И. Голуб: Правила программирования на C и C++ — раздел 20. Если не согласны — это ваше личное мнение, не надо навязывать его другим. Писать или не писать комментарии — скажете это авторам сложного фрагмента кода, который нужно модифицировать вчера. Я считаю что писать комментарий нужно, просто этому не учат у университетах.
программа без комментариев ничего не стоит. Это законченное утверждение.
Это утверждение не проходит проверку практикой.
Если не согласны — это ваше личное мнение, не надо навязывать его другим.
Это не только мое личное мнение, это мнение, проверенное практикой. И вот вам цитата: "The main contributor to code-level documentation isn’t comments, but good programming style" (Steve McConnell, Code Complete, p. 778)
У следующих уважаемых ребят целые главы посвящены комментированию.
Фаулер «Рефакторинг»:
Макконнелл «Совершенный код»:
Фаулер «Рефакторинг»:
Почувствовав потребность написать комментарий, попробуйте сначала изменить структуру кода так, чтобы любые комментарии стали излишними
Макконнелл «Совершенный код»:
Если код настолько сложен, что требует объяснения, почти всегда разумнее улучшить код, а не добавлять комментарии
Это теория. А вот практика. Что здесь происходит?
#include <stdio.h>
int main()
{
int flags = 0x5; // Некий набор флагов.
printf ("-parity\n" + ((flags & 0x1) != 0));
printf ("-break\n" + ((flags & 0x2) != 0));
printf ("-xon\n" + ((flags & 0x4) != 0));
printf ("-rts\n" + ((flags & 0x8) != 0));
return (0);
}
#include <stdio.h>
int main()
{
int flags = 0x5; // Некий набор флагов.
printf ("-parity\n" + ((flags & 0x1) != 0));
printf ("-break\n" + ((flags & 0x2) != 0));
printf ("-xon\n" + ((flags & 0x4) != 0));
printf ("-rts\n" + ((flags & 0x8) != 0));
return (0);
}
Вывод информации о том установлены ли бинарные флаги.
Вроде примитивный код, что тут может быть не понятно?
Вроде примитивный код, что тут может быть не понятно?
переделать так
аналогично для остальных.
inline bool is_parity(int flags)
{
return flags & PARITY_MASK;
}
аналогично для остальных.
… а на практике этот код сам по себе ужасен, потому что использует магические числа. Пока не будет честных именованных констант, комментарии его не спасут, а после появления констант (а лучше — адекватных макросов/проверочных методов) комментарии будут избыточными.
Вот из Википедии:
Давайте изменим традиционные приоритеты в создании программ: вместо представления о нашей задаче как о создании инструкций «Что делать?» для компьютера сконцентрируемся на объяснении другим людям описаний нашего видения того, что под управлением программы должен делать компьютер.
— Дональд Кнут, http://community.livejournal.com/ru_perl/249441.html
Давайте изменим традиционные приоритеты в создании программ: вместо представления о нашей задаче как о создании инструкций «Что делать?» для компьютера сконцентрируемся на объяснении другим людям описаний нашего видения того, что под управлением программы должен делать компьютер.
— Дональд Кнут, http://community.livejournal.com/ru_perl/249441.html
Будьте аккуратнее с аксиомами, а то если воспринимать их слишком буквально, придется комментировать i++.
Писать комментарии нужно там, где они действельно нужны. То есть в сложных системах, про которые вы упоминаете. И только если код не документирует сам себя.
Вы ссылаетесь на Алена Голуба. Если вы перевернете страницу, то увидите правило «Комментарий не должен подтверждать очевидное». Вот вы написали комментарий: ///@brief Главная функция, непосредственно выводящая в консоль приветствие. По коду же очевидно, что это главная функция и что она выводит текст в консоль, и второй раз повторять это нет смысла. Ваш код не буфетчица будет читать, а другие программисты, и уж если они это понять без комментария не могут, то проблемы тут явно не в отсутствии комментариев.
Писать комментарии нужно там, где они действельно нужны. То есть в сложных системах, про которые вы упоминаете. И только если код не документирует сам себя.
Вы ссылаетесь на Алена Голуба. Если вы перевернете страницу, то увидите правило «Комментарий не должен подтверждать очевидное». Вот вы написали комментарий: ///@brief Главная функция, непосредственно выводящая в консоль приветствие. По коду же очевидно, что это главная функция и что она выводит текст в консоль, и второй раз повторять это нет смысла. Ваш код не буфетчица будет читать, а другие программисты, и уж если они это понять без комментария не могут, то проблемы тут явно не в отсутствии комментариев.
В данной задаче достаточно puts
#include
int main(void)
{
puts(«Hello, world!»);
}
#include
int main(void)
{
puts(«Hello, world!»);
}
GNU Hello:
http://www.gnu.org/software/hello/
:-)
http://www.gnu.org/software/hello/
:-)
Если уж и придираться, то почему оставили без внимания то, что принтф вообще-то возвращает результат, который почти никто никогда не проверяет?
http://netnotes.narod.ru/sbm/text/t18.html
Господа, появилось много отрицательных комментариев — видно многих очень сильно задело то, что кто-то учит их писать Hello world. Это не являлось целью статьи, так что извиняйте (видно все используют принцип KISS). Однако появилась новая пища для размышлений (как минимум для меня) — это https://habrahabr.ru/post/75971/ и http://www.gnu.org/software/hello/. Так что, если есть желание поддержать автора в его начинаниях (у многих ярых комментаторов 0 статей) подумайте еще раз над своей оценкой статьи и ее значении для вас и для автора. А конструктивная критика всегда приветствуется и будет учтена в последующей работе.
О возвращаемом значении позаботились, а о переводе строки — нет.
Sign up to leave a comment.
«Привет, мир!» как инструмент для оценки навыков программирования