Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (511)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4
  ignore  |  Print  
  The hidden cost of C++  (Read 14060 times)
0 Members and 1 Guest are viewing this topic.
Offline kaffiene
« Reply #60 - Posted 2012-09-26 23:24:16 »

Quote
... uses this notation for cross product: a X b, which is precisely what I referring to - that is that standard notation for the multiplication operation.
In arithmetic sure. 10×5.  Or sometime when you're abstractly talking about some (potentially unspecified) field, but then again it's almost as common to use a 'dot' as well.  But we're talking about a specific algebra:

Standard notation for vectors:  let small letters be scalars and capitals be vectors:

product of a vector with a scalar: sV  (no cross symbol)
cross product:  A×B
dot product: A.B
product:  AB -  Doesn't exist..it isn't representable in terms of vector


We must be talking across purposes.  All I have been claiming is that A x B is the standard notation for vector cross product - which you seem to have agreed with.  

I also claimed that A x B is usually "a * b" in programming languages and therefore "a * b" would be an obvious choice for overloading vector cross product (esp. since you can't overload the 'x' character)

I also claimed that the '*' multiplication operator when overloaded often inherits it's programming language level precedence.

I also claimed that programming level precedence doesn't always map correctly to various mathematical domains thereby creating a problem representing maths in code using operator overloading.

I don't know why you've kept going on about inner / outer products, scalar/Vector multiplication or Vector multiplication OF ANY KIND.  I'm not discussing any of those cases, I'm just discussing "A x B" with vectors, the cross product of A and B.

If you want to disagree with me, can you disagree with one of the points I actually made rather than making up straw men of your own?

regarding Mathematica: I asked you for a mathematical reference showing that A x B has a different precedence in the context of Vector maths than A + B, not a programming reference.  It was a simple enough request I believe.  All of your verbiage related to Mathematica is simply restating your intuitions - the very ones I asked for a reference for in the first place.
Offline kaffiene
« Reply #61 - Posted 2012-09-26 23:30:51 »

Funny thing about primitives: they're a compiler optimization, they need not be exposed at the language level.  Smalltalk has never really had them, and most of Java's JIT technology came from smalltalk derivatives (Self and Strongtalk).  Scala also doesn't have them, yet it also emits bytecode that uses primitives -- in fact, because of annotations like @specialized, it's able to do so in more places than Java.

Java did not start out with JIT at all, and therefore did not launch with many ambitions to advance the state of its compiler to leave out the primitive/object distinction or even blur it in any way.

Sure you can still hand-optimize quite a lot of code with primitives ... just like you can if you wrote everything in C.


This is the reason I said in a previous thread about Java that I'd have preferred that the language didn't have the primitive / type class split.  It seems unnecessary given a smart enough compiler.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #62 - Posted 2012-09-26 23:44:43 »

After more than a decade of work on the JIT, the (hotspot) compiler still isn't smart enough to remove the overhead of objects. Every time the hotspot engineers promise optimisations in this regard, it's like 'Java2D all over again': wildly varying performance, depending on a lot of unobvious factors. In realtime gaming (this is JGO after all) this is unacceptable.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #63 - Posted 2012-09-27 13:00:02 »

WRT: No primitive types.  I love smalltalk, but java having prims was the good choice IHMO.  The problem that then the best option for promoting object wrappers of prims was tagged unions.  Slows down performance and is an extra headache for the VM.  The other option of boxing combined with AOT sugar of treating prims as objects is likewise a big pain (this is actually what I expect that they mean by "no more prims" in JDK10).  However having said that, it seems like V8 does a pretty good job and it's based on the strongtalk low-level...so I might be full of poop.

Quote
All I have been claiming is that A x B is the standard notation for vector cross product - which you seem to have agreed with.
No question, here we're in agreement.

Quote
I also claimed that A x B is usually "a * b" in programming languages and therefore "a * b" would be an obvious choice for overloading vector cross product (esp. since you can't overload the 'x' character)
Here's where we start to disgree. I claim that in algebras the unique product 'ab' is represented in C-like programming languages as 'a*b' and that the cross product does not well agree with a unique product nor with any standard notion of properties one might expect from a product-like structure.  (NOTE that a unique product does not indicate that other "products" do not exist).  Of the various vector products the best one (in terms of structure/properties) is the Hadamard (component-wise) product which has little geometric meaning and is more useful if you're treating vectors and tuples as one and the same (a la shaders and various SIMD ops).  Now I'm sure that most people think that I'm a nut case, engaging in pure mathematical wankery or possibly both, however I don't not consider this to be the case. In terms of operator overloading, defining the cross product as "*" is pretty much an abitrary choice.  Why not the dot or Hadamard products?  These would be more logical as they are somewhat in agreement with multiplication by a scalar.  The real problem with using "*" as the cross product is that it leads to ambigous and therefore hard to read expressions, which is exactly contrary to the point of operator overloading in the first place. a(b×c) becomes: a*b*c = ..I'll pass.  By naming convention the previous could be slightly cleaned-up, but simply not enough to interest me.  I don't see any issue with this.  We use pow,floor,sqrt,etc mixed with operators for floating point and doing likewise over non-primitive types is more than reasonable.  As such I use cross(a,b) and dot(a,b) respectively...problem solved as far as I'm concerned.  None of this is intended to imply that anyone shouldn't use "*" as the cross product if that works for them (and potentially any "users"), because again, the point to get more correctly done in less time.

My "liking" of operator overloading is not a desire to have my code look like a LaTeX document.  There exist languages in which this is possible.  Operator overloading allows my high level language to NOT look assembly over a non-primitive types, therefore drastically increasing the read/write/maintainablity of my code...oh yeah, and I get things done faster.

Quote
I don't know why you've kept going on about inner / outer products, scalar/Vector multiplication or Vector multiplication OF ANY KIND.  I'm not discussing any of those cases, I'm just discussing "A x B" with vectors, the cross product of A and B.
This is all related to the choice of "*" as an operator for the cross product.  It's an arbitrary choice and not a logical one from a mathematical notation perspective.  Addionally meanful computations require mixing of cross, dot and scalar products, so any choice of operators need to be readable...otherwise we're simply using a language feature because it's there and that's naughty.

But really, talking about vectors in a discussion about operator overloading (when extended operators are not available) is a red herring as it's an odd duck. 

Quote
I also claimed that the '*' multiplication operator when overloaded often inherits it's programming language level precedence.

I also claimed that programming level precedence doesn't always map correctly to various mathematical domains thereby creating a problem representing maths in code using operator overloading.
I think that fixed priority is a good choice for general purpose languages.  Can you give any examples of fields which don't agree with the standard order of operation?  I seriously cannot think of any.

Quote
If you want to disagree with me, can you disagree with one of the points I actually made rather than making up straw men of your own?
I'm seriously attempting to address your points (in my brain dump kind-a way).  Am I missing any?

Quote
regarding Mathematica: I asked you for a mathematical reference showing that A x B has a different precedence in the context of Vector maths than A + B, not a programming reference.  It was a simple enough request I believe.
Yes indeed it's a simple enough request.  The thing is that I'm lazy and didn't feel like doing a web-search for something that I'm certain to be correct about.  Since you explicitly mentioned Wolfram in a previous post I made the assumption that you'd accept an output of Mathematica as a correct statement.  I didn't occur to me until later that vector identities implicitly contain the correct order of operation.

Quote
After more than a decade of work on the JIT, the (hotspot) compiler still isn't smart enough to remove the overhead of objects. Every time the hotspot engineers promise optimisations in this regard, it's like 'Java2D all over again': wildly varying performance, depending on a lot of unobvious factors. In realtime gaming (this is JGO after all) this is unacceptable.
Has anyone seen any interesting testing about how well the backend is at scalar replacement?  (This is on about page 20 for my "when I have spare time" list).
Offline kaffiene
« Reply #64 - Posted 2012-09-27 22:50:15 »

Aaahh!  Ok, thanks for the clarification - I get where we diverge now - mainly around the use of the '*' character.  I guess the larger issue here is that we don't have a number of characters available to use for overloading which means that we're always compromising somewhat.  It's this element of compromise which always disappoints me with operator overloading.


Offline Roquen
« Reply #65 - Posted 2012-09-28 12:02:49 »

Indeed.  More operators makes overloading much more generally useful.  And in the context of Java (and JVM based language) which already support UNICODE it would be perfectly reasonable to support the wealth of UNICODE defined operators.  This brings up a tooling issue which, again, in my opinion is a minor issue.  As mentioned previously, I think that overloaded operators should be rendered differently than their built-in equivalent as then it's immediately obvious that it's overloaded.  Likewise an IDE could have a default 'font' for operators which it could use if the current font doesn't contain the character in question.  That leaves the outstanding issue of input which I'll defer to UI specialists Smiley

But extended operators aside, just the default set of operators would cover the major of peoples needs.  Examples:

  • R representations all work as well as built-in floating point (multiprecision flavors, double-double & double-quad, non-standard fixed width floats, IEEE: (binary16, binary128, decimal32, decimal64, decimal128), rational (Q), fixed-point
  • Z variants: same thing.
  • Ranges/Intervals over an ordered type:  error bound analysis, range analysis
  • Dual Numbers over an ordered type:  automatic differentiation
  • C over Reals:  Yeah, you have inner & outer products, conjugate and some other operators..but again, not everything has be an overloaded operator (before anyone asks: 2D geom/physics, electrical engineering, physics...including light modeling.

These barely scratch the surface..and beyond that is the "biggy": linear algebra (over many types).  Again LA has a ton of operators, but the basics cover a great deal of territory.  Practical LA need very many implementations of the same things for different specialized use-cases.  And yeah, I've seen many bloody awful LA libraries which use overloaded operators.  That's not a problem.  The issue is the ability to create a reasonably well written library which isn't awful.
Offline Best Username Ever

Junior Duke





« Reply #66 - Posted 2012-10-06 00:22:51 »

@Roquen

I was confused over who you were addressing. There were multiple disconnected conversations going on. I thought you were addressing one of my posts about retrofitting Objects to behave like numerical types. (I said something I thought that you thought I meant using C++ as a model for Java...) How much of this post did you see and to what extent were you addressing that post vs the other people? I'll respond to parts of your response to try to make some sense of this.

Quote
Technically, a programming language does not have to do much under the hood at all.
I depends on what kind of language you're talking about.  The higher level you get...more and more is happening "under the hood".  That's the nature of the game.

You wrote "Most of the stuff about operator overloading must do this and that under the hood is compete bunk." In general, you absolutely should care what happens under the hood. Operator overloading included. I think you absolutely agree that language features ought to have smart implementations. Without that, the entire language suffers in terms of utility more so than if the feature did not exist at all. I'm against adding (arithmetic) operator overloading without making other updates to the language first (structs/improved generics), but only because no one put forth a proposal that does not involve plain Objects.

Quote
Sure, as long as performance and spending twice the required memory is of no concern.

Right. The same can be said for operator overloading. If speed and memory are concerns (and consistency with primitive types, simplicity, and predictability, too) then like it or not a good implementation of operator overloading in Java would probably look more like C++ under the hood than a Java Object. Not because someone used C++ as a model, but simply because C++ coincidentally implements operator overloading on by-value types (if only because all C++ types behave that way). There are merits to that method over more complicated methods, even if C++ did it first.

Quote
Personally I could care less if Java ever gets operator overloading, but I'm able to look beyond my own bellybutton to the needs of other programmers.  I can implement operators exactly as I would like them to work.

I disagree. Under the hypothetical situation that one person here had a magic wand to make a change to the language, I would be worried if Java got a bad implementation of operator overloading. Most people can't see for themselves that a change would have a snowball effect to the rest of the language. A struct-like type is probably the only practical way that would be most universally useful. I disagree with sentiments like "Just use annotations!" or "Just put add, subtract, multiply, divide in an interface!" or "Well I would make a really really really really smart compiler." That's the same crime, but has worse consequences than requiring programmers work within an existing framework until the design can be worked out.


As for the rest of your post, I'm not sure what you're arguing. Are you saying you would use a struct-like data type? A contract system? JIT Compiler magic? Syntax sugar like auto-boxing? Or what? (BTW, where did the JDK 10 thing come from? Is it a rumor or a roadmap I don't know about?)
Offline Roquen
« Reply #67 - Posted 2012-10-10 11:58:49 »


First off:
1) If you think that operations over non-primitive types looking like macro-assembly is not a problem...stop reading, you're wasting your time.
2) I strongly suspect that most people whom cry: "OMG! The calling overhead! OMG! The object creation overhead!!" were to read some other post on a topic which included optimizations which yields greater cycle reductions then these introduce would cry: "OMG! Premature optimization!"  If you feel you might fit in this category...stop reading, you're wasting your time.

Quote
There were multiple disconnected conversations going on. I thought you were addressing one of my posts about retrofitting Objects to behave like numerical types. (I said something I thought that you thought I meant using C++ as a model for Java...)
Indeed.  On the whole I'm only talking about operator overloading in an imperative language.  I see no strong reason to retrofit anything.

Quote
How much of this post did you see and to what extent were you addressing that post vs the other people?
Saw all of it..but, forget C++..like the creators of Java did.  There's nothing to learn about high-level language design other than counter-examples.  (And again: C++ is a very useful language. It's feature set is more than reasonable...it's problems are design related, or rather the lack thereof.  Oh and structural.  Oh and I hate multiple inheritance of state) Are there any specific issues you'd like me to comment on from that post?

Quote
You wrote "Most of the stuff about operator overloading must do this and that under the hood is compete bunk." In general, you absolutely should care what happens under the hood.
Agreed.  That wasn't my point.  Operator overload doesn't not require naive direct translation of the expression tree into a method sequence. Also since the exact sequence is not mandated by the programmer (unlike method calls) the compiler is given more flexibility in reordering.  Nor does it require one-to-one translation of operator to method.  Nor is where data is stored in the sub-expression mandated, yet again giving the compiler more wiggle room.  If you allow for rewrite rules (which isn't operator specific) then more advanced transformations are allowed, likewise for contracts, etc. etc.  Someone asked a question like: how many object does this long expression require?  In every DSL I've thrown together, the answer (assuming type is backed by an object) would have been:  either zero or one...it depends on the call-site. In general you can run a trivial live variable analysis pass which (the vast majority of the time) will tell it the exact number of temporary data chunks required. This is just one example of something the programmer must currently manually perform that and will often get "wrong" (as in non-minimal) and the compiler can easily (most of the time) get it exactly right.  But we could babble forever about compiler techniques and bore everyone to tears.  Also I don't really feel like it.  All of this ties back to my comment about assembly programmers.  Really you want to get things done as quickly as possible and hopefully your chosen language is helping you with that.  This free up time spent better somewhere else.  If anyone really want to micro-manage their codebase, then please..write in C.  It's a nice clean language designed for that kind of thing.

Quote
I'm against adding (arithmetic) operator overloading without making other updates to the language first (structs/improved generics), but only because no one put forth a proposal that does not involve plain Objects.
Again I don't care about overloaded operators in Java.  I can solve that problem myself.  Conversely structs is a huge deal to me...esp combined with concrete arrays of structs.  This is a problem I cannot solve for myself.  BTW: Structs were mentioned recently on the dev mailing list.  There seems to be no plan other than "gosh, we should do this.".  But there's no real problem with objects if that doesn't happen.  The only real gotcha exists for both structs & object: aliasing.

Quote
If speed and memory are concerns (and consistency with primitive types, simplicity, and predictability, too) then like it or not a good implementation of operator overloading in Java would probably look more like C++ under the hood than a Java Object. Not because someone used C++ as a model, but simply because C++ coincidentally implements operator overloading on by-value types (if only because all C++ types behave that way). There are merits to that method over more complicated methods, even if C++ did it first.
Forget everything about C++.  Think functional which generates imperative.

Quote
Quote
Personally I could care less if Java ever gets operator overloading, but I'm able to look beyond my own bellybutton to the needs of other programmers.  I can implement operators exactly as I would like them to work.

I disagree. Under the hypothetical situation that one person here had a magic wand to make a change to the language, I would be worried if Java got a bad implementation of operator overloading. Most people can't see for themselves that a change would have a snowball effect to the rest of the language.
Having written many DSLs I'm well aware how insanely difficult it is to design languages. So we're in agreement here. Good design is uber important.  In the context of Java there's no concern..all features are painfully over-thought.  The up side is it's a nice clean language.  But really there's little concern here (other than potentially adding more operators, which IHMO would be a good thing). No syntax pollution..and the "real-estate" (if you will) remains the same.

Quote
A struct-like type is probably the only practical way that would be most universally useful. I disagree with sentiments like "Just use annotations!" or "Just put add, subtract, multiply, divide in an interface!" or "Well I would make a really really really really smart compiler." That's the same crime, but has worse consequences than requiring programmers work within an existing framework until the design can be worked out.
I disagree.  There's no real additional problem with objects.  Also note that struct only tosses out quite a bit of things, notably many LA formulations.  Sure VM aware structs/value-types are slightly easier, but not really by much. Give me structs/value-types/tuples and support-em all!   Interfaces is in IHMO a very silly idea. "really xN time smart compiler" isn't needed..the analysis/transforms are easy. Annotations are the way to go. Meta-data is awesome.  Look at the LLVM mailing-list archive and you'll see tons of discussion about meta-data, because it's awesome.  One of the biggest problems is providing compilers with too little information.  I'm sure that annotations in Java seem like a PITA and/or bordering on useless to most java programmers but because of how the're used.  The java "system" doesn't really use annotations in any meaningful way.  And that's too bad.  Oh yeah, and contracts are awesome..because they're meta-data..which is awesome..which provides more info to the system...which is double awesome!

Quote
As for the rest of your post, I'm not sure what you're arguing. Are you saying you would use a struct-like data type? A contract system? JIT Compiler magic? Syntax sugar like auto-boxing? Or what?
I'm not arguing for anything specific.  I'm arguing that operator overloading is much more than minor sugar.  Without operators over non-prim types you're stuck programming in a macro assembler which blows chunks.  I'm also attempting to point out that what most people think-of as operator overloading is far from the only implementation possible.

Quote
(BTW, where did the JDK 10 thing come from? Is it a rumor or a roadmap I don't know about?)
This presentation.  Which is basically: Hey, this is some stuff that we're thinking about...well at least for the future stuff.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #68 - Posted 2012-10-28 09:15:17 »

It makes no sense to add operator overloading to existing classes like Integer. The language would gain nothing by it.
What are Operator Overloads even used for?  Huh

Smiley
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #69 - Posted 2012-10-28 10:41:45 »

They are critically important so that everyone can use their own randomly chosen set of ascii symbols to write their own mathematical vector library. Some intrepid programmers also like to overload the new and delete operators to make up for C++ shortcomings in the garbage collection department.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #70 - Posted 2012-10-28 13:17:40 »

Indeed.  The wealth of Java mathematics libraries speaks for itself (I'll leave off qualifiers like full-featured, useful, high-performance and over non-primitive types off...no reason to be TOO demanding).

I always overload new/delete and it has nothing to do with GC....I promise!
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #71 - Posted 2012-10-30 09:54:52 »

They are critically important so that everyone can use their own randomly chosen set of ascii symbols to write their own mathematical vector library. Some intrepid programmers also like to overload the new and delete operators to make up for C++ shortcomings in the garbage collection department.

Cas Smiley
Why is that helpful? Huh

Smiley
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #72 - Posted 2012-10-30 10:04:37 »

So are Dinosaurs, and they are still cool.
How did you manage to turn C++ into dinosaurs? (Not that they're not cool Grin)

Smiley
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #73 - Posted 2012-10-30 10:08:04 »

Tell here what are the worst things about C and C++ (In your opinion Grin)
I'm trying to tell everyone that C++ is BAD!!!!!!!!!!!!!!!
EDIT: I wasn't thinking to clearly. I just want your opinions.  Grin Sorry  Lips Sealed

Smiley
Offline Grunnt

JGO Wizard


Medals: 84
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #74 - Posted 2012-10-30 10:39:41 »

It comes after the A and B. Nuff said.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #75 - Posted 2012-10-30 11:08:57 »

Merged Roll Eyes

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gimbal

JGO Knight


Medals: 25



« Reply #76 - Posted 2012-10-30 13:26:30 »

I'm trying to tell everyone that C++ is BAD!!!!!!!!!!!!!!!  Cool Cool Cool Cool Cool Cool Cool Cool

But its not, you can still do great stuff with it. Its the developers that abuse it who suck.
Offline nsigma
« Reply #77 - Posted 2012-10-30 13:31:37 »

I'm trying to tell everyone that C++ is BAD!!!!!!!!!!!!!!!  Cool Cool Cool Cool Cool Cool Cool Cool
But its not, you can still do great stuff with it.

Like HotSpot!  Wink  I guess @masteryoom better steer clear of Java too.  Yawn

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline Roquen
« Reply #78 - Posted 2012-10-30 14:01:23 »

The language that a VM is written in has no really bearing on language(s) which run on it.

Talking about what's "bad" about C & C++ is like talking about what's bad about Java and Objective-C (or Self, strongtalk, smalltalk, forth)

Quote
Why is that helpful? Huh
If you're asking about new/delete..then the compiler provided manager is a single heap (thread-safe if multi-threaded app).  On the whole that doesn't match allocations in the real world.  But it's fine if you don't care about performance.
Offline gouessej
« Reply #79 - Posted 2012-10-30 14:15:40 »

In C++, this is not valid:
1  
vector<vector<vector<double>>> myVec;


This is valid  Huh:
1  
vector<vector<vector<double> > > myVec;

Offline Varkas
« Reply #80 - Posted 2012-10-30 14:47:14 »

The hidden cost are your headaches if you get C++ code from someone who uses a different set of C++ features to achieve some effect than you use to use. C++ has so many ways to do something, and different people will use different approaches. To read, understand and extend foreign C++ code you really must have coverage all of C++ features Stare

I like Java for the fact that it is leaner and simpler than C++, syntax-wise.

Templates and overloaded operators are perfect tools to code pitfalls for other programmers. You never will know if an operator symbol is overloaded for the types left and right, or if it really means what it seems to mean.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #81 - Posted 2012-10-30 15:24:32 »

In C++, this is not valid:
1  
vector<vector<vector<double>>> myVec;


This is valid  Huh:
1  
vector<vector<vector<double> > > myVec;

Broken compiler?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #82 - Posted 2012-10-30 15:39:36 »

In C++, this is not valid:
1  
vector<vector<vector<double>>> myVec;


This is valid  Huh:
1  
vector<vector<vector<double> > > myVec;

Broken compiler?

Cas Smiley

Broken spec. It's ambiguous in current C++ whether it should be parsed as multiple nested <> or an insertion operator >>

They've fixed it in 0x I believe.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline gene9

Senior Duke


Medals: 10



« Reply #83 - Posted 2012-10-30 16:35:33 »

What I don't like about C++

- string doesn't have standard upper/lower case functions? I remember I had to port Microsoft C++ code to UNIX, and a simple upper case (with full internationalization) required completely different implementations on different compilers and OSs.
- string isn't immutable! Why on earth would they have a mutable non-thread safe string?!?
- Collections library is overly complex, and lacking in features. No persistent immutable?
- Basic multi-threading + networking aren't in standard library or language. Usually involves platform specific tools.
- No outer variable capture for inner functions. Even Java has allowed final outer variable capture since 1.1 I believe.
- Extremely confusing syntax for lambdas and first order functions.
- Macro system.
- Most production code must be littered with vendor specific language hacks like __declspec and #pragma.
- Language syntax, particularly, the wide open macro system, is very unfriendly to fancy IDE features and tool supprt.
- Build tools are extremely primitive by Java standards. They have nothing close to even basic Maven, much less SBT or Gradle.
- Array syntax is counterintuitive. int array[] rather than int[] array.
- Array system is completely separate and disjoint from the template system.
- Has both structs and classes.
- Internal name mangling. Many times I had to learn and parse the internal name mangling system of Microsoft C++ tools to understand a build error.
- Separate primitive and class types.
- Marshalling memory across DLL boundaries.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #84 - Posted 2012-10-30 16:44:06 »

- Array syntax is counterintuitive. int array[] rather than int[] array.

Want to see something really weird? C++ lets you write the array access backwards. ie.

1  
2  
3  
4  
5  
char[] array = "hello";
int index = 4;

char ch1 = array[index]; // 'ch1' is 'o'
char ch2 = index[array]; // same as above


No, I have never found a use for this.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #85 - Posted 2012-10-30 17:28:43 »

- Array syntax is counterintuitive. int array[] rather than int[] array.

Want to see something really weird? C++ lets you write the array access backwards. ie.

1  
2  
3  
4  
5  
char[] array = "hello";
int index = 4;

char ch1 = array[index]; // 'ch1' is 'o'
char ch2 = index[array]; // same as above


No, I have never found a use for this.

If my understanding is correct, that only holds true for when the sizeof() the datatype of the array is equal to 1?
Otherwise the pointer arithmetic would be wrong.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #86 - Posted 2012-10-30 17:43:03 »

If my understanding is correct, that only holds true for when the sizeof() the datatype of the array is equal to 1?
Otherwise the pointer arithmetic would be wrong.

That would make sense. Unsurprisingly I've only ever used it in a toy example to prove to myself someone wasn't yanking my chain.

It's quite illustrative of the half-assed 'features' C++ is riddled with though. And you kinda have to know about them all even if you never use them, just in case you find someone who's actually used it.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Varkas
« Reply #87 - Posted 2012-10-30 22:49:59 »

I think it's actually interpreted as "+" operator between the operands, and the array name is a pointer to the element type. So you have "int" + "pointer" or "pointer" + "int" and that should work for type sizes other than 1 too ... anyways, one more reasons to be suspicious about C++ syntax Undecided

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline KittenKoder

Senior Duke


Medals: 7



« Reply #88 - Posted 2012-11-01 07:43:58 »

I think it's actually interpreted as "+" operator between the operands, and the array name is a pointer to the element type. So you have "int" + "pointer" or "pointer" + "int" and that should work for type sizes other than 1 too ... anyways, one more reasons to be suspicious about C++ syntax Undecided

That's actually one of the reasons I do and don't like c/c++, pointers are "open access." You can type cast anything to anything, but you have to remember what you've cast something as or you'll access part of something else ... maybe even part of another program.

I think you're looking for "pointer + sizeof class," but I'm late into the conversation so I could be wrong.

I am no one else.
Offline masteryoom

JGO Coder


Medals: 5
Projects: 2


If you look closely, you might see it turning...


« Reply #89 - Posted 2012-11-01 09:55:06 »

In C++, this is not valid:
1  
vector<vector<vector<double>>> myVec;


This is valid  Huh:
1  
vector<vector<vector<double> > > myVec;

I think that doesn't make sense at all.  Undecided

Smiley
Pages: 1 2 [3] 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (36 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!