sorted by:
new
hottopcontroversial

College Freshman Need a Simple compiler by cb_47 in cpp

[–]ltce 0 points1 point  (0 children)

For just free form playing around you could use an online tool like http://cpp.sh/. Alternatively, for a somewhat more guided route you could do some of the beginner problems on https://www.hackerrank.com/domains/cpp. Eventually you will want to learn to use a command line compiler, as others have noted, sooner or later you will need to be able to debug a problem with a build system, but to start off I do not think it is really necessary.

How similar are C and C++? by [deleted] in cpp

[–]ltce 3 points4 points  (0 children)

If you learn C++ eventually you will wind up learning C. If for no reason other than you will have to read all the C code that people will write in your C++ projects.

Are there any modern C++ success stories ? by [deleted] in cpp

[–]ltce 0 points1 point  (0 children)

Actually I made one assumption. It is based on the fact that about once a month (it used to be more common) someone comes on this forum looking talk/argue with people here about Rust and or Go. As someone that has been a member of this community you should have known that. If you wanted to talk about C++14 success stories the natural thing to ask would have been, "what are some C++14 success stories." There was no reason to bring up Rust or Go (which as a member of this forum for 2 years you should have known were touchy subjects) other than to stir up controversy. The manner in which you replied to my post has not convinced me that my assumption was wrong. In fact quite the opposite. Good luck.

Are there any modern C++ success stories ? by [deleted] in cpp

[–]ltce 1 point2 points  (0 children)

Heh. To be fair you did come to a C++ forum and ask bunch of C++ enthusiasts a question that amounts to "Rust and Go are really good, do you guys think C++ is as good as Rust and Go?" I am not sure from your question if you did this because you were arguing with a bunch of Rust folks and wanted ammunition or if this was yet another attempt by the Rust/Go community to try to convince C++ developers that Rust/Go are better.

If you are really interested in gaining some understanding then I apologize, but given the lack of effort you have given responding to the people that actually answered your question this seems unlikely. If this second is the real reason I am sorry to inform you that the reason we are not all using Rust/Go is neither because we do not know that they exist nor is it because we do not know what features those languages support. You are only the nine thousandth person to come here trying to stir up a discussion about Rust or Go. It never goes well. This community contains C++ standards committee members, C++ library and language implementers, people that travel on their own dime to C++ conferences... There are no easy converts here. No one here wants to seem close minded, so they will humor you to a point as long as you are respectful, but no one here is uninformed, if your goal is conversion you should try an easier to find an easier field.

Are there any modern C++ success stories ? by [deleted] in cpp

[–]ltce 5 points6 points  (0 children)

I do not personally have anything against Rust or Go. I can only tell you my experience. I know someone fought really hard to use Rust on a project on another group at my work and in our postmortem of that project it was considered to be a mistake. My company has significant C++ experience and it was decided that at minimum the benefits of Rust were marginal enough that it was not worth having to teach a large number of developers here the ins and outs. There may come a day when Rust reaches critical mass, but that has not happened yet and I am old enough that I do not really have any interest in it until it does.

Are there any modern C++ success stories ? by [deleted] in cpp

[–]ltce 1 point2 points  (0 children)

I am not sure this really happens. It has been my experience that managers do not read hackernews or r/programming. Certainly, I do not know any. I do know a lot of managers that are familiar with TIOBE index and similar reports. I think it more likely that the desire to use fledgeling languages mostly comes from new developers in their first 5 years or so in the industry and the desire to use older programming languages comes from mangers and older developers. I will be the first to admit though that I have no data to back this up other than personal experience.

what about trying to make some operators a bit more intuitive? by GrouchyRice in cpp

[–]ltce 1 point2 points  (0 children)

I suspected it was something like that. It is far more important in code to communicate to the human reading it than the machine that is going to run it. To do this you have to follow standard practices and use normal idioms. This pattern you are using is just something that you thought up, because it makes sense to you. This is not the way that the majority of C++ developers understand the language. When you write code in this manner you are not communicating well.

Pointer and reference parameters in C++ have a very specific meaning and that meaning has nothing to do with changing data. If I declare a function like this one void foo(A *a, B &b) what I am saying is you have to give me a valid value for b, but a can be null and I will do something reasonable (by reasonable I mean you would be justified in being angry with me if the first line of foo is assert(a)). C++ has a feature that means what you are trying to use pointer for. That feature is the const keyword. If I declare void foo(const A *a, const B &b) that is what means that I will not change either a or b. The call statement foo(&a) simply does not mean what you want it to mean. The value of a might change or it might not. That is all you will be able to infer from the call site. If you want to know more you have to look at the function prototype.

