Mustach posted:

roomforthetuna posted:

And the rebuttal to his premise that C++ shouldn't be used for any new projects is to make a similar set of complaints about whatever language he suggests should be used instead. If there was a language that wasn't full of stupid flaws nearly everyone would be using it.

The Cheshire Cat posted:

Another basic question: Is there a standard for what goes in a particular .cpp file, like with Java's "One class per .java file"? I'm assuming it's just "use whatever everyone else on the team is using", where in my case the team is just me so it's "use whatever you feel works best", but if there is some kind of rule it would make it easier for me to figure out when I need to make a new file or when I can just include something in an existing file.

The Cheshire Cat posted:

In C, if you want to pass by reference you would usually declare your function like void f(int *foo), and call the function like f(&someInt). Apparently in C++ though, you declare a function like void f(int &foo), and just call it like f(someInt)? Does this mean that in most cases I'll never actually need to use the * operator (aside from declaring a pointer variable)?

quote:

This is assuming that pointer arithmetic is beyond the scope of what I need to do. Additionally, if the thing being passed by reference is an object, would I treat it inside the function as a pointer (so using -> to access members) or just a basic variable (thus using . insetad). I'm fairly new to C++ coming from a lot of experience with Java and C, so some of the syntactical quirks are really throwing me off.

A MIRACLE posted:

Can someone who understands templates help me out? I'm working on an assignment that uses some of my professor's code, which is templated out. I'm trying to add a find function. Here is the code:

code:

template<typename Tkey, typename Twgt>
int cgraph<Tkey,Twgt>::find(string cname) {
    map<Tkey,int>::iterator it;
    size_t found;
    for (it=keymap.begin(); it!=keymap.end(); it++) {
        found = it->first.name.find(cname);
        if (found != string::npos) return it->second;
    }
    cout << "City containing " << cname << " not found!\n";
    exit(1);
}

Qwertycoatl posted:

C++ is dumb and doesn't know that "map<Tkey,int>::iterator" is the name of a type, rather than a member. If you change the second line to "typename map<Tkey,int>::iterator it;", it should work.

The Cheshire Cat posted:

Anyway, serious question: Since the topic of pointers has come up recently, I'm a bit confused about the different usage in C++ compared to C. In C, if you want to pass by reference you would usually declare your function like void f(int *foo), and call the function like f(&someInt). Apparently in C++ though, you declare a function like void f(int &foo), and just call it like f(someInt)?

HFX posted:

Anyone recommend a good C\C++ logging framework similar to Log4J? I really like the ability to create module loggers, rolling logs, runtime configuration if I don't disable at compile time, etc. A Googling seemed to show ones that are either lacking, or have no active development.

HFX posted:

Anyone recommend a good C\C++ logging framework similar to Log4J?

Harokey posted:

If you like Log4J why not use Log4cpp? http://log4cpp.sourceforge.net/

I haven't personally used it, but I've seen lots of other projects that use it.

Edit: of course, maybe this was one of the logging frameworks that did not have "active development"

Sagacity posted:

The only relatively full-featured one I could find was Boost.Log which isn't part of the Boost, but really wants to be.

That Turkey Story posted:

Cross-posting this from the boost mailing list because I think it's pretty cool. I realized a new way to use enable_if in C++0x that offers a superset of the functionality that the current uses provide. If you ever wanted to use enable_if with overloaded conversion operations, now you can:

BigRedDot posted:

It was accepted, wasn't it? It hasn't gone in a release yet, but it will after some of its hand-rolled features get ported to some newer boost libs.

BRAINS! posted:

I'm running this

...

but it's skipping right to the input for Author. Whats the deal with that?

ed: VVVVVV Thanks

Plorkyeran posted:

The line of code that's happening on isn't in the chunk you posted.

There isn't really a single agreed upon standard of when to use pointers and when to use references. My personal preference is to never use non-const references if I have a choice, as they make it much less obvious that a function mutates its arguments, but others like to use them whenever possible as it lets you encode in the typesystem that NULL isn't a valid value for that argument.

emonkey posted:

the whole references being unable to be NULL is bunk anyway. This will still give you a runtime crash:

int *value = 0;
int &ref = *value;
ref = 1;

Since it can happen it does happen, especially if you ever have to call a function that takes a reference when all you have is a pointer.

rjmccall posted:

Applying the dereference operator (*) to null is undefined behavior only if the subsequent lvalue is actually accessed, i.e. read, written from, or called (or bound to a reference, naturally).

Plorkyeran posted:

My personal preference is to never use non-const references if I have a choice, as they make it much less obvious that a function mutates its arguments, but others like to use them whenever possible as it lets you encode in the typesystem that NULL isn't a valid value for that argument.

shrughes posted:

Pointers already encode into the type system that NULL isn't a valid value for that argument (unless you explicitly document that the function accepts it).

rjmccall posted:

Binding a reference to null is undefined behavior. Applying the dereference operator (*) to null is undefined behavior only if the subsequent lvalue is actually accessed, i.e. read, written from, or called (or bound to a reference, naturally).

ctz posted:

This is absolutely wrong with respect to C.

ctz posted:

I'm not sure about the exact semantics of C++ -- which puts me on par with the WG.

wellwhoopdedooo posted:

I, too, like to make assumptions about what callers of my function will do, and enjoy the freedom to be wrong.

(p.s. in case it wasn't clear, no they loving don't)

(p.p.s. I mean jesus loving christ that is one of the most ignorant possible statements you could make concerning the C++ type system, and the explicit, exact opposite of what is actually true. If you had left out that the type system encodes this information your statement would have merely been stupid, if not stupid enough to comment on, but god drat it man I don't even ... this has got to be a troll, and I have been got. Good show.)

shrughes posted:

When you write a function that returns a pointer, it should never return null.

shrughes posted:

It's not a troll, it's a comment about how to read and write C++.

When you see a function that takes a pointer parameter and want to call it, the default assumption you should have is that the parameter cannot be null.

When you write a function that returns a pointer, it should never return null.

shrughes posted:

It's not a troll, it's a comment about how to read and write C++.

When you see a function that takes a pointer parameter and want to call it, the default assumption you should have is that the parameter cannot be null.

When you write a function that returns a pointer, it should never return null.

shrughes posted:

It's not a troll, it's a comment about how to read and write C++.

When you see a function that takes a pointer parameter and want to call it, the default assumption you should have is that the parameter cannot be null.

When you write a function that returns a pointer, it should never return null.

rjmccall posted:

I seem to remember this being somewhat clearer in an earlier draft, but now I can't find the wording, so maybe I dreamed it up.

Claeaus posted:

(BST_Threaded is my own class)
In my mind this will use the copy-constructor(that I have tested and know works), allocate memory for a new BST_Threaded and return it. But I just get an empty BST_Threaded.

I'm guessing it has something to do with how the memory is handled or something like that, so if someone could educate me on that it would be awesome!

That Turkey Story posted:

Why would you ever assume this. This is the opposite of good practice and also is not implied by the type system.