Announcement
Collapse
No announcement yet.
GCC Developers Look At Transitioning Their Codebase To C++11
Collapse
X
-
Originally posted by pal666 View Poststatic typing is the only thing which works
Explain something to me. If there is a good type system out there, why do they all allow casts? It's like saying my nuclear reactor operates flawlessly, but in case it doesn't there is a safety latch over here. What do I need that for, I thought you said it operates flawlessly? You wouldn't need a method of escaping the type system if it was so great.
Originally posted by pal666 View Postfunctions don't contain data, at least in c++
Originally posted by pal666 View Posti know what functor is. my point is that if you are trying to explain lambdas to c++ programmers, you should use c++ meaning of terms
Originally posted by pal666 View Postthey both target jvm
- Likes 1
Comment
-
Originally posted by pal666 View Postc++ had proposal with similar syntax, it was rejected due to technical issues. you see, c++ committee has to design sane language, unlike javascript. but maybe someone comes with improved proposal in fufure
- Likes 1
Comment
-
Originally posted by pal666 View Postit's not use after free, it's null pointer dereference. same goes about second example. for use after free you need delete p.get(); for example. you can do destructive things in c++ if you really want, but at least it tries to make them visible
I had gotten to thinking about the most common user error with unique_ptr<>, which would be some form of ownership violation involving transfer. To get a use of (heap address) after free, what I should've illustrated is a case of ownership violation without transfer:
Code:int function_that_takes_ownership( int *int_ptr ) { // do some stuff... // then, an error occurs and the function decides to delete the ptr *now*, // instead of keeping it around and deleting later. delete int_ptr; return -1; }
Code:std::unique_ptr< int > p( new int( 42 ) ); function_that_takes_ownership( p.get() ); std::cout << "p = " << (*p) << "\n";
Originally posted by pal666 View Postmy argument works for simpler more common case, his argument doesn't
Like many things, it's a situation where the std improved the common case, but there's still a scenario where someone might reasonably prefer a C array. I'm not trying to argue against using std::array<> in the former case, or even necessarily the latter.Last edited by coder; 02 October 2019, 11:56 PM.
Comment
-
Originally posted by pal666 View Postboth. because std::array is safer replacement
it is advisable to leave proofing to compiler(by using std::array)- the programmer might know things the compiler doesn't and that aren't easily expressible in code.
- the compiler is not guaranteed to maintain full visibility of relevant data or actually even do any assumed bounds-checking.
Comment
-
Originally posted by cynical View PostIt works in the sense that it gives you a false sense of confidence that your code is correct.
Originally posted by cynical View PostConsider if your data has to go over the wire, where does your type information go? Oh right, into the trash because your data is now bits.
Originally posted by cynical View PostExplain something to me. If there is a good type system out there, why do they all allow casts?
IMO, it's a pointless waste of time to debate whether approach X is better than Y. It's like debating whether screws are better than nails. They each have their benefits and drawbacks. If you want a worthwhile discussion, I'd advise focusing on when and how best to use each tool.
- Likes 1
Comment
-
Originally posted by coder View PostThis is an absolutist position I don't support. Static typing allows more errors to be detected at compile time than dynamic typing. Whether you consider this a net win probably has to do with external factors.
Originally posted by coder View PostPlease, let's not be silly. It's not as if all of us here haven't done plenty of serialization/deserialization. Obviously, when you deserialize, you sanity-check/integrity-check/etc., which allows you to re-assert type guarantees.
Originally posted by coder View PostWhich kind of casts? static_cast is perfectly sensible for converting numeric types. dynamic_cast is sensible for safely recovering static type information, when it's lost. reinterpret_cast is indeed a hack, but something of a nod to C++'s more primitive and pragmatic heritage.
Originally posted by coder View PostIMO, it's a pointless waste of time to debate whether approach X is better than Y. It's like debating whether screws are better than nails. They each have their benefits and drawbacks. If you want a worthwhile discussion, I'd advise focusing on when and how best to use each tool.Last edited by cynical; 03 October 2019, 08:28 AM.
Comment
-
Originally posted by cynical View PostYou do agree that you still need to write tests and check your logic though right?
Originally posted by cynical View PostA type system does not stop you from making errors, only a certain class of errors. (not the most important ones imo)
For instance, I worked on one project where they had loads of time-related bugs, because they used standard numerical types to represent both timestamps and durations, and had no standard units. Once I introduced distinct timestamp and duration types (each of which had intrinsic units and accessor functions for getting specific units), those problems were completely solved.
If my C++ code compiles, I can be reasonably sure it's going to work as intended. On the other hand, Python code can have loads of things wrong with it, that you wouldn't know if you didn't hit that particular code path. I try to take Python on its own terms, though, and write more in idiom for that language. Still, it's hard not to be a bit annoyed when I find errors that every C++ (or even C) compiler would've caught.
At the other extreme, shell scripts are a context in which I think types would just completely get in the way.
As you mentioned, they can also facilitate a great many compile-time optimizations. In C++, it's not only about the compiler - function/operator overloads and template specializations are other mechanisms where static typing can enable performance enhancement.
Originally posted by cynical View PostAll casts. If someone, even yourself, can just change the type out from under your feet at any time, that to me is the same as no guarantees. (an extreme statement to you I'm sure )
As for dynamic_cast<>, for sure it's undesirable. Usually, it hints at a design deficiency in your code. However, it's occasionally quite useful. I don't have a great example, off hand, of where I wouldn't consider it ugly and something that should ideally be refactored away, but I'm sure I've seen a handful of such cases.
Most of the time I use reinterpret_cast I think is usually working with C libraries. Nothing much to be done about that.
Originally posted by cynical View PostI was responding to someone who claimed that static typing is the only thing that works.
Originally posted by cynical View PostI happen to believe it has a lot more to do with personality than anything else. Some like to have clear specifications for all of their types, and to outsource that required knowledge to an external system that will yell at them if they get it wrong (and they like to have precise control over all of their program, masters of the universe). Others prefer to keep that information in their mind and instead retain the flexibility to change it as their perspectives change, and as the situation demands (and don't mind ambiguity).
If you use strong, dynamic-typing, then you don't get to change your perspective on what something is without either casts or using using multiple-inheritance or interfaces - none of which are exactly "fluid", since that stuff needs to be planned out somewhat in advance.
Comment
Comment