Ok how about something at the other end. Is there any time in the near future when C++ might break compatibility with C(I mean something more than the slight new features of C99)?
PS. I think designated initializers would be more use to a C programmer. I agree with CornedBee that that is what constructors are for.
Last edited by lruc; 09-07-2008 at 05:52 PM.
Really? That's awesome! How do you do that for this array stored in read-only memory then?Originally Posted by CornedBee
Remember, you can't modify or 'construct' this during runtime.Code:const unsigned char __eprom lookup_table[] = { [0x5E] = 0xAE, [0x3A] = 0x4D, [0x17] = 0xB9 };
> I don't know why these have been received with such lukewarm enthusiasm.
I think it's because they're so verbose. That's why I'm kind of 'eh' about them. It's not much less typing than using assignment operators in separate statements.
Last edited by robwhit; 09-08-2008 at 10:56 AM. Reason: more to less
O_o
How do designated initializers require no runtime overhead? That's magic that is...
Soma
Assignment is not initialization!
The array example I showed above is more verbose than that initialization without DI? Hardly. It is far less than writing out an entire table of zeros with three elements changed, and have fun counting as well.
I'm afraid you will have to give me an example of what you mean by verbose DI.
Fair enough. I wasn't too clear about that.
What I meant to say, was that they aren't going to incur any more runtime overhead than the old-fashioned initialization.
That is what I meant to compare. Thanks for pointing that out.Code:struct foo { int a, b, c, d, e, f; }; // with DI foo bar = { .f = 10 }; // without DI foo bar = {0,0,0,0,0,10};
Last edited by whoie; 09-07-2008 at 05:55 PM.
Ah... well, that depends rather a lot on whether or not you are interested in every member of a structure. (I'm thinking or any given variant of the ridiculous "object oriented" crimes perpetrated on C where every structure had members nothing ever reads or writes.)What I meant to say, was that they aren't going to incur any more runtime overhead than the old-fashioned initialization.
In C++...Assignment is not initialization!
You could do it with the preprocessor in classic C89 simpler, in use obviously, than C99 with designated initializers.The array example I showed above is more verbose than that initialization without DI?
Note: I actually have no problem with designated initializers, but then I use C++ and have RAII.
Soma
> Assignment is not initialization!
Correct, but in almost all instances, you can use assignment instead of initialization.
> The array example I showed above is more verbose than that initialization without DI? Hardly. It is far less than writing out an entire table of zeros with three elements changed, and have fun counting as well.
Yes, that is a good application for that.
> I'm afraid you will have to give me an example of what you mean by verbose DI.
I mean versus C89 initialization.Code:struct a inst = { 0, 'a', "string", something.c }; struct a inst = { .id = 0, .some_char = 'a', .some_string = "string", .some_other_variable = something.c };
Why does that depend? Whether you use old-fashioned initialization or DI, anything not specified is default initialized. I don't understand the dependence that you are pointing out here.
Period. Simple assignment and initialization are two different things in both C and C++. Assignment destroys a previous value, initialization never does. You can't assign to an object declared with a const qualifier in either language. But you can initialize them in either.
I need an example of what you are talking about here. I use C++ and have RAII as well, but I don't see how RAII has anything to do with initializing an array or a POD struct. Nor do I see how preprocessor magic is simpler than the array initialization I posted upthread. That's about as simple as it gets IMO.
Until you can't because it is const or placed in read-only memory, or you'd rather initialize than assign for debugging purposes, style, coding standard, whatever, and then we are right back here. Also, assignment is more verbose than DI, because you always have to prepend the object name before the member.
Whew! I was beginning to think I was getting the shoulder shrug again!
Agreed, that is more verbose. In that case, I'd probably skip DI myself. I would point out a couple of differences though.
Using DI, there would be no need to explicitly initialize the id member. That would be default initialized to zero anyway. But, let's leave it as it is and pretend that someone was using struct a as an overlay but needed to swap the position of the first two members id, and some_char to match up with the memory image. Which one breaks if that someone forgets to update the initializer? Not the DI, and that's what I mean by less maintenance risk. It doesn't even need maintenance at all. In the old-fashioned initializer, you probably wouldn't even get a diagnostic because 0 is fine for a char and 'a' is fine for an integer type.
Well I would agree that designated initializers are useful in C, but they are less useful in C++ since we have constructors in C++. Although it certainly wouldn't hurt to re-absorb all the new features from the latest version of C into the latest C++ standard.
I don't agree - there are circumstances when you want to have a constant table. If LOTS of the entries are zero [take for example a table for your own version of "isdigit, where you have to cope with 256 character values, but only 10 have a value other than zero - this is obviously not a very realistic scenario, because there is no reason not to use isdigit - but it makes for an easy example that most of those who can follow this thread will understand without further explanation].
Now that means that you don't have to write a comment next to each of the characters.Code:char isDigitTable[256] = { ['0'] = 1, ['1'] = 1, ['2'] = 1, ['3'] = 1, ['4'] = 1, ['5'] = 1, ['6'] = 1, ['7'] = 1, ['8'] = 1, ['9'] = 1, };
The compiler will do the same as a long lost of zeros [48 of them, to be precise, asssuming we are using ASCII-based character set [1] ] with 10 ones on the end [we don't need to fill in the next 190-odd characters with zero, since that is the default for initialized arrays anyways].
[1] And if we are compiling on a non-ASCII based character set, then the compiler will support the correct digits in whatever character set is being used [assuming the compiler itself understands the character set, that is].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I'm all for DI. I fail to see how constructors can do everything they can. Constructors are better used to default initialize objects (and what if you want to specially initialize only a specific subset of objects inside an array, just like in mats's example?).
I didn't know DI worked with arrays. Yes, for those they are definitely useful and there's no suitable equivalent in C++.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
>_<
I don't know if this is a waste of time or not, but I am trying to be polite. Well, at least in this particular post...
I'm not ignoring the discussion whoie. I really did type a rather lengthy, and hopefully understandable, post and followed by a C macro example.
Unfortunately, I was also downloading an ISO and my browser crashed.
So... yea... not typing it all in again, but the short story: the designated initializers as provided by C99 fit to small a niche compared to what C++ provides by implicit partial construction and implicit destruction.
Soma *grumble*
