איש אי הכלבים

Свинство, ага. Но #pragma setlocale() должна, по идее, спасти отца русской демократии.

From:

Литерал-то, блин, юникодный! Какой locale?! Эх…

From:

-- Ты суслика видишь?
-- Нет!
-- И я -- нет. А он -- есть!


#pragma setlocale(".1251")
    wchar_t* pszLatin1String = L"\x00C5";
    printf("U%04X\n", (unsigned int) *pszLatin1String);

#pragma setlocale(".1252")
    pszLatin1String = L"\x00C5";
    printf("U%04X\n", (unsigned int) *pszLatin1String);

Печататет:
U0415
U0435

From:

Второй результат вызывает у меня полное размягчение мозгов.

From:

sobaker.livejournal.com

И это - язык программирования? Макроассемблер, блин.

wchar_t со звездочкой. Офигеть! кого волнует wchar?..

ужасный язык :)

From:

Да что уж там язык программирования.. Жизнь -- говно!

From:

Искреннее огромное спасибо!

From:

А ты чем на жизнь зарабатываешь?

From:

sobaker.livejournal.com

Топ-менеджер в ISP :)

From:

А почему тогда тебя вообще волнуют языки программирования?

From:

sobaker.livejournal.com

Ну как.. С ними связана значительная часть моей жизни (сейчас это так, хобби)

From:

nine_k

Это всё грусть от неразличения int и char в C. Принципиального :-( Кого волнует, какой был литерал, после того, как он стал unsigned int?

(А в java такого не происходит никогда, под любой локалью :-)

From:

Происходящее выше безобразие происходит на этапе лексического анализа. Неразличение int и char тут IMHO ни при чём.

А так — как раз вчера мы с Андреем пришли к выводу, что лучшим в мире языком программирования могла бы стать Java со слегка усовершенствованным си-плюс-плюсным memory management'ом, то бишь, без GC, со свободой создавать что угодно на стеке или в куче, и нормальными деструкторами.

From:

nine_k

Мне-то казалось, что оно как хранилось в виде 0xc5, так и хранится, а при *выводе* интрпретируется в соответствии с codepage, а не как unicode, и это грустно. Потому что пометить, что это символ, а не число, в сущности, никак.
Охотно допускаю, что я неправ.

Совсем без GC грустно %-) Но и с одним GC грустно. Хорошо бы иметь возможность создавать *некоторые* объекты с контролируемым временем жизни (и соотв. "нормальными деструкторами"). Хотя бы локальные переменные с ограниченным scope, как это вроде бы есть в C#: вышел из scope, и указанные объекты гарантированно померли. Ессно, компилятор гарантирует, что не допустит "утекания" ссылки за scope, etc.

From:

Мне-то казалось, что оно как хранилось в виде 0xc5, так и хранится.

Там литерал был юникодовский, то бишь, начинающийся на букву L. Хранится он безусловно 16-битно. Проблема случается именно при парсинге исходного текста.

From:

Хорошо бы иметь возможность создавать *некоторые* объекты с контролируемым временем жизни.

Богатая, кстати, наклёвывается тема. Допустим, мы заводим две кучи, одну garbage collected, для ленивых, другую традиционную, для тех, кто знает, чего делает. Интересный вопрос: размещение в той или иной куче должно быть атрибутом класса (e.g. public gc class MyGarbageCollectedClass {…}) или экземпляра (e.g. MyGarbageCollectedInstance = new gc SomeClass;)? Тот же вопрос применим и к размещению в стеке (то, что ты называешь "с ограниченным scope").

Я лично думаю, что это стоило бы сделать атрибутом класса, ибо деструктор, например, при сборке мусора теряет всякий смысл. Будут ли другие мнения?

Ещё одна видимая опция: операция типа boxing/unboxing для перехода между типами размещения.

Вообще, надо бы подробнее перетереть.

From:

nine_k

В рамках той же java это можно было бы ловко решить очередным "магическим" интерфейсом. Типа class MyClass implements ExcplicitlyManaged { ... } и у этого ExplicitlyManaged пусть будет бесхитростный метод destruct(), работающий как деструктор в смысле C++. Такой объект нужно будет явно убивать.

