| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> Heheh
<1> maybe I'm speaking to the wrong person
<1> because there's nothing wrong with quotes, they're used to query names with special characters like spaces
<1> and this query is programmatically generated, with no bias
<2> SELECT * FROM [CppUsers] WHERE [Name] LIKE 'MrAshe' AND [Brain] IS NOT NULL
<2> 0 results
<3> ouch :o
<0> People who use spaces in table/column/db names deserve violent death
<1> I agree, but if you don't handle it, and a customer uses one, then it makes your software look very poor
<0> Customers often deserve violent death
<2> ah, it does work for sql server too
<1> aside all the critisism, are you actually going to help?
<2> i've never seen database objects delimited with quotes before
<0> Dunno, you seemed to say I know nothing while you don't know how to compare dates
<4> lots of tools generate SQL with quotes
<1> MrAshe: that made no sense, but whatever
<1> I don't claim to be an Oracle expert
<2> i've always seen it with brackets, though i don't use non-microsoft tools in that area, as we use SQL Server
<2> though, EMS's SQL Server tools also do it
<0> Try to_date on those strings
<5> NABBED THAT BUG! i ****ed up. it wasn't my compiler
<2> shocking
<1> MraAshe: thanks, that actually is helpful, and makes sense
<0> About 99.9999999% of the time, it's not your compiler, unless you use Turbo C++
<0> (or VC++ 6)
<2> effectively the same thing
<4> VC8 gets stuck/crashes too. not as much as 6 though
<0> I don't mind crashes
<0> I mind when it doesn't compile valid stuff
<2> i rarely see a cl 14 ICE
<4> I had this problem with intel's compiler yesterday
<0> Yeah in VC++ 6 you get ICE like 15 times/day
<5> what's ICE ?
<0> C1001
<2> internal compiler error
<5> oh
<2> bug in compiler
<5> yeah, i've had plenty of those
<4> kept giving me some crap about duplicate symbol in temp001.asm
<5> worst part is coding around the template limitations
<4> dextre : the worst part is coding around limitations with no apparent logic
<4> I had to break a line such as "foo(bar());" into two using an ***ignment into a temp var, and then it compiled well
<5> YEAH!
<5> that happened to me too
<5> it's got a mind of its own
<2> actually, the most cl ICE's i've seen are a result of PCHs
<5> PCH?
<2> turn off PCH, and problem goes away, while your build time goes up 20 minutes
<2> pre-compiled header files
<5> oh
<2> and the compiler devs always wanted full preprocessed output to repro the bug
<2> which is a real pain in the *** when you have a huge source tree
<5> vc6 ain't bad.. it still does most of what i want. it's just sortof.. handicapped
<2> that's because it's not a c++ compiler
<2> it's some pre-c++ like c++ language compiler
<4> it does compile "c with cl***es"
<0> And structs too!
<4> ("c with cl***es" is the working title of c++)
<4> was
<0> You mean in 1990?
<4> 1983, actually
<5> what features do u most eagerly want to see in c++ 0x?
<2> smart ptrs, personally
<5> aren't they slower?
<2> than?
<4> smart ptrs are always almost worth the extra time
<4> peterhu : than not having them, obviously
<5> i wonder if _m_ is here
<5> i had a question cowmoo told me i should ask _m_
<4> are they added as a language feature, or just part of the standard library ?
<4> boost::auto_ptr gets standardtized ?
<5> i think they'll prefer to add it to the standard lib
<2> std::auto_ptr already exists, but effectively boost::shared_ptr and friends get into std
<0> What question
<1> I hate the fact that there's free tools used with g++ for distributed compilations (like distcc and cachecc) yet Microsoft still has not offered this with their product
<5> ah. i was irked by the discovery that u can't have default template arguments for standalone functions, whereas it's possible for cl***es
<1> something I've been requesting for the longest time now
<2> we had an intern work on that
<2> didn't quite make it to being ready to get productized
<2> it's on the build team's radar though
<5> cowmoo said there was some historical reason for that limitation
<0> There's a historical reason for every limitation
<0> Laziness
<0> (that, or JBlitzen)
<4> "historical reason" basically means "because it turned out this way"
<5> but wouldn't it be more convenient to have default args for templated functions as well?
<4> what's the big deal ? it gets instanciated according to the parameter type anyway
<4> I really don't see your problem
<5> it's no biggie.. i was trying to write a templated typedef day..
<5> and i thought it'd be nice to just template the line of code, but turns out i had to house it in a struct
<5> nevermind. this sounds stupid
<4> was just about to go "huh"
<5> lol
<5> http://www.gotw.ca/gotw/079.htm
<5> that's what i meant
<5> but i know u can't use c++ this way
<4> yep, struct is the way to work around it
<5> so in this context, it's kinda useful to have a templatable typedef
<4> c++0x seems to have aliases instead
<5> what are those?
<4> http://www.artima.com/cppsource/cpp0x.html
<5> i always enjoy reading about 0x
<4> template<cl*** T> using Registry = std::map<std::string,T>;
<4> here's the solution to your question
<4> I don't like the syntax, but the feature is nice
<5> wow nice
<5> i wonder if 0x is going to allow default args for template functions
<6> dextre templatable typedefs are on the 0x list
<5> vaw: awesomeness! :)))
<4> vawjrwrk : isn't it the same as these aliases ?
<5> i'll be happy to dump vc6 for 0x anyday
<6> ???
<4> dextre : dump vc6 for anything else anyway
<5> hah hah
<6> exception yes
<6> dump vc6 for vc8
<5> i like how 0x does away with the annoying "for (std::vector<double>::iterator p = v.begin()......)" and introduces the "auto" keyword
<6> and do it now
<6> auto is in the language now
<4> auto
<6> it just doesn't do what you showed
<4> auto was always in the language, except it was useless
<5> ah
<6> I'd almost prefer that you be able to say for(v::iterator p =.......
<6> than have auto
<5> vaw: haha nice
<5> wonder why it isn't like that
<4> typeof(v)::iterator, maybe...
<6> yes that would be fine also
<4> the compiler *has* to know the type of every variable, so why not let the programmer access it ?
<0> variable::iterator would probably be so easy to implement
<2> as long as it's not "for each (int i in v)"
<2> otherwise, they might resolve my bug as a "already 0x implemented feature!"
<0> hehe
<5> maybe they had space concerns. so they didn't want to hinge an extra iterator appendage to the containers
<5> nevermind.. it's just a typedef
<2> i need to take a look, but didn't the generated code call postfix ++?
<2> someone should open that bug too
<5> peter: what's so bad about that syntax? "for each (int i in v)"
<2> nothing, i don't mind it, except it currently isn't standard c++ and cl 14 accepts it even with /Za (disable microsoft-specific extensions)
<5> it's like visual basic almost
<2> it's valid c++/cli for IEnumerable types
<2> or IList
<2> but standard c++ it is not
<5> ic
<2> so the compiler should not accept it
<4> in fact, in c++0x they could add it as well
<4> but it's just sugar coating
<5> did they make any improvements to template syntax?
<4> >> is now legal
<4> no need in stupid spaces
Return to
#c++
or
Go to some related
logs:
#MissKitten
#london
selectedIndexes + JS
#AllNiteCafe
#javascript
#mirc
php mysql stringtotime
createimagefromstring
#linux
#linuxhelp
|
|