|
OddObserver posted:A virtual superclass isn't the same thing as a superclass with virtual member functions. Or just read this. (With the assumption that this is considered a good source around here.)
|
# ? Dec 24, 2009 03:35 |
|
|
# ? May 18, 2024 08:58 |
|
UraniumAnchor posted:Or just read this. Well, it's in the OP, so...
|
# ? Dec 24, 2009 03:43 |
|
Avenging Dentist posted:Well, it's in the OP, so... Which I haven't had cause to read in months, but I suppose I should have checked.
|
# ? Dec 24, 2009 06:01 |
|
Clang can now compile LLVM! It's not self-hosting yet but it sounds like it's pretty close to happening.
|
# ? Dec 25, 2009 01:25 |
|
rjmccall posted:No. I mean, you're right, a non-leaking malloc implementation is forced to have *some* way of re-deriving the approximate size of an allocation, but there's no standard way to access it. It's definitely not necessarily stored at a constant offset relative to returned pointer; there are implementations that (e.g.) track arenas where all the allocations are the same size. The above summarizes everything interesting that was said when we went over this topic. One safe way to derive the size of the block of allocated memory from a malloc-allocated pointer is to use the malloc_usable_size(void* p) function. Most popular malloc libraries support it, and if yours doesn't it's easy to switch to one that does.
|
# ? Dec 25, 2009 17:31 |
|
What do people think about http://www.stepanovpapers.com/notes.pdf ? It's less mathy than most of his other stuff and it's kind of fun (and on a level, sad) to see the guy who did STL rail against the standards committee. On the other hand, for all his regrets, I wonder why he never made his own language or something.
|
# ? Dec 26, 2009 20:00 |
|
Skimming through it briefly, it looks like it has a lot of similarity to Elements of Programming. Which is to say, programmers (especially programmers who hate C++) should be required to read it.
|
# ? Dec 26, 2009 20:17 |
|
Avenging Dentist posted:Skimming through it briefly, it looks like it has a lot of similarity to Elements of Programming. Which is to say, programmers (especially programmers who hate C++) should be required to read it. Speaking as a programmer who hates C++ and is currently reading Elements of Programming, do you think we should read it because it will make us hate C++ less or because it will make us use C++ better in spite of hating it?
|
# ? Dec 26, 2009 20:56 |
|
GrumpyDoctor posted:Speaking as a programmer who hates C++ and is currently reading Elements of Programming, do you think we should read it because it will make us hate C++ less or because it will make us use C++ better in spite of hating it? Well, hopefully it will make you understand why a lot of "Serious Programmers" use C++ and why generic programming is so important that it's worth dealing with the cruft in C++. (This is coming from someone who's only actually read a chapter and a half of EoP, though I am traveling soon so that amount will increase.)
|
# ? Dec 26, 2009 21:44 |
|
Avenging Dentist posted:Well, hopefully it will make you understand why a lot of "Serious Programmers" use C++ and why generic programming is so important that it's worth dealing with the cruft in C++. (This is coming from someone who's only actually read a chapter and a half of EoP, though I am traveling soon so that amount will increase.) There's this kind of proud ignorance that a lot of programmers have with respect to advanced C++ and they think that all of the template nuances and metaprogramming should never be used simply because it looks complicated. Elements of Programming shows you how important the ideas of generic programming are and that C++ is one of the few languages out there that really lets you express these essential components that make up generic code. Everyone knows C++ is a mess, but it's also much more capable than other "high level" main-stream languages at expressing truly high level concepts. "Serious Programmers" use C++ because it is necessary for creating powerful and efficient generic code. I like how Alexandrescu put it in his talk. It's almost impossible to have conversations about the STL, GIL, or the Boost Graph Library, with Java programmers who have never worked with a language capable of generic programming. That's not meant as a put-down to Java programmers or to any other non-C++ programmers, they just don't get it because the languages they've worked with are incapable of expressing all that is necessary to make libraries such as those as powerful as they are. Talk about something as basic as a generic sort algorithm not directly attached to a specific container/collection and you often hit a road block. These are important ideas that transcend languages and yet many programmers have never been exposed to them because they are not taught and because the languages they use are unable to fully represent them.
|
# ? Dec 26, 2009 22:39 |
|
Quick question regarding classes.code:
code:
How can I allow a user to define the name of the class object? To clarify, this is simply a question of curiosity. I don't really have a need for this to work, I just want to know if it is possible, and how?
|
# ? Dec 26, 2009 23:08 |
|
You have the name of the object be a member of Vehicle and in your constructor or whatever you assign the string to that name member??
|
# ? Dec 26, 2009 23:22 |
|
Subway Ninja posted:Quick question regarding classes. You don't want to do what you're trying to do for a whole host of reasons, even in languages where it's possible without considerable fuckery A better way to solve the same problem is to create an associative container (std::map or std::unordered_map) with the value of the user input as the index for that particular Vehicle
|
# ? Dec 26, 2009 23:25 |
|
I'm fairly new to this so perhaps I'm not grasping this properly, or maybe I'm not communicating it well enough. For example (user input in bold): Code string str; cout << "Name your vehicle: " cin >> str; DOS Window Name your vehicle: Camero Code str.Wheels = 4; //str holds the value of 'Camero' cout << "Which vehicle do you want to inspect? " cin >> str; DOS Window Which vehicle do you want to inspect? Camero Code cout << "A " << str << "has " << str.wheels << "wheels."; DOS Window A Camero has 4 wheels. EDIT: Otto Skorzeny posted:You don't want to do what you're trying to do for a whole host of reasons, even in languages where it's possible without considerable fuckery Got this in just before my reply. Thanks for the input, I'll have to look up containers/maps and play around with those. Working my way through a tutorial and this question popped into my head. I tried to solve it on my own but couldn't think of a way it would work, nor did it seem impossible, so I figured I was missing something. Subway Ninja fucked around with this message at 23:39 on Dec 26, 2009 |
# ? Dec 26, 2009 23:36 |
|
What is a good smart pointer library or source code?
|
# ? Dec 27, 2009 03:13 |
|
Given that you didn't bother to qualify what kind of semantics you want, I'm going to have to say "the C++ standard library" (and/or TR1).
|
# ? Dec 27, 2009 03:21 |
|
I just want something that will keep track of how many pointers i have to something and delete if none are left.
|
# ? Dec 27, 2009 04:04 |
|
code:
|
# ? Dec 27, 2009 04:09 |
|
MagneticWombats posted:What do people think about http://www.stepanovpapers.com/notes.pdf ? It's less mathy than most of his other stuff and it's kind of fun (and on a level, sad) to see the guy who did STL rail against the standards committee. On the other hand, for all his regrets, I wonder why he never made his own language or something.
|
# ? Dec 27, 2009 08:04 |
|
Ignore me.
|
# ? Dec 27, 2009 11:06 |
|
Subway Ninja posted:Code code:
|
# ? Dec 27, 2009 11:41 |
|
If I have a union union thing{ float a; int b; }; and I have thing example; example.b = 5; example.a = example.b; Is this guaranteed to be safe? How does assignment work when its from one union member to another for the same union instance?
|
# ? Dec 27, 2009 14:40 |
|
tractor fanatic posted:Is this guaranteed to be safe? How does assignment work when its from one union member to another for the same union instance? For PODs like these, example.b will be read out from memory into a register, and then written to the memory location of example.a. So yeah, it's safe.
|
# ? Dec 27, 2009 14:45 |
|
Vinterstum posted:For PODs like these, example.b will be read out from memory into a register, and then written to the memory location of example.a. So yeah, it's safe. Thank you.
|
# ? Dec 27, 2009 14:49 |
|
To be totally formal, you are not allowed to do this with unions. In practice, this restriction is never enforced because there is no other legitimate way to do it.
|
# ? Dec 28, 2009 01:46 |
|
rjmccall posted:To be totally formal, you are not allowed to do this with unions. In practice, this restriction is never enforced because there is no other legitimate way to do it. example.b = 5; float const temp = example.b; example.a = temp;
|
# ? Dec 28, 2009 02:05 |
|
That Turkey Story posted:example.b = 5; Hah, yes, I did not read carefully enough. This is totally fine.
|
# ? Dec 28, 2009 05:28 |
|
rjmccall posted:To be totally formal, you are not allowed to do this with unions. Source? Can't remember reading that anywhere, and a click search through the standard doesn't mention anything about that either. I can't think of any reason why. Maybe for non-PODs, but even then things with non-trivial copy constructors and assignment operators aren't allowed in unions, so it should be safe then as well (or actually not relevant, since the types would need to be identical). Vinterstum fucked around with this message at 10:58 on Dec 28, 2009 |
# ? Dec 28, 2009 10:54 |
|
For the sake of argument say I'm using stdlib.h. I would rather avoid not including it and having to reimplement its functionality. If I want to redefine a function that's already defined in stdlib, what are my options? Say I want create my own function named div, even though div is already declared in stdlib. Using the #undef macro doesn't work. The errors generated are "conflicting types" and "previous declaration." The obvious workaround, "create a function with a different name and use that", is not acceptable in this case. If I do manage to override the naming convention, what are the effects on the upstream and downstream libraries? Presumably projects which rely on my project as a library will see my new implementation of div. What about other projects that I rely on in mine?
|
# ? Dec 28, 2009 18:19 |
|
functional posted:For the sake of argument say I'm using stdlib.h. I would rather avoid not including it and having to reimplement its functionality. code:
pre:[box] ~ > gcc hurr.c && ./a.out hurrrr [box] ~ >
|
# ? Dec 28, 2009 18:27 |
|
That's one of those things that you pretty much need to explain why you're trying to do it so you don't get dismissed out of hand as "that's something that just shouldn't be done". If you're trying to avoid a million search-and-replace operations, you could implement your alternative div with a different name and redirect references to it with a #define (and #undef at the end).
|
# ? Dec 28, 2009 18:27 |
|
ChiralCondensate posted:
This is a good technique, and it works for div. It doesn't seem to work for all functions. I think it's failing for library functions which are defined using macro abstractions. Are there any other techniques like this? Whether at the code or compiler level?
|
# ? Dec 28, 2009 18:57 |
|
It's probably a better idea to rename your own 'div' function and its uses rather than messing with the system ones. On ELF systems (e.g. Linux, FreeBSD, etc.), your implementation may end up overriding global 'div' symbol even when it's called from within the standard libraries internally, causing stuff to blow up in weird ways, unless you're ultra careful.
|
# ? Dec 28, 2009 19:05 |
|
functional posted:This is a good technique, and it works for div. It doesn't seem to work for all functions. I think it's failing for library functions which are defined using macro abstractions.
|
# ? Dec 28, 2009 19:22 |
|
Vinterstum posted:Source? Can't remember reading that anywhere, and a click search through the standard doesn't mention anything about that either. I misread your post as the similar, pervasive, but technically illegal example.b = 5; foo = example.a;. Your actual example is fine. There is a special caveat with unions in C++, which is that union members are allowed to have non-copy assignment operators, which can get you in trouble because they're typically not robust against self-assignment. This is a pretty marginal problem prior to C++0x, though, because you'd have to have a class with a non-copy assignment operator but *not* a destructor, constructor, or copy assignment operator.
|
# ? Dec 28, 2009 19:29 |
|
Is there a better way to deal with passing member functions than wrapping them in another static function? Kind of an ugly solution...
|
# ? Dec 29, 2009 06:20 |
|
slovach posted:Is there a better way to deal with passing member functions than wrapping them in another static function? Kind of an ugly solution... boost::bind and boost::function or their C++0x versions if you have a compiler that supports them.
|
# ? Dec 29, 2009 06:36 |
|
litghost posted:boost::bind and boost::function or their C++0x versions if you have a compiler that supports them. Does the latest visual studio have support? C++0x seems like it has so many nice things
|
# ? Dec 29, 2009 07:05 |
|
slovach posted:Does the latest visual studio have support? Luckily for you, std::bind and std::function are also available in TR1 (in the std::tr1 namespace, of course), which you can download for VS2008 from Microsoft (or use Boost's implementation thereof).
|
# ? Dec 29, 2009 07:38 |
|
|
# ? May 18, 2024 08:58 |
|
Member functions? Sounds like a job for std::tr1::mem_fn or std::mem_fun.
|
# ? Dec 29, 2009 14:49 |