LINUX.ORG.RU

Использование глобальных const char*

 


0

1

Будет ли такой код считаться хорошим подходом ?

static const char* gvar = NULL; //Здраво ли так объявлять глобальные char* ?
 
void func(){
 
    char path[4096];
    snprintf(path, sizeof(path), "%s%s", gvar, " - continued string ");
    
    printf ("String = %s\n", path);
}
 
int main(int argc, char *argv[]) {
 
    // .............
    if (gvar) {
        gvar = "One String";
    } else {
        gvar = "Second String";
    }
    // ............
 
    int my_condition = 1; // или 0
 
    if (my_condition) gvar = "Third String"; // просто пример, чтобы не раздувать код лишним
    func();
    return 0;
}

Есть ли вероятность , что моя строка gvar , затрется где когда нибудь другой белибердой ?

Есть ли вероятность , что моя строка gvar , затрется где когда нибудь другой белибердой ?

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

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

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

глобальные переменные всегда уродуют код. Передавай в функцию указатель const char*. (для сишки. Для C++ нужно юзать std::string или свой шаблон/класс, как в Qt).

emulek
()

Лучше глобальные переменные не юзать по возможности. В твоем случае это абсолютно не оправдано.

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

а зачем тебе вообще глобальная строка?

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

FreakMurderer
() автор топика

Будет ли такой код считаться хорошим подходом ?

Нет, сделай gvar локальной переменной в main и аргументом в func. Глобальные переменные - зло, и в 90% случаев их можно и нужно избежать.

Есть ли вероятность , что моя строка gvar , затрется где когда нибудь другой белибердой ?

Нет, если и дальше будет указывать только на строковые литералы, они в RO странице лежат.

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

И что мне передавать через десяток функций этот локальный параметр ? Нет спасибо... Хочу - глобальный, читай пред. сообщение... Возможно - это мои 10 процентов ...

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

Ну я не знаю, что такое mprotect, я нуб еще в с... А чем , плох мой пример, ну вот чем (наведите конкретный пример) - кроме того , что глобальные переменные это зло на 90 процентов...

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

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

Ну да, а почему нет?

Возможно - это мои 10 процентов ...

Нет.

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

Ну да, а почему нет?

А почему да ? А я вот не хочу заниматься лишней работой .. Убеди меня , зачем мне передавать через 10 функций этот параметр ?

Нет.

Почему нет ?

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

Открой для себя С++ и инкапсуляцию, право.

Открою, открою )) Не переживайте так.. Еще что открыть ? :)

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

В твоем случае глобальная переменная нафиг не нужна! Это ж не какая-нибудь errno...

Вот ежели бы ты обрабатывал какие-то ошибки при помощи флага, то глобальная нужна была бы...

А еще глобальные бывают нужны при реализации конечных автоматов. И очень дофига глобальных при погромировании под микроконтроллеры. Вон, пошукай по моему быдлокоду на гитхабе. Найдешь 100500 глобальных. Только не советую брать мой быдлокод за образец: я — не погромист, и мне вообще на все эти погромистские штучки насрать. Я делаю по принципу "лишь бы работало, да пошустрей (если возможно)".

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

ну-ну. Не можешь убедить, объяснить - а выпендриваешься... Очень умно..

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

Ну, коли тебе хочется — используй. Никто ж не запрещает!

А "белибердой" твоя строка затрется лишь если ты сам ее какой-нибудь белиберде приравняешь. Переменную ты туда не впихнешь — gcc сругнется. А постоянные — они на то и постоянные, чтобы никуда не деваться. Они ж даже в другой секции лежат... Если у тебя что-то изменит эти постоянные, то и самой программке достанется. И будет она хрень какую-нибудь делать, а не работать.

Eddy_Em ☆☆☆☆☆
()

И не слушай анонизмусов, которые предлагают кошерную сишечку на говно С++ заменить!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Если у тебя что-то изменит эти постоянные,

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

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

правильное использование глобальных переменных

Правильно — их лучше не использовать, кроме как, без этого не обойтись.

Ещё это может быть оправданно для «конфигурационных» переменных — set once, read a lot, но и это не факт.

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

