Freedom is also allowing other to have their opinions, and limit the use of their work.
If somebody want's to limit the users of their work to abiding to Human Rights, the please let them (Although people who violate Human Right are not likely to thin twice about violating a Software licence).
I seriously doubt, that any Open Project would gain much popularity if it contains restrictive licences, which do not align with the OSS culture.
BTW: Remember, that Freedom is also a responsibility. For the "Free World" to work in a "fair" way, you need to express your opinions where it matters:
1. political.... VOTE!
2. economic.... choose who should have you efinincial backing
3. daily.... express your opinion, even though you may loose Karma points:)
DISCLAIMER: of course, some actions/views are so generally unacceptable that we (as country, culture or...) decide they are "illegal"...
what else could have been done with the same money and far superior management
Aaaah. the fabled efficiency of management.
Navigating the future is about as easy as trying to make a paper-hat cross the atlantic by mounting a sail and have a ten-man "blowing-crew" standing on the coast of France.
The more "evil" and vendor-locking Microsoft is, the greater the chance that people flee from M$.
Sure we'll have some rough time (2-5 years maybe), but I predic that:
Microsoft will squeuze their customers so hard they will kill them
and a company feeds on it's customers!
The real thing to worry about is, why our goverments (at least the Danish) spends billions on supporting Microsoft via free education in schools... The goverments are the key to bringing M$ down.
I thought the situation might be a little different when you:
1. don't sue to stop a single person for a single crime, but rather to scare other people from committing the same crime.
2. don't have a direct financial gain in settelling, but rather in a conviction.
It seems to me, that if APG was about to go around sending bill's to everyone that does p2p filesharing (as a legit activity), it would be rather nice for them to have at least one court ruling supporting their claims.
This is probably best achieved by selecting one case where the offence is rather obvious, and get that tried in court. A rather bad move (I would expect) was to start 10-50 cases, and only win 2, that doesn't look half as scary.
Also, there's really no financial gain in setteling with those 150 people, less that $200.000, that's probably less than the APG spends a year on saleries.
I would suspect that the reasoning behind the "bill's" is somewhere along:
1. We can't really smack down on every little fish
2. We want people to stop p2p'ing our customers copyrighted material (which is OK in my book)
3. We can select some big fish, and fine'em, but that has proven to be ineffective (this has been tried before in Denmark)
4. We had some nice media coverage when we raided a college last year, and had a file-server closed, that made our funding explode by 300%
5. Why don't we do something outrageous, and get some more media-coverage. And maybe this time we can show a financial result to our customers (last time was actually a financial disaster, but a media success), and we can say to our customers: we estimate that piracy has gone down $5 mill, because of the campign, so the $500.000 you spent on APG last year is well spent.
6. The really good bit: if nobody covers the lack of payment of the bill's in the press (which was what happened in the collage-raid), in time we may even make a living one day, just sending out bills, when people are convinced that they have to pay.
If you are not experiencing performance-constraints, why not use another language?
Personally, I would think that if rapid development and market response is very important, you should probably select an interpreted runtime-typed language... which gives you minimum hazzle when changing desgin, arkitecture and most importantly: implementaion.
One language that would spring to mind is python:)
Sell it, if anyone want's to buy it. It's probably not worth much.
Like thousands of others before you, you think you have discovered a way to extend onetime-padding, reusing the key-material in some intricate way.
Unfortunatly it has been proved, that for an algorithm to be unconditionally secure, the key needs to be as long as the plaintext (That is, the information theoretic measure on the key must be larger or equal to the measure on the plaintext).
Your "algorithm" is probably nothing more than a random-generator. Many people have tried to make cryptographically secure deterministic random generators and have usually failed. In 1998 it was constructively proved, that any cryptographicly secure random generator can be used to implement a provable universal hash-function: it's THAT hard.
Actually, the best known random-generators that are considered cryptographically safe are based on RSA and El-Gamal encryption schemas, where a small portion of the output of CBC feedback encryption is "leaked" as the random output. These generators are roughly "as good as the algorithm they are based on".
In recent years so-called "chaos-mathematics" has begun producing promising random-generators, but it's a very new field which has not seen much information-theory and cryptological analysis yet.
Researchers have discovered a method bringing inanimate objects to life, without requiering the traditional lightning. This amazing breakthrough renders many movies obsolete, and new makings of "Frankestein" as well as "Short Circuit" are already on Hollywood film-makers drawingboard.
The patented technology relies on a breakthrough method, known to experts as "programmer error" to produce "close to human bahaviour": not doing what your're told.
"The tecnology means that animating inanimate objects will be substantially cheaper in the future -- you will no longer have to chase thunderstorms in a firetruck with the ladder extended... a very costly affair", says the "Gaak Team" behind the discovery.
yack yack yack.... All kinds of rant about why 2.96 is good
I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96. The libstdc++v3 from GCC 3.x is (almost) standard compliant.
I agree with that, and the "typedef trick" is not true encapsulation. But if you "squint your eyes" it works, and I have a hard time respecting people who knowingly circumvent it. People who circumvent it out of ignorance will learn in time:).
I agree with your assesment that it's good that it will break at compile time. Compile time is the best time to find errors. =) More people should try to write code that will run correctly IFF it compiles correctly. I see far too many tricks that leave everything until runtime, lately.
Oh, what an interesting discussion:). In my thesis, i'm extending the type-system of a language to include what i call quality-types, which express some quality about a value.
The quality-type in not related to the normal-type of the value.
This can be used to capture predicates such as:
comes from user input (-> you have to check before you pass a string derived from it to system())
has security level X (-> you can issue guarantees about the leakage of information)
...
example:
lattice { elements = system_checked, system_unchecked; system_checked < system_unchecked; }
int system(<system_checked>const char *s); <system_checked>const char *check_for_bad_stuff(const char* s);
<sysmtem_unckeced>int getc();
int main(int argc, char *argv[]) { system(argv[0]);// error: arg 1 not system_checked char buf[10]; sprintf(buf, "%i", argc); system(buf);// error: arg1 not system_checked system(check_for_bad_stuff(buf));// OK }
But, ultimately, a better solution would be run-time analysis, invocable an any time, there are many things you would like to check that it's not possible to check in a static-typed language.
I'm flirting with adding code-anylysis and som type-check like features at "run-time" in a language like python. So your program would start by invoking the analysis, and then proceed. You could defer checking some parts of the program till later, skip the check for efficiency,... Well, better finish my thesis first:).
When code is generally readable (meaning, it reads just about the same, no matter what language it's written in), coders are more likely to understand it, and to make fewer mistakes. Perl and some stuff in STL are not generally readable.
I generally believe, that people should code in a language they are proficient with, or get proficient at the language they code in
That said, I don't deliberatly write code in complex ways, but if there's a mechanism that's "best" in my evaluation, I will use it, even if newbie's will find it hard to read. I prefer:
Every langauge has a "natural" way in which to program, and it should be used. I write in different styles in C++, JAVA, C, ML,... I'm don't think similarity in implementation is a goal, although language independence of design often is (because the customer can't decide which language they want implementation in).
And by the way, C++ now has Garbage Collection, thanks to std::auto_ptr - another reason to be distrustful of STL.;)
I'm not sure I understand... std::auto_ptr is nothing near GC... And it sucks too:
Try looking at http://www.boost.org/libs/smart_ptr/smart_ptr.htm, it works MUCH better.
Anyway, I may not agree with your opinions, but your thoughts are very well said - I commend you on your command of the language and the strength of your convictions. (Even though I hate what you're saying, I'd give you mod points, if I had them.
That's very noble of you, but you are not allowed to mod on a topic you post on anyway:)
Regarding conversion at least, there have been some interesting discussions lately on the boost list (in part in response to the requirements set forth by the meeting of c++ working group in Curacao).
Those boost guy's rock, the boost::function is GREAT. I'll need to read up on their comments.
You may also want to consider whether you really want to convert between a shared_ptr and a cyclic_ptr. They handle the memory differently and while a cyclic_ptr may decide to delete an object, a shared_ptr will not know it.
That's the problem! I have to specify if my method takes a cyclic or a shared (or auto or simple) pointer... and there's no (sane) way to convert.
Notice, that the MyStringVector cannot possibly specialize any of the JAVA collections, since the interface is (by design) stricter.
Typedefs don't encapsultate anything! I could take or leave the rest of your arguments, but this point is rediculous.
The typedef keyword defines a synonym for the specified type-declaration.
That's all it is, nothing more, nothing less - and a synonym doesn't encapsulate anything.
Of course typedef's ecapsulate (unless people actively circumvent it):
class Foo { private: typedef map<Bar,Baz> FooMap; FooMap m; public: typedef FooMap::const_iterator const_foo_iterator; const_foo_iterator begin() const; const_foo_iterator end() const; }
Now, Foo can change it's implementation of the FooMap without users of Foo having to rewrite code. If users write:
map<Bar,Baz>::const_iterator foo_it(foo.begin())
Then, of course, the encapsulation is broken, but luckily, this bad code will break (at compile-time) when Foo changes the FooMap implementation.
always use the C++ language to obtain best results
Maybe in a code-obfuscation contest! =)
I think, you would probably find yourself better at home in the JAVA world?
Let's all play nice, kids. There's no place for these kinds of insults in/. It's not like I'm Jon Katz, and I wrote an opinion piece about how the STL caused Columbine. =)
Jon Katz:).... If you don't like to use the features, why not choose another langauge without them? (And with the nice feature of Garbage Collection!)
Yes, C++ is hard to understand, and has lot's of "wierd-stuff" features, but they are all there for a reason, so I'm buggered if I gonna refrain from using them.
I think we agree more than I thoght at first. I may have misinterpreted your "Has-A" statement, thinking that you wanted to use composition whenever possible, even for usage -- as in your string example.
In C++, inheritance (unfortunatly) plays a may roles
sub-typing, or is-A (which many OO-fanatics dont' regard as seperate from specialization)
specialization, or extension
shared implemetation (private inheritance)
I understand (now), that you resist using specialization unless there really is a reason..., and I agree with that.
I am also under the impression that you argue against using the "shared implementation" idiom? This I cannot understand.
If you used the str* functions all over the place, instead of making a class that used them, you had a major rewrite to switch to the STL.
I understand the value of implentation (and data) by proxy, and sometimes does this. But std::string is a central part of C++, and the reason it's standard is, so that people can share the definition.
I would like to add, that I (like you) also get frustrated at the ineptitude of many people trying to do OOP. When i see:
class Pupils: public std::set<Pupil> { const School& school; ... };
My toes cruble:). Why pretend that Pupils are a set? Here I would use:
vector::erase doesn't take an integer index, it takes an iterator. Granted you can do math on the iterator, but it makes for long and ugly one-liners to have to refer to your container multiple times on one line. Same thing with vector::insert.
Why would you even use an integer offset into a vector?
for ( mylist::const_iterator it(l.begin()); it != l.end(); ++it ) { do_stuff_on(*it); } for ( mylist::size_type i = 0; it != l.size(); ++i ) { do_stuff_on(l[i]); }
If you really want to call vector::erase() just:
l.erase(l.begin()+i))
How hard is it?
I suppose I should have been more clear and indicated that the methods on the container switched paradigms in a way that I don't like, not the actual containers themselves.
The methods or containers do not change paradigm, you just think, that because some (rather old-fashioned and wierd) specialization (integer indexing on vectors) work for one method, it'll work for all the methods that usually take iterators.
The container index paradigm in the standard library is iterators -- everywhere!
vector::erase() CANNOT take an int, because that would make many call's to erase ambiguous.
My first foray into this was to try to erase the first character in a string. I sent 0 to string::erase
You even had bad expiriences with (a related) ambiguity.
but I tend to find that the most obvious way to use a function should be the way a function actually works, unless there's a good reason it shouldn't.
The way methods that manipulate containers work is using iterators, that IS the obvious way.
And like I said, unfortunately, compilers (both MSVC++6 and Intel 5.0?) aren't very good at protecting you from making mistakes - because 0 is both a pointer and an integer, for instance. *shrug*
Here you touch on one of the (i think) fundamental flaws in C++, auto-conversion! and the fact that no seperate notation for a multi-convertible pointer exist. Unfortunate but true.
Also, I hate that people will free-form type functors, in the middle of their code. People end up with multiple functors that all do the same thing.
I don't agree.
People who use functors usually come from functional programming, and this style is suitable for use for many "odd-jobs" where C++ is not flexible enough. You don't need, or even want to give a name to all functions. For example, predicates, for std::count_if.
The "method" paradigm is far better, that the algorithm and data are coupled. It makes it far easier to organize your code, far easier to make global changes and manage your code, and reduce bugs!
Named functions and Lambda's have each their use. Don't underestimate the power of the lambda:)
Other than something like sprintf - a major pain in the butt to get working in STL, in my opinion.
If you are using *printf*() functions in C++, you are WAY off track. The "..." arg-style is the single most horrible thing in C, and should never had existed. Use the overloaded operator
Another thing I dislike - many, many languages support OO methodoligy, which makes porting code from one language to another pretty easy. Templates are not easy to port to another language. And they really don't buy you that much, in your end-user code. They're great for quickly developing something, and potentially making it more portable, but if you encapsulate all of the functions (ie METHODS), you can always change your mind, and your client code becomes more portable, too. (As in, porting to another language, if you need to.)
Do you even know what a template is? It's a type-parameter, nothing more, nothing less... there's no "protability problems" in templates for the simple uses of templates as type parameters.
It's always easier to make a change in one place than in a thousand places. Encapsulation makes that possible - but unfortunately the only way to encapsulate something is to wrap it in another API.
That is incorrect. You may use typedefs.
But having everyone re-invent the way to do case-insensitive comparisons is insane. Those kinds of decisions should be encapsulated in one location. If you know a better way than writing an API wrapper, I'd love to hear about it.
Shared library of functions acting on class'es through their public API.
And I'm not saying you should make myVector, I'm talking more about things like myStringVector. Application data should not DEPEND on the STL for its interface. Just because the STL is a useful API, don't think it's the Holy Grail. Too many people just LOVE to code Is-A relationships, when a Has-A relationship is better in every measurable sense.
Composition (which you call Has-A) is more versatile than specialization (which you call Is-A), but there's no reason not to use the C++ language to obtain best results. Private inheritance provides encapsulation, efficiency and ease of implementation in many places where one class is implemented directly in terms of another.
struct myStringVector: private std::vector<std::string> { //^^^^^^^ private: typedef std::vector<std::string> implementation; using implementation::begin(); using implementation::end(); using...; }
I think, you would probably find yourself better at home in the JAVA world?
Now, I don't want to get off on a rant here, but in my personal opinion, the worst thing about STL is their string support. It's great, because it's standardized, but that's about the only thing going for it, from a programmer's perspective. (Yes, it's highly optimized, but the API isn't very rich. I like rich APIs!) In other words, build your own string class, and give it a Has-A relationship to the STL string.
I object.
Your own "myString" is not accepted as input by any other code. You will get problems with memory ownership. Other people must use hours to try to figure out exactly what myString is good for:). Proxy'ing usually leads to ownership problems in C++.
I dont't think that you really "get" the Standard Library, but you try to bend it into your "old" way of programming. One example:
Also, the methods are written along the lines of, "if it's not optimal, you have to write the code yourself." I'm sorry - that sucks. Sometimes I need to remove an element from a Vector. Maybe I should be using another Container. Or maybe the API should allow it, but make it clear in the documentation that it's not efficient. I vote for the latter.
Well, the C++ standard comitee voted otherwise:)
You can nicely expand API's in C++. just define functions outside class scope:
template<typename T, typename A> horribly_missing_method(std::vector<T,A>& ; myargs...){ // (above: not C++ "...", just more stuff:) // do the stuff (in terms of the public API) }
Of course vector should not have a "size_type get_index_for(const T& t)"
operation, if you need such an operation, you should probably use another data structure. But you can use the STL algorithms to easily write your get_index_for function.
Also, I hate that Containers change paradigms on you, some places you can use integer indecies, sometimes you have to use iterators - and in my opinion, the line isn't very clearly drawn.
All containers support the iterator paradigm.
Containers with linear ordering from 0-n and efficient indexing support integer indexing.
std::map support syntax reminding associative array's (operator[]) because a map is an assiciative array.
What's there to be in doubt about?
Of course, that's just my opinion, I could be wrong
OK. To explain the differences of "programming-styles", I often analogize to linear algebra, with programming-styles (imperative, OO, GP, functional,...) as vectors in the space of programming-styles. which makes OO and GP "perpendicular".
You might as well look at it as the OO and GP spaces of programs, which I would be inclined to say are orthogonal
in the space of programs...
...smart pointer implementation...
I'm aware of the boost libraries, and i especially like (and use) the boost::function stuff...
One problem with "smart pointers" is, that there's one for every library... and the complexity involved in getting pointers to members, pointers to member functions and that stuff working properly (I have done it, of course:)
The most obvious problem are:
performance. smart pointers MUST perform action on every copy of a reference, thus making garbage collection rather expensive... stop-and-copy only cost something when you GC, and the cost is linear in the used memory.
conversion. Converting between different smart-pointers is not possible, and to normal pointers mostly invalid
My shared_ptr<foo> cannot be used as a cyclic_ptr<foo, and the expenses of just having every pointer implemented as cyclic_ptr<> are often too big because of the above performance problem. This problem becomes insurmountable when using third-party libraries!
error messages. BOOST does a good job of error-reporting, but the error-messages that a smart-pointer can generate are inherently worse than the compiler error messages for pointer usage.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/, but I guess you were referring to something that is integrated into the language.
I tried out BoehmGC, and it work's OK quite a lot of the time, but it never worked as smooth as a OO-standard-language GC:)
I generally oppose extending a language with "new" features, unless they are accepted and proven in other langauges (don't think chiken and egg, this strategy will work:), but I think GC has proven it's worth...
- Never use vector! It's a horrible specialization and is not even a container. Very, very bad.
I object.
You don't need to let anybody know that you are using a vector, just use typedef to expose iterators.
A vector is good when
you have an idea about how many items will be inserted into a linear structure or
you require constant lookup, and are willing to sacrifice linear internal delete time (which is often the case when you'll delete all items at the same time)
unfortunatly: std::hash_map<size_t,T> is not an option yet:)
Yes, it's a specialization of list, but most datastructures are specializations which allow certain operations to be performed fast, at the expense of others.
Just use a typedef to hide that your actually using a vector
- Allocators are for the most part evil. Be very wary of them.
I would rather say: Ignore them -- don't think about them, unless you are in embedded systems.
If you use a Vector to hold 15 different things,
the compiler has to generate 15 different
version of the Vector class to compile your
project.
That's probably also required, since different code should execute when the template parameter changes, for instance the copy-constructors, assignments, comparison and such are different.
One candidate for code-sharing is "int size_t e() const", but many such candidates are so small inlining is shorter than funcall.
C++ has no requirement for seperated code-generation. It would be perfectly legal to compile template clas-code into shared functions for different parameters, where it is possible. That no compilers do it is an unfortunate fact:(
Slashdot Mirror
Freedom is also allowing other to have their opinions, and limit the use of their work.
.... VOTE!
.... choose who should have you efinincial backing
.... express your opinion, even though you may loose Karma points :)
...) decide they are "illegal"...
If somebody want's to limit the users of their work to abiding to Human Rights, the please let them (Although people who violate Human Right are not likely to thin twice about violating a Software licence).
I seriously doubt, that any Open Project would gain much popularity if it contains restrictive licences, which do not align with the OSS culture.
BTW: Remember, that Freedom is also a responsibility. For the "Free World" to work in a "fair" way, you need to express your opinions where it matters:
1. political
2. economic
3. daily
DISCLAIMER: of course, some actions/views are so generally unacceptable that we (as country, culture or
1. Call Bush, make him aware that national American interests are at risk (i.e. M$ will loose money)
:)
2. Ask Bush if he doesn't think the special-forces needs a little execise
3. Point out, that an excercise should produce benefit for american taxpayers
4. sit back and watch
what else could have been done with the same money and far superior management
Aaaah. the fabled efficiency of management.
Navigating the future is about as easy as trying to make a paper-hat cross the atlantic by mounting a sail and have a ten-man "blowing-crew" standing on the coast of France.
The more "evil" and vendor-locking Microsoft is, the greater the chance that people flee from M$.
Sure we'll have some rough time (2-5 years maybe), but I predic that:
Microsoft will squeuze their customers so hard they will kill them
and a company feeds on it's customers!
The real thing to worry about is, why our goverments (at least the Danish) spends billions on supporting Microsoft via free education in schools... The goverments are the key to bringing M$ down.
.... Check.
Less Security => More Convinience
..... I don't think so :)
I thought the situation might be a little different when you:
1. don't sue to stop a single person for a single crime, but rather to scare other people from committing the same crime.
2. don't have a direct financial gain in settelling, but rather in a conviction.
It seems to me, that if APG was about to go around sending bill's to everyone that does p2p filesharing (as a legit activity), it would be rather nice for them to have at least one court ruling supporting their claims.
This is probably best achieved by selecting one case where the offence is rather obvious, and get that tried in court. A rather bad move (I would expect) was to start 10-50 cases, and only win 2, that doesn't look half as scary.
Also, there's really no financial gain in setteling with those 150 people, less that $200.000, that's probably less than the APG spends a year on saleries.
I would suspect that the reasoning behind the "bill's" is somewhere along:
1. We can't really smack down on every little fish
2. We want people to stop p2p'ing our customers copyrighted material (which is OK in my book)
3. We can select some big fish, and fine'em, but that has proven to be ineffective (this has been tried before in Denmark)
4. We had some nice media coverage when we raided a college last year, and had a file-server closed, that made our funding explode by 300%
5. Why don't we do something outrageous, and get some more media-coverage. And maybe this time we can show a financial result to our customers (last time was actually a financial disaster, but a media success), and we can say to our customers: we estimate that piracy has gone down $5 mill, because of the campign, so the $500.000 you spent on APG last year is well spent.
6. The really good bit: if nobody covers the lack of payment of the bill's in the press (which was what happened in the collage-raid), in time we may even make a living one day, just sending out bills, when people are convinced that they have to pay.
who gets the money?
Lindegaard is the spokes-person for APG.
I think I'll demand payment too, it's not my material, I hold no copyright on it but I demand payment!
Who decided what price to set for the various downloaded artifacts?
APG, It seems like. It must be their idea of "full payment"
And, who is going to ensure that paying these folks will prevent future prosecution by the copyright holders?
A good question, but there's a 50% discount if you erase the files and pay now (what you paid for is then rather unclear :)
Seriously, I think that this is going to cool down again. I'm a dane, IANAL but I don't think the cases are going to hold in a danish court.
indicators of just how flimsy the cases are, can be that APG:
I wager they are just out to create
And maybe even a bit of pocket-money
Obviously, you would leave the numeric and "immersive graphics" in C++, and link the python code to it....
:)
Leaving you to do interesting stuff _with_ the C++ components, but without having to formulate everything in C++.
Just preempting the "you did not read the post"-posts
If you are not experiencing performance-constraints, why not use another language?
:)
Personally, I would think that if rapid development and market response is very important, you should probably select an interpreted runtime-typed language... which gives you minimum hazzle when changing desgin, arkitecture and most importantly: implementaion.
One language that would spring to mind is python
Sell it, if anyone want's to buy it. It's probably not worth much.
Like thousands of others before you, you think you have discovered a way to extend onetime-padding, reusing the key-material in some intricate way.
Unfortunatly it has been proved, that for an algorithm to be unconditionally secure, the key needs to be as long as the plaintext (That is, the information theoretic measure on the key must be larger or equal to the measure on the plaintext).
Your "algorithm" is probably nothing more than a random-generator. Many people have tried to make cryptographically secure deterministic random generators and have usually failed. In 1998 it was constructively proved, that any cryptographicly secure random generator can be used to implement a provable universal hash-function: it's THAT hard.
Actually, the best known random-generators that are considered cryptographically safe are based on RSA and El-Gamal encryption schemas, where a small portion of the output of CBC feedback encryption is "leaked" as the random output. These generators are roughly "as good as the algorithm they are based on".
In recent years so-called "chaos-mathematics" has begun producing promising random-generators, but it's a very new field which has not seen much information-theory and cryptological analysis yet.
--
Helge
That's not ignorance, that's sending a political signal with your spendings (as opposed to a technical).
Researchers have discovered a method bringing inanimate objects to life, without requiering the traditional lightning. This amazing breakthrough renders many movies obsolete, and new makings of "Frankestein" as well as "Short Circuit" are already on Hollywood film-makers drawingboard.
The patented technology relies on a breakthrough method, known to experts as "programmer error" to produce "close to human bahaviour": not doing what your're told.
"The tecnology means that animating inanimate objects will be substantially cheaper in the future -- you will no longer have to chase thunderstorms in a firetruck with the ladder extended... a very costly affair", says the "Gaak Team" behind the discovery.
I use GCC 3.0.4, and it's a lot more standard-compliant than 2.96, has better error messages, and seems just as stable as 2.96. The libstdc++v3 from GCC 3.x is (almost) standard compliant.
I'm sorry love, can't help with the dishes -- entered into a contract to watch the commercials...
I agree with that, and the "typedef trick" is not true encapsulation. But if you "squint your eyes" it works, and I have a hard time respecting people who knowingly circumvent it. People who circumvent it out of ignorance will learn in time :).
Oh, what an interesting discussion :). In my thesis, i'm extending the type-system of a language to include what i call quality-types, which express some quality about a value.
The quality-type in not related to the normal-type of the value.
This can be used to capture predicates such as:
- comes from user input (-> you have to check before you pass a string derived from it to system())
- has security level X (-> you can issue guarantees about the leakage of information)
- ...
example:But, ultimately, a better solution would be run-time analysis, invocable an any time, there are many things you would like to check that it's not possible to check in a static-typed language.
I'm flirting with adding code-anylysis and som type-check like features at "run-time" in a language like python. So your program would start by invoking the analysis, and then proceed. You could defer checking some parts of the program till later, skip the check for efficiency, ... Well, better finish my thesis first :).
I generally believe, that people should code in a language they are proficient with, or get proficient at the language they code in
That said, I don't deliberatly write code in complex ways, but if there's a mechanism that's "best" in my evaluation, I will use it, even if newbie's will find it hard to read. I prefer:
overEvery langauge has a "natural" way in which to program, and it should be used. I write in different styles in C++, JAVA, C, ML, ... I'm don't think similarity in implementation is a goal, although language independence of design often is (because the customer can't decide which language they want implementation in).
I'm not sure I understand... std::auto_ptr is nothing near GC... And it sucks too:
Try looking at http://www.boost.org/libs/smart_ptr/smart_ptr.htm, it works MUCH better.
That's very noble of you, but you are not allowed to mod on a topic you post on anyway :)
Those boost guy's rock, the boost::function is GREAT. I'll need to read up on their comments.
That's the problem! I have to specify if my method takes a cyclic or a shared (or auto or simple) pointer... and there's no (sane) way to convert.
Nice workaround, but no cigar... this prevents virtualization:
Now with shared or cyclic or whatever:
But the trick:doesn't work (of course). And what we REALLY don't want is:compile-time type-parameters and virtualization don't mix (very well).I don't think "language portability" stand out as a quality in a program, but:
In Pascal, Java and Python, there are no type parametrisation, so you would either
- use the langauge's standard data-structure resembling a vecor. i.e (in JAVA):You would have to cast the extracted values all the time, but that's what you loose from not having type-parameters.
- Write your own StringVector, (probably in terms of vector)
Of course typedef's ecapsulate (unless people actively circumvent it):Notice, that the MyStringVector cannot possibly specialize any of the JAVA collections, since the interface is (by design) stricter.
Now, Foo can change it's implementation of the FooMap without users of Foo having to rewrite code. If users write:
Then, of course, the encapsulation is broken, but luckily, this bad code will break (at compile-time) when Foo changes the FooMap implementation.Jon Katz :).... If you don't like to use the features, why not choose another langauge without them? (And with the nice feature of Garbage Collection!)
Yes, C++ is hard to understand, and has lot's of "wierd-stuff" features, but they are all there for a reason, so I'm buggered if I gonna refrain from using them.
I think we agree more than I thoght at first. I may have misinterpreted your "Has-A" statement, thinking that you wanted to use composition whenever possible, even for usage -- as in your string example.
In C++, inheritance (unfortunatly) plays a may roles
I understand (now), that you resist using specialization unless there really is a reason..., and I agree with that.
I am also under the impression that you argue against using the "shared implementation" idiom? This I cannot understand.
I understand the value of implentation (and data) by proxy, and sometimes does this. But std::string is a central part of C++, and the reason it's standard is, so that people can share the definition.
I would like to add, that I (like you) also get frustrated at the ineptitude of many people trying to do OOP. When i see:
My toes cruble :). Why pretend that Pupils are a set? Here I would use:
Or at least:
If you really want to call vector::erase() just:
How hard is it?
The methods or containers do not change paradigm, you just think, that because some (rather old-fashioned and wierd) specialization (integer indexing on vectors) work for one method, it'll work for all the methods that usually take iterators.
The container index paradigm in the standard library is iterators -- everywhere!
vector::erase() CANNOT take an int, because that would make many call's to erase ambiguous.
You even had bad expiriences with (a related) ambiguity.
The way methods that manipulate containers work is using iterators, that IS the obvious way.
Here you touch on one of the (i think) fundamental flaws in C++, auto-conversion! and the fact that no seperate notation for a multi-convertible pointer exist. Unfortunate but true.
I don't agree.
People who use functors usually come from functional programming, and this style is suitable for use for many "odd-jobs" where C++ is not flexible enough. You don't need, or even want to give a name to all functions. For example, predicates, for std::count_if.
Named functions and Lambda's have each their use. Don't underestimate the power of the lambdaIf you are using *printf*() functions in C++, you are WAY off track. The "..." arg-style is the single most horrible thing in C, and should never had existed. Use the overloaded operator Another thing I dislike - many, many languages support OO methodoligy, which makes porting code from one language to another pretty easy. Templates are not easy to port to another language. And they really don't buy you that much, in your end-user code. They're great for quickly developing something, and potentially making it more portable, but if you encapsulate all of the functions (ie METHODS), you can always change your mind, and your client code becomes more portable, too. (As in, porting to another language, if you need to.)
Do you even know what a template is? It's a type-parameter, nothing more, nothing less... there's no "protability problems" in templates for the simple uses of templates as type parameters.
That is incorrect. You may use typedefs.
Shared library of functions acting on class'es through their public API.
Composition (which you call Has-A) is more versatile than specialization (which you call Is-A), but there's no reason not to use the C++ language to obtain best results. Private inheritance provides encapsulation, efficiency and ease of implementation in many places where one class is implemented directly in terms of another.
I think, you would probably find yourself better at home in the JAVA world?
I object.
I dont't think that you really "get" the Standard Library, but you try to bend it into your "old" way of programming. One example:
Well, the C++ standard comitee voted otherwise :)
You can nicely expand API's in C++. just define functions outside class scope:
Of course vector should not have a "size_type get_index_for(const T& t)" operation, if you need such an operation, you should probably use another data structure. But you can use the STL algorithms to easily write your get_index_for function.
What's there to be in doubt about?
That is possible :)
OK. To explain the differences of "programming-styles", I often analogize to linear algebra, with programming-styles (imperative, OO, GP, functional, ...) as vectors in the space of programming-styles. which makes OO and GP "perpendicular".
You might as well look at it as the OO and GP spaces of programs, which I would be inclined to say are orthogonal in the space of programs...
I'm aware of the boost libraries, and i especially like (and use) the boost::function stuff...
One problem with "smart pointers" is, that there's one for every library... and the complexity involved in getting pointers to members, pointers to member functions and that stuff working properly (I have done it, of course :)
The most obvious problem are:
My shared_ptr<foo> cannot be used as a cyclic_ptr<foo, and the expenses of just having every pointer implemented as cyclic_ptr<> are often too big because of the above performance problem. This problem becomes insurmountable when using third-party libraries!
I tried out BoehmGC, and it work's OK quite a lot of the time, but it never worked as smooth as a OO-standard-language GC :)
I generally oppose extending a language with "new" features, unless they are accepted and proven in other langauges (don't think chiken and egg, this strategy will work :), but I think GC has proven it's worth...
I object.
Just use a typedef to hide that your actually using a vector
I would rather say: Ignore them -- don't think about them, unless you are in embedded systems.One candidate for code-sharing is "int size_t e() const", but many such candidates are so small inlining is shorter than funcall.
Example:
Here, it would be perfectly legal for all "Bar::bar(Timer& timer) const" to share the generated code, but such cases (with substantial code) are few.