[SOLVED] C/C++ do loops - good practice or bad?

Sergei Steshenko · 06-30-2012, 03:19 PM

Quote:

Originally Posted by tuxdev

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 ...

tuxdev · 06-30-2012, 03:33 PM

Quote:

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.

Sergei Steshenko · 06-30-2012, 03:45 PM

Quote:

Originally Posted by tuxdev

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) :

Code:

my %chip_spec =
  (
  FOO_ADDR => 0x98761234,
  FOO_OFFSET => 0x678,
  ...
  TWICE_FOO_OFFSET => '(2 * FOO_OFFSET)',
  ...
  );

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.

Of course, the above can be hierarchical:

Code:

my %chip_spec =
  (
  DOO_BLOCK =>
    {
    FOO_ADDR => 0x98761234,
    FOO_OFFSET => 0x678,
    ...
    TWICE_FOO_OFFSET => '(2 * FOO_OFFSET)',
    ...
    },

  HOO_BLOCK =>
    {
    ...
    },
  );

- which in reality it is.

And I still stick to "single point of change" paradigm.

worzel1968 · 07-01-2012, 02:55 AM

Hi ntubski,

Quote:

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?