Это, однако, мешало бы использовать один класс (скажем, из базовой библиотеки коллекций) и с gc, и без. Тут выхода два: либо легко делаемый по месту anonymous class (всего-то написать деструктор, скорее всего, в один вызов готового метода), либо какой-то boxing/unboxing, но какой, я не представляю %-)

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

{
 scope_only File f = new File(); 
// или new File() implements ExplicitlyManaged { void destruct() {close();}}
 f.open('filename');
 bar(f);
 f.close();
}
// и в этой точке f гарантированно прибивается

Интересно, что делать, если надо не-gc-шный объект убить, а ссылки на него ещё есть. Либо бросать exception при убивании (тогда дорогостоящая проверка на наличие ссылок), либо имеющиеся ссылки на него обрабатывать как weak references сейчас, т. е. бросать исключение при обращении, если объект ссылки уже умер: тут даже особо переделывать ничего не придётся.

Ещё хорошо бы иметь несколько независимых куч и возможность говорить
Foo my_foo = new Foo(1) on that_heap_of_mine;
Ради того, чтобы можно было говорить в нужный момент that_heap_of_mine.gc() -- если куча эта небольшая (я ж сам контролирую, что в ней завожу), то и gc пройдёт быстро и хоть как-то контролируемо. Вопрос, конечно, совместимо ли это с применяемыми нынче алгоритмами gc.
(Похожая фича с многими кучами была в движке Doom.)

From:

yms.livejournal.com

Компилятором правильным пользоваться надо :) На VC++ .NET (т.е. 7.0) такого не обнаружено - выдаёт U00C5. А 6.0 - действительно, выпендривается.

From:

Иначе почему держаться на устаревшем по всем параметрам компиляторе и не перейти на куда более нормальный 7.0 или даже 7.1?

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

From:

1. Большой проект не всегда сразу соберется другим компилятором.
2. Кто-нибудь может объяснить тот забавный факт, что драйвера можно собирать только VC 6.0?

From:

vba.livejournal.com

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

From:

1. Корректно написанный с точки зрения С++ проект не вызвал никаких претензий компилятора :) А вот те куски, которые были написаны с использованием "расширений" стандарта от MS да, пришлось править. Кстати при переходе нашли несколько ошибок :)))

2. Никогда не писал драйвера, увы. Может дело в библиотеках? Ибо приложения, собранные 7.* требуют .Net dll-к (нам сам .Net на клиентские места ставить не понадобилосб). Кстати, а что, драйвера уже на С++ пишут?

From:

1. А много их есть, корректно написанных проектов? А если это проект размером в полтора миллиона строк кода? И дело тут даже не столько в расширениях от MS, сколько в том, что VC 6.0 делался еще без оглядки на стандарт C++, поэтому при компиляции современными компиляторами может вылезти куча говна, которое раньше попросту прошло незамеченным. Так что при переходе еще как найдут кучу ошибок, только вот на их исправление в конкретный момент времени может не быть.

2. Драйвера, очевидным образом, пишутся без использования стандартной RTL компилятора. Там для этого системная RTL есть. И, кстати, статическую линковку еще никто не отменял. Что же до драйверов на C++ -- а какая, собственно, разница, на C писать или на С++, покуда компилятор один.

From:

1. Ну эт как всегда от драйвера ruki.sys зависит :) Если же команда в основном MS-C++ программеров то да, беда :( Есесна что-то вылезет, но ничего страшного не было, а перетащили мы много, можно не будем меряться строками кода?

2. Если и с первым беда, то я просто боюсь предположить что народ умудрится начудить с плюсами ...

From:

Замечу со своей стороны, что большие проекты редко бывают полностью самописными. Есть такая мерзкая вещь, как third party.

From:

Или вы берете головняк по переносу из на себя? А так да, есесно все сторонние библиотеки которые идут в исходника были проверены на перенос в 7-ку. До перехода. Собственно и заморачиваться поиском дистрибутива я начал если правильно помню только после того, как boost стал нормально компилиться 7-кой, это был для меня как бы сигнал что на компилятор уже можно смотреть.

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

Скрещивать приложения на 7-ке с библиотеками, собранными 6-кой особо не приходилось, но однако Qt, с которой начинали работать еще под 6-кой, нормально используется и под 7-кой.

From: