Храню в ней данные от парсера . Числом более 10 , а может уже и 15 эл-тов .
Хотелось бы сделать обращение к ней через цикл . Потому что иначе приходится обрабатывать каждую строку по-очереди : например выделять память , перекодировать строки в wchar и тд . И это выглядит как-то совсем криво , даже для новичка .
Почему-то никакое нормальное решение уже несколько дней не приходит .
Ну почему? Если вся структура такая, то можно (зная выравнивание) просто взять адрес первои строки и перемещаться на следующую просто добавление размера указателя.
Здравствуйте, sgenie, Вы писали: S>Ну почему? Если вся структура такая, то можно (зная выравнивание) просто взять адрес первои строки и перемещаться на следующую просто добавление размера указателя.
неужели проблем так мало, что обязательно хочется их потенциальное кол-во увеличить?
— кто-нить может эту стуктуру переименовать в класс, сделать пару виртуальных методов и внезапно все сломается
— кто-нить может вбить между сточками свое поле. или вначало его воткнуть? почему бы нет?
— Вася захардкодит переход к след указателю через 4 байта, а Петя потом соберет под x64 и будет долго ругаться с Васей
— какая-нить опция компиляции вдруг внезапно захочет вставить пробел между полями или какая-нить оптимизация вообще поля перетусует. чего бы нет-то?
— кто-нить через несколько лет начнет переписывать на C# и прифигеет от каких-то странных смещений и прыжках по памяти в бизнес-логике, сотрет все нафиг и перепишет, где-нить обязательно накосячив
DP>Храню в ней данные от парсера . Числом более 10 , а может уже и 15 эл-тов . DP>Хотелось бы сделать обращение к ней через цикл . Потому что иначе приходится обрабатывать каждую строку по-очереди : например выделять память , перекодировать строки в wchar и тд . И это выглядит как-то совсем криво , даже для новичка . DP>Почему-то никакое нормальное решение уже несколько дней не приходит .
enum
{
login,
passwd,
balance,
email,
phone,
и тд...,
last
};
wstring data[last];
for each(wstring& in data)...
Здравствуйте, __kot2, Вы писали:
__>- Вася захардкодит переход к след указателю через 4 байта, а Петя потом соберет под x64 и будет долго ругаться с Васей
Даже в Delphi есть адресная арфиметика, так что обычного ++ там будет достаточно. Нет, ну я понимаю, что настоящий си-гуру сначала всё кастует к void*, но от тогда также заведет макрос для величины инкремента, чтобы autotools нормально отрабатывали на разных платформах
Здравствуйте, __kot2, Вы писали:
__>какой-то камменоугольного века код
Ну в целом да . Ручонки еще не отросли и малость кривоваты . Пишу как лучше понимаю .
__>если прямо сильно хочется иметь доступ к элементам и по имени и по очереди, то можно их запихать все в std::map
NT>Кстати, зачем Вам понадобились wchar_t*, а не std::wstring, например?
Спасибо . Я правда не ждал такой развернутый ответ . К сожалению , в бусте я на данный момент ни в зуб ногой . Но надеюсь через полгодика разберусь и применю по назначению .
Здравствуйте, DrunkPilot, Вы писали: DP>Здравствуйте, __kot2, Вы писали: __>>какой-то камменоугольного века код DP>Ну в целом да . Ручонки еще не отросли и малость кривоваты . Пишу как лучше понимаю .
код нормальный для Си. Но сама структура — пользователь, пароль, e-mail говорит что это какая-то клиент-серверная БД веб-ерунда (коей я, например, сейчас тоже занимаюсь) а для этого Си использовали лет 30 назад, скорее всего сам выбор языка плох или книжка, на которую вы опираетесь в С++. могу поспорить это очень старая книжка. вместо того, чтобы писать много сложноотлаживаемого и сложноподдерживаемого кода вам для этой области стоит выбрать, например C# и потратить время на изучение современных подходов. иначе потом все равно все переписывать придется, а на C# все тяп-ляп и готово и нету, например, никаких проблем с выделениями памяти, сериализацией, юникодом, разработкой интерфейса и прочим.
Здравствуйте, johny5, Вы писали:
J>[/ccode] J>for each(wstring& in data)... J>[/ccode]
J>Кул?
Нет не кул. Даже представители MS рекомендуют не пользоваться этим нестандартным костылём (здесь):
> I have a question: you briefly mentioned some gotchas when using for each.
> Did you mean the C++/CLI for each (int i in v), that is also available in unmanaged code?
Yes, that non-Standard extension. (Also, "native" please, not "unmanaged".)
> I am working on our coding guidelines and I would be interested what those gotchas are
It doesn't permit in-place modification (through modifiable references). The code that the compiler generates for "for each" contains a static_cast and some other weirdness in it, and I'm not sure exactly what it's doing. That's why I strongly recommend against using it. It's just not worth it.
> and what you recommend instead.
Anything else. Handwritten iterator loops (now with auto), STL algorithms (now with lambdas), BOOST_FOREACH, whatever.
for_each() is kind of the least useful STL algorithm (its main virtue is that it says what it does, whereas all handwritten iterator loops have to be inspected to see what they're doing). transform() is most useful for transforming one sequence into another, instead of doing in-place transformations (which it's certainly capable of).
The ultimate solution will be C++0x's range-based for-loop, when it's implemented.
Stephan T. Lavavej, Visual C++ Libraries Developer
Книжка вроде нормальная . Философия c++ Эккеля . Просто пришлось параллельно разбираться с libcurl , незнакомым контролом , еще данные хранить надо где-то . В xml или json по идее . Надо еще библиотеку прикрутить . В общем решил с языком пока не заморачиваться и делать как получается . Может со временем , когда разберусь полность с плюсами , и перейду в C# .