ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That's a (not-that-great) solution to a problem that wouldn't have existed in the first place if you used something with decent scoping.
If you use a static const variable, and the compiler can determine you never ever try to take the address of it (so there's no pointer shenanigans to to try to ninja-modify the value), the compiler is legally allowed to treat it as a true constant (and almost all compilers do, when optimizations are turned on).
The scope of my problem was primarily Verilog; "C" defines were automatically generated from Verilog ones, and the names were preserved, so both HW developers and "C" programmers could use the same names for the same things.
...
I notice that, for example, highly skilled C++ programmers are often weak in other languages/approaches. E.g. using an advanced script to autogenerate things often sounds outlandish to them. Luckily, in VLSI design world we were not constrained by "pure programmers" taboos ...
I notice that, for example, highly skilled C++ programmers are often weak in other languages/approaches. E.g. using an advanced script to autogenerate things often sounds outlandish to them. Luckily, in VLSI design world we were not constrained by "pure programmers" taboos ...
It's a matter of which techniques you use by default. Unless you have a specific reason to use a #define over a static const (which in this case you *do*), then you should generally use a static const, as it's the generally superior technique. Just because it's *generally* better doesn't make it better in *all* cases, as your example proves.
It's a matter of which techniques you use by default. Unless you have a specific reason to use a #define over a static const (which in this case you *do*), then you should generally use a static const, as it's the generally superior technique. Just because it's *generally* better doesn't make it better in *all* cases, as your example proves.
You might be still missing my point. In a multi-language environment I do something like this (using, for example, Perl code/data as the primary spec) :
and then from the above I can generate whatever I like - Verilog defines, "C" defines, "C" static const members, C++ public static const class members, etc.
But again, what is the upside to Hungarian notation?
I like my little notation system (it really only shows the type of the variable) because knowing the type can be important to avoid these errors:
1. Incorrect casting - and I always do explicit casts.
2. Problems with pointers - can be a big source of errors.
Here's another question: I have seen people do static_cast to convert an int to double, wondering if there is any advantage in doing this as opposed to doing an ordinary (double) cast, there are no classes involved?
Last edited by worzel1968; 07-01-2012 at 02:58 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.