LINUX.ORG.RU

Ну теперь то точно. :)

BRE ★★
()

Не могу понять, это C++-капец или C-капец?

StReLoK ☆☆
()

Много букв, можно выжимку из документа, что конкретно появится в си?

andreyu ★★★★★
()

Давайте я повангую: никто это не будет использовать.

Deleted
()

вообще-то С-капец получается

dib2 ★★★★★
()

в следующем стандарте C появятся средства ООП

А нет ли каких-либо более весомых доказательств чем по ссылкам? Меня терзают смутные сомнения ))

mbivanyuk ★★★★★
()

Author Affiliation: Sun Microsystems, Inc

Блин, я думал и правда сантехник. Было бы эпично.

entefeed ☆☆☆
()

More fully support Resource Allocation Is Initialization as CUYOM (Clean Up Your Own Mess), both for performance and maintainability of code. The segment of a program that opens a file, creates an object, or allocates memory should also be responsible for cleanup.

хотя вот здесь неясно: каков будет синтаксис

next_time ★★★★★
()
Ответ на: комментарий от mbivanyuk

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

Lincor
() автор топика
Ответ на: комментарий от Lincor

Там как бы

This paper proposes ...

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

xaizek ★★★★★
()
Ответ на: комментарий от Stil

неймспейсы не так критичны, их можно было бы ввести в С и никто бы и не заметил

next_time ★★★★★
()
Ответ на: комментарий от xaizek

либо надо найти список принятых со ссылкой на этот документ.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/PostStLouis2014.htm. ссылка там на старый, а новый как раз был составлен на этой конференции для описания, как именно оно будет выглядеть.

Lincor
() автор топика
Последнее исправление: Lincor (всего исправлений: 1)
Ответ на: комментарий от Lincor

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

This paper proposes the addition of C++ style classes

То что предложено я вижу, а где про принято? Ткни носом чтобы я не искал полночи. Гугл молчит.

mbivanyuk ★★★★★
()
Последнее исправление: mbivanyuk (всего исправлений: 1)
Ответ на: комментарий от next_time

While automatic constructors and destructors are some of the most popular features in C++, this paper proposes this more conservative naming convention, manually writing both initClassName() and deleteClassName() methods which are called explicitly only when needed.

будут, но не будут вызываться автоматически.

Lincor
() автор топика
Ответ на: комментарий от Lincor

ну так это обычные функции тогда, а не «будут». о какой тогда «More fully support Resource Allocation Is Initialization» можно говорить?

next_time ★★★★★
()
Ответ на: комментарий от next_time

только вот если этот момент настанет, чем будет отличаться С от С++? а ничем.

В Си не обязательно делать Тьюринг-полное уродство в стиле Си++.

tailgunner ★★★★★
()
Ответ на: комментарий от next_time

о какой тогда «More fully support Resource Allocation Is Initialization» можно говорить?

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

Lincor
() автор топика
Ответ на: комментарий от mbivanyuk

прямым текстом не написано, ладно. но:

[This section applies only if the “Access specifiers” proposal is also approved.]
also approved
also

подталкивает к выводу, что N1875 уже заапрувлен.

Lincor
() автор топика
Ответ на: комментарий от Lincor

прямым текстом не написано

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

подталкивает к выводу

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

mbivanyuk ★★★★★
()

ООП и так используется практически во всех крупных проектах на Це, которые я видел.

manually writing both initClassName() and deleteClassName() methods which are called explicitly only when needed

y u no RTTI? Короче, не нужно

Gvidon ★★★★
()

Интересненько. Видел на первой странице.

HerrWeigel ★★★★
()

RIP, ага. Может геймдев, если не будет ещё захвачен хипстерами, на него перейдёт.

ranka-lee
()
Ответ на: комментарий от next_time

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

ranka-lee
()
Ответ на: комментарий от Lincor

подталкивает к выводу, что N1875 уже заапрувлен.

Нет, это всего лишь указание, что если этот документ и тот документ примут, то секция будет иметь смысл. Пока это не появится в черновике нового стандарта, никто ничего не принял (каких-то списков принятых документов не нашёл), это рабочие документы, подготовленные одним человеком, чтобы другие их оценили.

xaizek ★★★★★
()
Ответ на: комментарий от CARS

Теперь можно с чистой совестью писать «язык программирования C/C++».

Писать всегда можно было. Только на интервью мы таких не приглашаем:)

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

C/C++

Теперь можно с чистой совестью писать «язык программирования C/C++».

Писать всегда можно было. Только на интервью мы таких не приглашаем:)

CARS, Pavval, не я один считал, что языки и парадигмы C и C++ настолько различны, что писать «C/C++» совершенно безграмотно?

Camel ★★★★★
()

Фу, подонки!

Все равно это никому ненужно будет. С99-то еще не все заюзали.

unt1tled ★★★★
()

Сантехник предложил сделать второй C++. facepalm.

По теме: не нужно.

Shadow1251
()
Ответ на: C/C++ от Camel

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

Естественно, языки сильно различны. Но «на интервью не приглашаем» - обычные понты.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

В Си не обязательно делать Тьюринг-полное уродство в стиле Си++.

Что плохого конкретно в Тьюринг-полноте шаблонов C++? Тот факт, что шаблоны в C++ ущербны чуть более чем полностью, я не отрицаю.

hateyoufeel ★★★★★
()
Ответ на: C/C++ от Camel

что языки и парадигмы C и C++ настолько различны

Парадигмы они одни вообще-то для всех ЯП. Другое дело, какие парадигмы с каким ЯП более принято использовать и насколько это геморройно. А языки настолько различимы, что почти любой код на СИ является валидным кодом на C++. Правда наоборот это не работает. ;)

Про понты выше верно сказано.

peregrine ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.