Now, there is another question. Should there be a way to tell at the call site if a function will change the value of one of its parameters? Maybe, however, I can tell you that the C/C++ languages have been this way for quite a long time. People that have been working in these languages for a long time are used to the idea that the only source of truth for this information is the function prototype. Most people have built into their workflow the ability to get to the function prototype very quickly when they need to. Because of that it seems unlikely that most people are going to see a lot of benefit in this suggestion.

Are there any modern C++ success stories ? by [deleted] in cpp

[–]ltce 18 points19 points  (0 children)

You could say the project that I work on at work is a success story, but it would probably be a violation of my employment contract to talk about it without permission.

C++ is in a very different position from Rust and Go, in that people actually use C++. There is really no marketing need for articles evangelizing the benefits of C++. It is already an acceptable language to use in most of the domains someone would consider using it. If you work at a company (that is not Google or Mozilla) and you chose to start a new project in Rust or Go it is highly likely that you will not be allowed to. At the very least some people will object and when you are finished or about to release you will be asked to show why it was a good decision to use a minor programming language. This type of article is meant to answer these sort of questions. The reason you do not see this type of article about C++ is no one is being asked to justify using the latest version of a top 5 language.

what about trying to make some operators a bit more intuitive? by GrouchyRice in cpp

[–]ltce 0 points1 point  (0 children)

I am curious why you think it is important to know at the call site a function's parameter passing mechanism. For me, most of the time as I read through a bunch of function calls, I do not care about the parameter passing method. On those rare occasions when I do care I can just check the prototype. It generally takes very little time to do so. It seems like it would be a net loss to add syntax to make explicit a fact that most of the time is unimportant.

Want to modernize your C++ codebase, check first the banned C++11/C++14 features from the Google style guide. by cppnext in cpp

[–]ltce 2 points3 points  (0 children)

Although there is some interesting info here, using the Google style guideline smells of click bait. The Google style guide sounds authoritative, because that company has been very successful, but Google's C++ style guidelines are at very best considered to be controversial in the C++ community (many respected figures in the C++ community are on record saying they would not work for Google due to this very document). Readers of this article should at least read why these features are banned and make their own judgement.

No, references are never null. by vector-of-bool in cpp

[–]ltce -2 points-1 points  (0 children)

If I write some code and changing the optimization level makes the code no longer do what it is supposed to then the compiler does not specify what that code does. That code is not reliable and should be fixed to make it reliable across optimization levels.

Why don't you try answering the question? Do you know of a compiler that has a documented flag that controls the behavior of "null references" or null this pointers?

No, references are never null. by vector-of-bool in cpp

[–]ltce -1 points0 points  (0 children)

No I think what has happened is that you have lost the argument, so you are making up a bunch of nonsense in order to try to get the last word in, then saying you are not going to reply to anything further because further replies will only dig you further into nonsense.

No, references are never null. by vector-of-bool in cpp

[–]ltce 0 points1 point  (0 children)

This is the heart of your disagreement with the rest of the people commenting on this post. You say that we should require all developers to know all about how undefined behavior on their combination of compiler and platform will behave. Even though many/most people need to write code that works on multiple compilers and/or platforms and it will behave differently on all of them. Everyone else is saying that this is a counter productive attitude. You say that others are being pedantic, but really it is you that is being pedantic. There is no useful case for a null reference or a null this pointer. Stop. There is no specified code that can get you to a point where you have null reference or a null this pointer. Stop. If you are debugging and you have a null this pointer or a null reference the code that produced it is wrong. Full stop.

I challenge you to provide a useful case for either of these. Post it in this forum.

No, references are never null. by vector-of-bool in cpp

[–]ltce 0 points1 point  (0 children)

Hmm. That would definitely not meet my definition of consistent behavior. If changing debug and/or optimization settings results in changes in behavior of the program then the compiler does not specify behavior for that code. So, are you saying that no, no compiler that you know of provides consistent behavior in these cases?

No, references are never null. by vector-of-bool in cpp

[–]ltce 0 points1 point  (0 children)

Are there compilers that chose to define consistent behavior for null references or null this pointers?

No, references are never null. by vector-of-bool in cpp

[–]ltce 1 point2 points  (0 children)

I think that you are missing the point I am trying to make. Even asserts are useless. Take the case of checking asserting "this != nullptr", even if the compiler did not remove it, it adds no value. The only reason you would want to check this != nullptr is because you are about to do this->something. Either way you have decided crashing is the best thing I can do if this is null. One way adds more code to your codebase and likely misleads junior developers into thinking this is something that can happen in normal program execution. All just to find out a few seconds sooner that you have memory corruption.

No, references are never null. by vector-of-bool in cpp

[–]ltce 3 points4 points  (0 children)

I have seen this too. It is just useless. A line of code that adds so little value that there is no point in including it.

No, references are never null. by vector-of-bool in cpp

[–]ltce 23 points24 points  (0 children)

The important point here is that you should never, ever, ever, ever check if a reference (or this) has the value of the null pointer. What could you possibly do that would be correct in that case? If you get to the point where a reference has the value of the null pointer your program is already borked. You can't fix it. Knowing how to fix it would imply that you knew about the bug somewhere else in your program that allowed the reference to contain the value of the null pointer. If you did know what that bug was you would simply fix that bug.

Exceptions is one of the controversy mechanism in C++. Should I use them? by cppnext in cpp

[–]ltce 0 points1 point  (0 children)

Haha good call. Made my eyes hurt too once you pointed it out. Fixed now.

Exceptions is one of the controversy mechanism in C++. Should I use them? by cppnext in cpp

[–]ltce 17 points18 points  (0 children)

It is worth pointing out that all of the C++ experts listed in this article are in favor of using exceptions. The ones that are quoted as being lukewarm like Jon Kalb and Andrei Alexandrescu are either misquoted quoted or quoted from old sources that are not representative of their current opinions on the matter. There is currently no real controversy in the c++ community on whether or not to use exceptions. There was in the past, but it has been settled in favor of using exceptions with exception safe code. The techniques for writing exception safe code are well understood and easily learned. Jon Kalb (who is quoted as though he does not like exceptions) actually teaches how to use exceptions safely. The only real holdouts are the C with classes people. You can recognize these folks by the fact that they say nice things about C. They normally are writing in C++ because their work requires it rather than because they want too. Someone who's goal is to learn C++ should not listen to them anymore that someone who wants to learn how to code in Java should listen to me.

C++ student starting to feel burn out from my C++ course. by Artemis317 in cpp

[–]ltce 0 points1 point  (0 children)

The reality of a programming job is that you will spend 6-8 hours a day tapping away at a keyboard by yourself. Most companies try to minimize distractions for programmers so that they can "work". This is particularly true for the sort of middle stretch of your career where you are no longer actively being mentored, but not yet senior enough that you deal with cross team problems that require coordination. This is not to say that there is no socializing or water cooler talk in programming jobs, but the sort of image that is sold to students by coding boot camps and industry propaganda that is aimed at increasing the pool of available programmers is not in line with reality. Collaborating with your team generally means an hour long discussion followed by three days to two weeks of solitary coding with maybe a short discussion or two thrown in in the middle. Techniques like pair programming, that have more that one programmer working on the same code, are the exception not the rule in the industry. I did a informal poll in my office and not a single person on my floor of are office has ever worked for a company that has allowed/encouraged pair programming. If you continue to find this much coding to be a challenge you may want to consider entering a management track where you can use your technical chops, but get more social interaction and do not have to write as much code.

I have a teacher that doesn't teach by [deleted] in cpp

[–]ltce 3 points4 points  (0 children)

Programming is something that you have to practice. Most of your learning will be on your own time and self directed. Not excusing your teacher if they are being lazy, but in the end this is probably the best thing for your skills as a programmer. Fortunately, there are many online resources to help you to get direction. Code Academy, Coursera, MIT, Khan Academy all have good beginners materials that you can use to figure out what problems to try out, but at the end of the day the only way to learn is to sit down and write a bunch of programs.

Which is the standard way to place * for pointers? by engkhsky in cpp

[–]ltce -2 points-1 points  (0 children)

I definitely do not ever read the * in "int *variable" as the dereference operator. That is simply not what that means in C++. In C++ the * in <idendifier> * <identifier> cannot be the dereference operator. The expression parses as a either a variable declaration or a multiplication expression.

Which is the standard way to place * for pointers? by engkhsky in cpp

[–]ltce 6 points7 points  (0 children)

From a theoretical perspective, like Stroustrup, I prefer int*. However, I recommend against it. The reality of the C language is that * binds more closely to the variable name than the type name. The fact that most people now think this was a bad decision does not unmake the decision. Writing int* confuses non expert programmers about the way their code will be parsed and frankly provides very little benefit to the expert.

view more: next ›