Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1412062 Posts in 69447 Topics- by 58483 Members - Latest Member: Exye

June 24, 2024, 04:54:31 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)C++ is frequently reviled both by those who never use it and by those who use it
Pages: 1 2 3 [4] 5 6 ... 8
Print
Author Topic: C++ is frequently reviled both by those who never use it and by those who use it  (Read 18877 times)
Movius
Guest
« Reply #60 on: October 18, 2009, 07:49:21 AM »

Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?

Note, these people do not count as 'employed in IT as programmers/software engineers/whatever': university students, open sauce lunix project co-ordinators/contributors and the like, those working at an educational institution, video game designers who once altered a lua script so that a traffic light in level 3 started as red instead of green.
Logged
increpare
Guest
« Reply #61 on: October 18, 2009, 08:14:32 AM »

Boris:  Hmm.  I'm out of my depth by this stage.  Regarding D, this thread seems to give an approach:

Quote
Like the C++ Blitz++ library, expression templates are used to convert
vector expressions into efficient element-wise operations. Unlike that
library, however, there is no reliance on the compiler's optimiser.
Instead, the expression template is manipulated as text, converted into
postfix, and then passed to a simple CTFE compile-time assembler, which
creates highly efficient asm code which is used as a mixin.

it's a very different approach to the C++ one.  Mm.

Quote
It's "abstract library" code so it rarely concern us who are user of this code.
The advanced material regularly bleeds out of these libraries in the form of error messages (and, unfortunately, there's no end to this situation in sight).

Quote
(some libs in boost are complex because they solve problems in complex domains)
Which libraries do you have in mind?  I regularly get tripped up on the lambda-related boost libraries.  Spirit I have a total love-hate relationship with.  I love it, but I hate it.  Compiler-generation is a complex domain, but spirit is, in my hands anyway, so utterly fragile.  Compare this to many other specialized parser generators, where I don't find myself tearing my hair out when I put a comma in the wrong place.
« Last Edit: October 18, 2009, 08:19:31 AM by increpare » Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #62 on: October 18, 2009, 08:14:51 AM »

Code:
Vector4 v3 = m*v1 + v2;
And not only will it correctly do vector maths, it'll build an expression tree, determine the best way to evaluate it (there are lots of matrix optimizations), and then inline all the code to do it as if it were a single function that you'd written ahead of time.

AFAIK, no other language can do that. Some languages may have operator overloading, but they don't have the template power to do that, nor implicit casting that makes the whole process opaque to the user.

Ada can do it.  Most of C++'s operator overloading concepts came from Ada.
Logged



What would John Carmack do?
increpare
Guest
« Reply #63 on: October 18, 2009, 08:25:37 AM »

Ada can do it.  Most of C++'s operator overloading concepts came from Ada.
Reading this right now. (edit: link fixed)
« Last Edit: October 18, 2009, 08:29:34 AM by increpare » Logged
Klaim
Level 10
*****



View Profile WWW
« Reply #64 on: October 18, 2009, 08:36:10 AM »

Quote
The advanced material regularly bleeds out of these libraries in the form of error messages (and, unfortunately, there's no end to this situation in sight).

Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that. (That's good to know that most of the compiler software developers are in the Commitee...)

Quote
Which libraries do you have in mind?  I regularly get tripped up on the lambda-related boost libraries.  Spirit I have a total love-hate relationship with.  I love it, but I hate it.  Compiler-generation is a complex domain, but spirit is, in my hands anyway, so utterly fragile.  Compare this to many other specialized parser generators, where I don't find myself tearing my hair out when I put a comma in the wrong place.

I was thinking about more domain specific stuff like Boost.Graph. It's easy to understand what is a graph but not to understand domain specific concepts that are more maths oriented that are required to understand how to use boost graph right. That's the same for some other libraries. Maybe Boost.Random too as it allows more specific random algorithms than the usual rand function.

Nothing really hard in the end, but it's logical that you have to understand the domain before understanding the tool that you'll use to solve a problem in this domain. Using Ogre without understanding the graphic pipeline is problematic.

Quote
Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?

I've worked as profesionnal programmer in several domains(commercial, stock management, games), languages (C++,python,lua,C#,java,add anything useful for the task here) and plaforms (embedded, phones, consoles) for 6 years now (argh already 6...). I've worked 2.5 years in a game company on NDS games and now I work on flash/flex/as3 based games on the client side and java/groovy on the server side.
I work at home on games since I was in school and started c++ since high school. Since then I use mostly use C++ and other langauges for tools and scripting for my home projects.

I don't know exactly how much my advice is useful. And my position is not "strong". In fact, if you have a "strong" position, most of the time you didn't even tried to see the two extremes of the same concept. It's better to learn following first an extreme way of doing things, then to extreme opposite. That gives you insights about what to do in the real world.
« Last Edit: October 18, 2009, 08:39:50 AM by Klaim » Logged

increpare
Guest
« Reply #65 on: October 18, 2009, 09:08:53 AM »

Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that.
It's probably many many years off now that concepts've been ditched from 0x.

(also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++).
Logged
Alex May
...is probably drunk right now.
Level 10
*


hen hao wan


View Profile WWW
« Reply #66 on: October 18, 2009, 09:29:05 AM »

Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?

Note, these people do not count as 'employed in IT as programmers/software engineers/whatever': university students, open sauce lunix project co-ordinators/contributors and the like, those working at an educational institution, video game designers who once altered a lua script so that a traffic light in level 3 started as red instead of green.

i
Logged

Klaim
Level 10
*****



View Profile WWW
« Reply #67 on: October 18, 2009, 09:32:35 AM »

Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that.
It's probably many many years off now that concepts've been ditched from 0x.

(also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++).

Yeah, I hope for some implementations to spawn in gcc and msvc to help getting it faster :/
Logged

increpare
Guest
« Reply #68 on: October 18, 2009, 09:37:43 AM »

Yeah, I hope for some implementations to spawn in gcc and msvc to help getting it faster :/
yessssssssss Smiley
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #69 on: October 18, 2009, 11:54:58 AM »

Right, that's one of the big problems the Commitee is working on, so at least they are working on solving that.
It's probably many many years off now that concepts've been ditched from 0x.

(also yeah that ada paper ends up with a system a lot more verbose than what would allow for simple expressions alla c++).

Yeah, it ain't pretty, but it can be done.

Considering that Ada has language level support for threading, things like matrix multiplication might perform better in parallel, something like this:

Code:
function "*" (M1, M2: Matrix) return Matrix is
    Result: Matrix(M1.Rows, M2.Columns);

    task type Multiply is
        entry Go(Row, Column: in Natural);
    end Multiply;

    task body Multiply is
    begin
        accept Go(Row, Column: in Natural) do
            -- Do the math, putting the results in Result.
        end Go;
    end Multiply;

    Sub_Tasks: array (1 .. Result.Rows, 1 .. Result.Columns) of Multiply;
begin
    -- Start all the sub-tasks.
    for X in Sub_Tasks'Range(1) loop
        for Y in Sub_Tasks'Range(2) loop
            Sub_Tasks(X, Y).Go(X, Y);
        end loop;
    end loop;

    return Result;
end "*";

Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++.  Alas, it will never be so.
Logged



What would John Carmack do?
bateleur
Level 10
*****



View Profile
« Reply #70 on: October 18, 2009, 01:08:15 PM »

Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++.  Alas, it will never be so.

Be careful what you wish for. Threads themselves are arguably a terrible, terrible idea. Parallelism is great, but threads may not be the best way to achieve it. (I say "may not" because I have no better proposal, not because threads are somehow acceptable.)

Programmers have been trying to find good ways to efficiently code parallel programs for decades. So far: very little progress.
Logged

Klaim
Level 10
*****



View Profile WWW
« Reply #71 on: October 18, 2009, 01:19:53 PM »

Well there seem to be some ideas like data driven tasks model that allow to easily organize all your code in parallel but the only limits are some libs you use that might become bottleneck if they dont provide a way to use your task scheduler. More about that in this discussion on the ogre forum.
Logged

Glaiel-Gamer
Guest
« Reply #72 on: October 18, 2009, 01:21:21 PM »

Programmers have been trying to find good ways to efficiently code parallel programs for decades. So far: very little progress.

While threads are cool and all, I always thought there was some overhead in setting up a thread (to the extent that doing one matrix multiplication over 3 threads would actually be a waste of time and resources).

I keep wondering myself if parallelism could be brought into compiler-level optimization. I.e, marking sections of code as independent of each other, then on the small scale executing blocks in parallel.

(gonna write in psuedo code syntax instead of compiled assembley)

Code:
int a=1, b=2, c=3, d=4, e=5;
a+=b*c;
c=a*b;
e=d*b;
e++;
d+=e;
a+=d;

the compiler could break it up into


Code:
1: int a=1;

2: int b=2;

3: int c=3;

4: int d=4;

5: int e=5;

//wait for 1, 2, 3
6:
a+=b*c;
c=a*b;

//wait for 4, 5
7:
e=d*b;
e++;
d+=e;

//wait for 6,7
8:
a+=d;

then, besides the waits, each block could be executed in parallel instead of each line waiting for the previous to finish


that's my idea on how parallelism should work. Threads on the high level, then the compiler doing this junk to our code on the low level
Logged
iggie
Level 1
*



View Profile WWW
« Reply #73 on: October 18, 2009, 02:03:38 PM »

Quote
Question. How many of you taking a "strong position" in here are employed in IT as programmers/software engineers/whatever?

Ouch, IT is a dirty word in my mind. I work as a software engineer in a tech + games company as a day job, our IT guy just dusts the server and replaces routers!

There must be a reason all console + the majority of PC gaming uses C++, it is fast and scales well to large teams of programmers. I have nothing against any other language for hobby, web, business or scientific purposes - indeed it is fun to learn several - but nothing beats C++ in the games industry.

Now on the other hand, it is a painful and frustrating language to learn, work with, and debug. It will eat up less able programmers and will punish smart coders endlessly. It is very hard to dip into as you need a lot of code just to start a tiny game - it is a fair commitment to get into, but the end results are well worth it... eventually.
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #74 on: October 18, 2009, 02:23:37 PM »

Glaiel-Gamer: Processors work like like that internally, except the parallism is optimistic, rather than blocking. It's why assembler optimization is now essentially impossible to do manually - you have to consider what instructions that processor might be doing at the same time, and ensure that you don't queue give it ones that cause it to give up on the parallel approach. I.e. a well placed NOP can make the program faster, as it means one instruction won't request a value before it's been computed.
Logged
mcc
Level 10
*****


glitch


View Profile WWW
« Reply #75 on: October 18, 2009, 06:35:59 PM »

Veering a little offtopic but... Glaiel, have you ever heard of Cilk? It is actually surprisingly similar to what you propose there. Like here is a Cilk program:

Code:
cilk int fib (int n)
{
    if (n < 2) return n;
    else
    {
       int x, y;
 
       x = spawn fib (n-1);
       y = spawn fib (n-2);
 
       sync;
 
       return (x+y);
    }
}

Every time you say "spawn", you could potentially be opening into a new thread while execution continues; when you say "sync" execution waits until all spawned work has finished. A "microscheduler" maintains threads of its own and assigns spawned work to threads in an optimal manner (or on a single processor system might just run everything serially). I don't believe it has the sort of notion where you can say something like "sync a" separately from "sync b", but I think you could actually emulate that by carefully putting the calculation of a and b in separate functions, then spawning each.

It all seems really natural and one neat thing about it is that since they define this by just adding a couple of extra syntactic ideas to C, if you #define "spawn" and "sync" as noops Cilk code magically transforms into C.Unfortunately I've never really given it a shot...

I actually learned about this from the ICFP (a Cilk team won one year), which actually Glaiel you especially might be interested in given your stated interest in Ocaml and such things. The early years of the ICFP especially were a great showcase for bizarro research languages.
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #76 on: October 18, 2009, 07:32:26 PM »

Language level threading supporting (instead of lame library based support) is something I'd really like to see in C++.  Alas, it will never be so.

Be careful what you wish for. Threads themselves are arguably a terrible, terrible idea. Parallelism is great, but threads may not be the best way to achieve it. (I say "may not" because I have no better proposal, not because threads are somehow acceptable.)

I probably shouldn't have said "threads."  What Ada tasks actually are is implementation defined.  GCC happens to use threads (as I believe most Ada compilers do), but they could just as easily be processes or some new exotic form of matter.
Logged



What would John Carmack do?
Glaiel-Gamer
Guest
« Reply #77 on: October 18, 2009, 08:10:04 PM »

I actually learned about this from the ICFP (a Cilk team won one year), which actually Glaiel you especially might be interested in given your stated interest in Ocaml and such things. The early years of the ICFP especially were a great showcase for bizarro research languages.

I don't even know what Ocaml is


But ya like, it'd be nicer if the compiler could do that kinda stuff for you
Logged
mcc
Level 10
*****


glitch


View Profile WWW
« Reply #78 on: October 18, 2009, 08:41:06 PM »

Quote from: Glaiel-Gamer link=topic=8634.msg274034#msg274034
I don't even know what Ocaml is
Yeah... I am stupid and briefly got you and increpare mixed up

...Increpare, you may find it interesting to check out the ICFP!
Logged

My projects:<br />Games: Jumpman Retro-futuristic platforming iJumpman iPhone version Drumcircle PC+smartphone music toy<br />More: RUN HELLO
increpare
Guest
« Reply #79 on: October 19, 2009, 12:59:55 AM »

will check it out Smiley

The problem with automatically parallelizing code is that
1: you have to be sure that the functions being parallelized won't interfere with eachother (in C++ this is hard to do, in other languages this is easier)
2: you have to figure out what's good to parallelize (this is a hard problem, and one haskell, say, leaves to the programmer)

Parallelizing annotations exist in grand central dispatch for Snow Leopard (and a couple of other concurrency libraries I think?), where they're apparently very fun to use.
Logged
Pages: 1 2 3 [4] 5 6 ... 8
Print
Jump to:  

Theme orange-lt created by panic