Эти переменные может изменить рут (прямым доступом к памяти). А если это делается на микроконтроллере, то перезаписью флеша (я, собственно, на МК без EEPROM'а так и храню настроечные данные — в отдельной области флеша, которая перезаписывается при необходимости; естественно, в самой программе эти переменные обозначены как const, иначе они будут не во флеше, а в оперативке).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

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

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

Судя из ваших слов, чтобы на сто процентов оградить себя от проблем, глобальные переменные нельзя использовать НИКОГДА ? Так ?

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

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

...то просто создай структуру (нет! не как глобальную переменную), положи в эту структуру все нужные тебе переменные, и засовывай в ссылку на эту структуру во все твои функции.

это будет явно лучше чем глобальные переменные.

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

Дык, думать же надо!

Вот, кстати, хорошо, что ты про потоки вспомнил! Глобальные переменные — идеальный вариант синхронизации потоков. Естественно, мьютексы тоже забывать не надо…

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

// эх, как, все-таки, элементарно писать под компутер.. На МК запаришься всякие мьютексы рисовать!..

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от FreakMurderer

Судя из ваших слов, чтобы на сто процентов оградить себя от проблем, глобальные переменные нельзя использовать НИКОГДА ? Так ?

ну можно наверно оградить...

..но какой смысл тратить на это свои усилия, если проще не допускать такие фейлы.

(то есть — проще не делать глобальные переменные, чем делать, а потом думать как избежать тех или иных фейлов :))

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

P.S. Вспомнил, как я наткнулся на "глюк" при использовании strtok в многопоточном приложении. Но это — от собственной тупости (т.к. не знал, что strtok использует статический буфер). Заменил на "потокобезопасный" strtok_r.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от FreakMurderer

Если опустить всякую «мултипроцессорность», то это как минимум абсолютно не читабельно.

Где-то кто-то куда-то что-то записал, потом где-то кто-то другой (или другие) это читают и/или переписывают. Лапша.

По ресурсам скорей всего без особой разницы, но могут быть нюансы.

Локальные переменные лежат в stack'е, глобальные в heap'е.

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

Подскажу пример, когда без глобальных переменных не обойтись: это чтение параметров командной строки. В обработчике ты все параметры читаешь и выставляешь нужные глобальные флаги, а потом в своих 100500 функциях нужные флаги проверяешь. Иначе никак не выйдет сделать.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

идеальный вариант синхронизации потоков. Естественно, мьютексы тоже забывать не надо…

да. для мьютекса — глобальная переменная — это норм :-) .. довольно стандартное решение

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

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

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

хорошо. глобальная переменная у тебя одна — это выяснили.

а функций — сколько? (которые будут к ней обращаться)

и при каких условиях эти функции будут у тебя вызываться. когда расскажешь это — тогда мы тебе и скажем вердикт — будут проблемы или нет :-)

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

Если опустить всякую «мултипроцессорность», то это как минимум абсолютно не читабельно.

это не проблема для меня ...

По ресурсам скорей всего без особой разницы

Вот и славно...

но могут быть нюансы.

Какие ?

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

в main() хочешь эту глобальную переменную *только* 1 раз инициализировать (в зависимости от условия)..

...а потом много раз — из разных функций — читать её (и НЕ писать уже) ?

тогда нормально.

на мой взгляд

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

Вроде серьёзных проблем нет. Не собирается же туда кто-то писать с разных потоков.
Мой пример, когда нельзя обойтись без глобальных переменных:
библиотека - враппер, которая должна хранить где-то своё состояние. Если в функциях не предусмотрено какое-то хранилище состояний хотя бы под указатель (а откуда ему там взяться если эту библиотеку там и не ждут?), то другого выхода нет.

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

Совершенно верно (ну почти , не в майн, а промежуточной функции, но только один раз , и да , читать , не писать )!

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

Разные участки памяти — промахи в кеше и т.д., но для меня это уже слишком «высоко». ;) Ещё глобальные iirc хуже (если вообще) оптимизируются. Но главное — это всё же читабельность человеком.

PS: Real Programmer can write FORTRAN programs in any language. ;)

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

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

Будут проблемы или нет ? :) Окончательно ....

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

Хочется сразу подставлять глобальное значение, дабы не делать лишних вычислений , а что ?

а ничего. Ничего хорошего. Почему не устраивает передавать указатель как параметр функций? Это удобно например константностью:

1. всегда видно, какой код меняет переменную

2. если функция не должна менять переменную, её можно сделать константой.

emulek
()
Ответ на: комментарий от FreakMurderer

При таком раскладе проблем не вижу. Аминь! ;)

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