I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?
Contracts for C
71–80 of 114 posts
Re: Contracts for C
#72Earlier quoted context omitted.
> Digital Mars C++ has had contracts since, oh, the early 1990s? I think that implementations trying out their own experimental features is normal and expected. Ideally, standards would be pull-based instead of push-based. The real question is what prevented this feature from being proposed to the standardization committee.
It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.
Ironically, over the years, C++ has adopted many features popularized by D.
(like contracts!)
C++ should adopt a few more D features, like https://www.digitalmars.com/articles/C-biggest-mistake.html, compile time expression evaluation (C++ did it wrong), forward references, and modules that work. C++ should also deprecate the preprocessor, a stone-age kludge that has long been obsolete.
Re: Contracts for C
#73Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh
You're welcome!
Re: Contracts for C
#74I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?
Ada / SPARK has contracts, too, that can be proven at compile-time. In fact, Ada alone suffices, it has pre- and post-conditions. I think Ada has more libraries than Eiffel does. Does anyone even write Eiffel? I am really curious if it is still alive anywhere, in some form.
Re: Contracts for C
#75Earlier quoted context omitted.
Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?
People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…
Re: Contracts for C
#76Earlier quoted context omitted.
People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…
> People chose C because they liked C. Of course they don't want C to change. The same thing can be said for every other language, yet they change.
Re: Contracts for C
#77Earlier quoted context omitted.
Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?
The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…
Re: Contracts for C
#78Earlier quoted context omitted.
The vast majority of C programmers will agree that they don't care for any of the new features, as is clearly evident by the fact that almost nobody elects to use the latest standards. The "most popular programming languages" are irrelevant here. C and C++ are standardized languages, and also the tools we use for code that actually matters. A standard that can't be implemented is worthless, and even the "3 high quali…
> The vast majority of C programmers will agree that they don't care for any of the new features,(...) I think this belief is based on faulty assumptions, such as survivorship bias. C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.…
Zortech C++ is what gave C++ critical mass to succeed.
P.S. before ZTC++, the traffic in the usenet C++ newsgroup was neck-and-neck with the objective C newsgroup. After ZTC++ was released, traffic in the C++ newsgroup took off and the objective C one faded away. Borland saw our success, and pivoted away from their nascent attempt at an OOP language towards implementing Borland C++. Microsoft then also abandoned their OOP C project (called C) in favor of developing C++.
(I've never been able to get any information about C, I was just told about it by a Redmondian.)
Re: Contracts for C
#79Earlier quoted context omitted.
The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…
Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.
Re: Contracts for C
#80Earlier quoted context omitted.
Most single C implementations have died out. There is hardly any C compiler worth using that isn't equally a C++ compiler . In fact, there is any C compiler left worth using that hasn't been rewriten into C++.
That may be true in your bubble, but I don't think this is true in general. There are still a lot C compilers out there, compared to 3 or 4 that do C++.