C/C++ merger

This is a discussion on C/C++ merger within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by phantomotap Unfortunately, I was also downloading an ISO and my browser crashed. I _HATE_ it when that ...

  1. #31
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by phantomotap View Post
    Unfortunately, I was also downloading an ISO and my browser crashed.
    I _HATE_ it when that happens.
    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*
    I don't think there is any argument on that side - there are all sorts of things we can do in constructor/destructor that are practically impossible to do in C [without much messier code at least]. I also do not think one is a replacement for the other - the DI is a much better solution to arrays and structs where only a (small) part of the data needs to be initialized.

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

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by phantomotap View Post
    >_<

    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*
    That does suck, but perhaps I can offer advice.
    Using Firefox and the Session Manager add-on, you should be able to recover from lost information if the browser crashes since it saves information on pages and can recover it if the browser crashes.
    And as for the download, all I can suggest is a good download manager. GetRight is my favorite.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #33
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Well I didn't say DI was useless in C++, I just said it was less useful than in C since C doesn't have constructors.
    Plus in C++ most member variables are private since C++ code usually follows proper encapsulation...
    I think C++ should always re-synchronize with the latest C standard to pick up the new features, otherwise the 2 languages will start to become more and more incompatible.

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    ...And there would probably be less of a chance for a successor for C.
    I will keep hoping for that.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #35
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    C++ does resynchronize with C in some aspects. However, not with the complex type (there's already a std::complex), not with VLAs (there's already std::vector) and not with DI (no idea why - apparently no one proposed it).

    C1x is already being planned.
    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

  6. #36
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    Quote Originally Posted by CornedBee View Post
    [...]and not with DI (no idea why - apparently no one proposed it).
    There's some reasons behind this paper from Stroustrup regarding the proposed Initializer Lists http://www.open-std.org/jtc1/sc22/wg...2006/n2100.pdf (pdf). Although I'm not sure I follow all of the arguments against DI. In any case, with the inclusion of Initialization Lists, DI becomes mostly redundant.

    On one note though, I find the DI syntax for initialization of arrays absolutely hateful and it has no place in C++.

    As for the issue of C++ and C merging, I don't think Stroustrup ever discusses the issue outside the realm of wishful thinking, neither is that something that takes away his sleep. In fact, on his own website he ends up dismissing the question entirely and addressing instead the need to eliminate incompatibilities between both languages.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #37
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    There's nothing about the DI part we're discussing here in this paper. It only discusses the semantics of initializer lists with casts in general, without respect for the contents of the initializer list. (Judging by the example the paper gives, these semantics are quite insane.)
    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

  8. #38
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    I' not going through the paper again. You can read him discussing compatibility to C99 features (DI on this case) somewhere.

    The whole other reasons are discussed when talking about the difficulties behind initializer lists.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #39
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by phantomotap View 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.
    Ouch. I'm sorry to hear that. I would have liked to read it.

    Quote Originally Posted by phantomotap View Post
    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.
    Well, I can only conclude that if it is too hard to type in again, then the macro can't be simpler than the example I posted upthread. I was also ready to break it by adding more and more dimensions. I really wanted to sandbag you with that! (only kidding of course, I'm really just poking you so that you'll get angry and post it )

    I would also echo matsp's opinion that one is not really a good replacement for the other. There is no competition here, one is clearly superior over another depending on the circumstance. Constructors for the most part, but DI for arrays and POD structs when it makes sense. Sometimes I don't want a constructor or a destructor, because they don't make any sense for the object or they are even a waste of my time. Sparse lookup tables are a perfect example of that. Some structures for interfacing with a C library or C based API are another.

  10. #40
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by Mario F. View Post
    There's some reasons behind this paper from Stroustrup regarding the proposed Initializer Lists http://www.open-std.org/jtc1/sc22/wg...2006/n2100.pdf (pdf). Although I'm not sure I follow all of the arguments against DI. In any case, with the inclusion of Initialization Lists, DI becomes mostly redundant.

    On one note though, I find the DI syntax for initialization of arrays absolutely hateful and it has no place in C++
    Hateful? Moreso than the array initializer's that C++ has right now? I doubt it. Perhaps DI isn't going to be accepted by the snobs, but I could care less. It's useful and it's a win-win IMO.

    I searched through that doc for 'designated initializers' with no hits, the word 'designated' doesn't even appear in the document. And if you consider that DI is redundant because of the inclusion of initialization lists, then I have to believe you don't understand what it even is. All I saw in the examples in that document were initializers like {1,2,3.14}. Don't get me wrong, C++ needs a solution for initialization lists, but that's the step before DI. Not a replacement for it.

  11. #41
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    Well, searching for "designated initializers" in a document about "initializer lists" is not going to help you. But actually reading the document will because the issue is implicit on some parts of the discussion when he mentions some of the difficulties in implementing "initializer lists".

    I'm not against the inclusion of DI, but I'm not in favor either. I guess I'd give it the same shrug you've seen from others you mentioned. However the syntax in C is unlike anything we have in C++, so that definitely is a point against. If I'm snob because I would like for the programming language syntax to remain coherent, so be it. A big part of the text on top is in fact the discussion of syntactic issues to do with Initializer Lists, so you can see i'm not the only one.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #42
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by Mario F. View Post
    Well, searching for "designated initializers" in a document about "initializer lists" is not going to help you. But actually reading the document will because the issue is implicit on some parts of the discussion when he mentions some of the difficulties in implementing "initializer lists".
    I'll take your word for it. Again, it's the step before, and I would have read it if it applied directly to this particular point. I'll get around to it eventually.

    Quote Originally Posted by Mario F. View Post
    I'm not against the inclusion of DI, but I'm not in favor either. I guess I'd give it the same shrug you've seen from others you mentioned.
    I guess that's a promotion from hateful, so I guess that's good.

    Quote Originally Posted by Mario F. View Post
    If I'm snob because I would like for the programming language syntax to remain coherent, so be it.
    *shrug* "Syntax is a secondary issue, and it appears that programmers can learn to love absolutely any syntax." I wonder who said that? Must've been the other Bjarne.

  13. #43
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by whoie View Post
    Must've been the other Bjarne.
    I didn't know that Bjarne Riis knew anything about computer language syntax - that is the only other Bjarne I have heard of...

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

  14. #44
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    Quote Originally Posted by whoie View Post
    I guess that's a promotion from hateful, so I guess that's good.
    Do me a favor and don't play word games with me. I'll never be in the mood, son. The C DI syntax is hateful, yes. That's my opinion. You want to argue that with actual arguments, shoot. Give me one reason why that syntax makes sense in anything C++. To me it even looks like it was hammered down onto C syntax with a bent nail and a rock for hammer.

    Just stop with the "snob", other superlatives, and word games.

    quote]*shrug* "Syntax is a secondary issue, and it appears that programmers can learn to love absolutely any syntax." [/quote]

    In a way yes. I like Python syntax for instance... and even C++ syntax, go figure -- something so many people despise. But I don't like it when one language syntax is all over the place ruining my carpet. So I wouldn't agree syntax is secondary.

    A lot of effort has always been put by the Committee in matters of syntax with respect to new additions to the language and changes to the existing features. Consistency has always been the major goal. You can read it in about any paper dealing with these changes now and in the past. So it has nothing of secondary.

    You can however disagree with my opinion on that syntax having no place in C++. That makes a lot more sense than dismissing the whole level of expression of a programming language to a "secondary issue"
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  15. #45
    Registered User
    Join Date
    Jul 2003
    Posts
    110
    Quote Originally Posted by Mario F. View Post
    The C DI syntax is hateful, yes. That's my opinion. You want to argue that with actual arguments, shoot. Give me one reason why that syntax makes sense in anything C++. To me it even looks like it was hammered down onto C syntax with a bent nail and a rock for hammer.
    All this time, I thought initializing arrays and structures WERE something C++. I simply don't understand your perspective. Why isn't it C++? From what I see, you seem to be saying that:

    Code:
    // C++
    const int a[] = {0,0,0,0,0,0,3,0,0,0,0,42,0,0,0,0};
    
    // Not C++
    const int a[16] = { [6] = 3, [11] = 42 };
    
    // used like
    yz_bucket = a[pulse_prefix & 0xFu];
    And I fail to see what is so "Not C++" about that.

    Just stop with the "snob", other superlatives, and word games.
    I'll stop, but hating something useful and productive just because it "isn't C++" is being that which I shall not speak of. If C++ has changed its design goals, then perhaps you are right, it isn't C++ anymore. But one of the goals was so that a programmer wouldn't want to "drop down" to C because it offered something C++ didn't. DI isn't strictly necessary, I agree with that, but it is very useful. If I am writing a decoder of some sort, non-volatile lookup tables become very central to the program. In those types of applications, DI can be a huge bonus. Is C++ supposed to be a language for systems programming, or not?
    Last edited by whoie; 09-09-2008 at 01:40 PM.

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. problem in file merger program
    By san_crazy in forum C Programming
    Replies: 6
    Last Post: 07-09-2008, 07:52 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21