| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12
Comments:
<0> ludde, the next standard, which is imminent, has this
<1> ludde: C++ should have full type inference :-)
<0> it also has concept checkers, which are the #2 solution to mauke's problem
<2> what is concept checkers?
<0> mauke, just use 'auto' everywhere, and it will.
<1> AaronWL: bull****
<0> concept checkers check that a type adheres to a concept.
<0> concepts are like meta-types. they're the set of all types that meets some requirement, such as ***ignable.
<2> type cl***es
<0> real compiler-supported concept checkers catch errors before they blow up into crap, and print sensible errors.
<1> AaronWL: or do you think auto foo(a, b) { return a + b; } will work?
<0> hm, i suppose not. :)
<2> i want closures (bound member pointers)
<0> i was joking anyway :)
<0> ludde, you probably wouldn't be satisfied to know boost provides something for this.
<0> im not sure if its slated for standard inclusion or not.
<2> you mean the functor stuff?
<0> alexandrescu also talks about that sort of 'closure' in his book
<0> yeah
<2> I want a native one that compiles to efficient code
<0> hm, i am not really sure what the status of 'bind' etc is, but there are many hopes it will be efficient when standardized.
<0> my #1 wish, besides fixing all of the known c++ problems, is for non-****y lambda expressions
<1> that's impossible in C++
<0> if not language support (which is unlikely), languages changes to make boost.lambda more pallatable.
<1> you'd need garbage collection and call by reference
<0> mauke, only a relatively few, minor changes are needed to make lambda libraries easier to use.
<0> im not sure why you think it would need all of that. boost.lambda uses the ordinary stack-based allocation.
<0> the main pain comes from some operators being unavailible for use by lambda expressions, because they're arbitrarily prohibited from being used in some manner or another.
<1> lambda != closures
<0> i am talking about lambda expressions, as in, anonymous functions created in-line
<2> I also _hate_ that private members are exposed in the header file.
<1> AaronWL: yeah, and non-****y lambdas should have access to their lexical environment
<0> mauke, an example: (cout << _1)("hi\n");
<1> ... which vanishes when you leave that block
<0> which sounds like you're asking for closures too, but i have not found this to be necessary.
<0> or at least, i have not used lambdas in c++ enough to find a need for closures.
<1> then what's the point of lambda?
<1> you could just write an ordinary function
<0> basically, to write anonymous functions in-line.
<0> mainly for predicates
<1> predicates usually access their environment
<0> sort(begin, end, your_lambda_goes_here);
<0> mauke, yes, and they can access any variables that are in scope.
<0> int i = 42; (cout << _1 + i)(55);
<1> yeah, and then you leave that scope, your lambda refers to non-existent variables
<1> great
<2> i want functions inside other functions
<2> and the inner function should be able to access the outer function's variables
<3> haha
<3> what you need is java!
<0> mauke, this is a more general lifetime consideration that has nothing to do with lambda expressions, imo.
<1> it's needed to make closures really work
<0> there are some stack-based closure implementations for c++, but hardly anyone uses them except for specialized stuff.
<0> eg, boost.spirit uses a library impl of closures
<0> (unlimited lookahead recursive descent parser)
<1> oh, another problem: what's the type of (cout << _1 + i)?
<0> indeterminant, but usually not a problem, since its used as a predicate.
<0> for when it is, we have 'auto' which is coming RSN
<1> what if I want to store it in a container?
<1> or return it from a function?
<0> use boost::function
<0> eg, generalized functor. this is in boost now, or coming in the next standard.
<0> boost::function is needed for all sorts of stuff, in practice.. a major difficiency in the existing c++ stdlib
<1> .oO( function<auto> )
<0> (its a concrete cl*** that is internally polymorphic)
<0> hehe
<1> cout << _1 + 1 doesn't really have a type, actually
<4> ludde, there's a GCC extension for nested functions
<0> i dont think gcc's nested functions work in c++.
<4> Supported by Intel, Pathscale and a couple others ; all but Microsoft compilers
<4> No, but this is #c, right? :)
<0> /topic #c
<0> :P
<0> hehe
<4> Limbo? Gah! :p
<0> mauke, why do you say it doesnt have a type? in the existing lambda lib impls, it does...
<0> it generally looks something like lambda_expr<nonsense>
<1> conceptually, I mean
<0> hmm, conceptually, i'd say it has a function type.. or really, function concept.
<1> it would be something like function<ostream &(T)> where T supports operator+(T, int)
<0> yeah
<1> oh, and operator<<, of course
<0> well, only the result of operator+ needs to support operator<<
<1> you just can't express this in C++'s type system
<0> thats what all of the new 'concept' stuff is for.
<0> use templates, to allow arbitrary types, but then constrain it, with concept checkers.
<1> eww
<0> it works.
<0> nobody said it is perfect.
<0> go back to your sml or theoretically perfect language thats useless for actually doing anything if you want something else.
<1> haskell also works
<5> c++ is perfect
<0> well, use haskell then
<1> I do
<0> i hear a lot of good reviews of haskell. unfortunately, i havent had a whole lot of opportunities to use it for anything.
<0> eg, it's not like theres any great SDK's for anything id like to do written in haskell
<0> ive only ever used one haskell program.. it was a cache analysis program written by the bzip2 guy, and it wasn't that great.
<1> hmm, if C++ really is such a great language, you should be able to write a regex-based string generator in it :-)
<0> however, have you ever heard anyone use one of the new fad languages, and say 'oh yeah, i learned everything about it, and it ****s' . ?
<1> i.e. given a regex, generate all strings matched by it
<6> morning nerds
<0> hm, i don't really see why you couldn't... or are you asking for this at compile-time?
<1> no, a normal program
<4> The C/C++ preprocessor could be more powerful sometimes, but you can always procedurally generate code
<1> how long would it take you?
<0> well, i don't see why you couldn't, for those regexes that have such a finite set.
<7> AaronWL yes I have
<0> mauke, im not sure.
<0> ive never written a regex matcher before, much less a regex set generator.
<1> who said anything about finite sets?
<0> (but id imagine they'd be about the same amount of work)
<1> it should support stuff like a*b*
<0> for infinite set, the algorithm will never halt.
<0> but again, i see no particular restriction in c++.
<1> oh, you just give it a limit n
<2> i also want && and || to work like in other languages
<0> recursion would be the way to go here, and we'll hit a stack boundary sooner or later (but so will any other language)
<2> but i guess that could be hard without an explicit none value..
<0> mauke, i dont see why this is a difficult problem.
<0> i am sure you have some theoretically perfect language that will do this in five characters though.. :)
<1> then do it
<0> no thanks. i am not familiar with regex beyond the basics, anyhow. it would take significant work just to learn all of regex.
<1> no, it took me a almost a whole afternoon and ~400 lines
<0> hehe, lets break out one of those one-line lisp qsorts that is hugely slow, isn't actually a qsort, and its worthless for real use.
<1> you just need literals, (), |, and {m,n}
<0> mauke, and are you suggesting that it would be harder in c++ than something else?
<1> yes
<0> why?
<1> because C++ lacks closures
<2> mauke: just generate all strings and check if they match the regexp
<1> ludde: haha
<2> actually, that's probably how you would do it in haskell :)
<0> i dont really see why, but then i am not accustomed to using languages that have closures.
<0> just thinking about it though, it seems like a fairly simple recursive algorithm.
<1> would it ever generate "b" for a*b* ?
<8> AaronWL: Ask yourself this: why, over the past 10 years, has C++ been used less and less in many application domains?
<0> Teckla, i don't know. i find generalities very hard to work with.
<2> mauke: should it generate the strings in alphabetic, shortest first, order?
<8> AaronWL: Is it because people unfairly believe C++ is too complex?
<1> ludde: probably
<0> mauke, the limiting is the key here, i guess. i think this is easy enough to deal with.
<2> in that case you can't use recursion, imo.
<8> AaronWL: I think you DO know.
<0> Teckla, historical c++ (ARM) was not that complex.
<2> or.. you probably CAN, but not as obviously
<0> the only way i even tolerate complaints of 'c++ is complex' is if we are talking about modern, standard c++.
<0> ARM-era c++ does not fall into this catagory.
<2> what does ARM mean
<0> annotated reference manual
<0> its the equivilent of K&R for C++
<2> ok
Return to
#c
or
Go to some related
logs:
#sex
#politics
don't take the brown acid woodstock quote
#unixhelp
burn jello
#politics
#cph
flashvars .htmlText encode
#gamedev
cybertokyo.net
|
|