But I agree that debuggers can be annoying, reconfiguring them
is often more troublesome than just adding some printf() hacks.
I find them indispensable when I am really stuck though: duh,
I have spent 15 minutes on this, time to fire up the debugger.
Hehhe reconfigure a debugger. Lolz.
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
Max Klyga:
https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters:
https://www.youtube.com/watch?v=rX0ItVEVjHc
He doesn't use RTTI, exceptions, multiple inheritance, STL,
OOP style and AoS in general does cause cache unfriendly data
access. You can separate out your hot and cold data but at that
point you're not really programming in an OO style. He doesn't
use RTTI, templates, exceptions, etc. for different reasons
than cache friendliness.
Modern C++ !=
On Wednesday, 1 October 2014 at 15:40:59 UTC, currysoup wrote:
I certainly believe C++ style and it's community promote the
idea of zero overhead abstractions and the kind of OOP style
which _does_ cause cache misses.
Take a look at the STL. See any OOP? Right cause there isn't any.
Boost?
Perhaps a (part of) language more fit/helpful/nice for that
purpose/use can be invented.
Bye,
bearophile
It isn't as hard as he pretends to write SoA code in C++. In
fact it is possible to abstract the underlying data you are
operating on, and replace it with vector type
Example
Take a look at the STL. See any OOP? Right cause there isn't
any.
Boost? Nope.
I see lots of it. How many examples do you want?
Well Boost might have some, I haven't looked at every library.
I don't know of any OOP in the STL, unless you mean the 1980's
stuff like iostreams and the
I don't know of any OOP in the STL, unless you mean the
1980's stuff
like iostreams and the other shit most people avoid using, but
I don't
think this is considered part of the STL
Any use of a class instance is part of OOP.
IOStreams, iterators, strings, containers, ranges, filesytem,
All true again, pre-allocation can fix lots of pause issues.
And simply not using GC in tight loops. While not the greatest
fan of Unity, it proved that GC (on top of of VM) is not a
concern for (I argue) most of gamedev. Minecraft was originally
written in Java for crying out loud yet it
This will most likely change when they get their IL2CPP
production ready and start moving code from C++ to C#.
Or when Microsoft finishes the ongoing work on .NET Native.
--
Paulo
I'd not seen IL2CPP before, but from this link:
On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it
wouldn't make much sense to port engine code to C# unless they
His entire reason for not using C++ lambda, and wanting local
functions instead, is faulty
His reason: I heard they can perform heap allocation.
Reality: No they do not perform heap allocation, that would only
happen if you stuffed it into an std::function
std::string tends to be more complicated because of the small
string optimization. Most debuggers I've used don't handle
that correctly out of the box, even if sorting it out really
isn't difficult.
Almost all game developers use Visual Studio, and VS has
supported visualization of all
More stupidity from JB:
At one point he talks about merging the memory of Mesh's
positions indices UV, but he does this manually like a
friggin moron;0
The proper way is using an allocator, but I'm guessing JB
doesn't grok allocators- cause they be weird templates stuff
derp!
- RAII makes most sense if you have exceptions.
RAII is orthogonal to exceptions, so his claim is nonsense.
- He does not want to write new classes to manage resources
(not only memory, but shaders etc).
I manage all resources using RAII, it did not require me to
write a new RAII
Just a note: this isn't really true. RAII was initially used to
deal with exceptions. If you want fast backtracking and just
reset the stack pointer (rather than unwinding) then
stack-allocated RAII objects won't work since they will be
overwritten. You need to maintain a list of destructors
«The technique was developed for exception-safe resource
management in C++[3] during 1984–89»
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
It may have been developed for exceptions, that doesn't mean you
have to use them together.
Alternative error reporting methods
He actually talks about Andre around 40' ;0
As a fellow game dev:
I don't agree with him about RAII, I find it useful
He kind of has a point about exceptions, I'm not big on them
I get the impression his C++ knowledge is about the level of C++
with classes, ie very low.
He claims using
No, and it neeedn't. The article is not that good. In C++, if a
thread must increment a reference counter while it's going to
zero due to another thread, that's 100% a programming error,
not a concurrency error. That's a well known and well studied
problem. As an aside, searching the net for
I'm not sure about that discussion, but there's good evidence
from C++ that refcounting with atomics works. What was the
smoking gun?
http://www.gotw.ca/gotw/045.htm
I don't see how that link answers Andrei's question? He just
compares different methods of implementing COW.
As I understand the issue it works if you make sure to transfer
ownership explicitly before the other thread gains access?
Maybe this is more clear:
http://www.1024cores.net/home/lock-free-algorithms/object-life-time-management/differential-reference-counting
Ah, I think I follow.
So in
I mean possible lifetime management options are:
1. string
2. string*
3. shared_ptrstring
4. weak_ptrstring
5. unshared_ptrstring (not interlocked; does something like
this exist?)
This way string is just like any other object. It's C++ after
all, the foot must be shot.
Exactly, you can
Smart pointers are rarely used, most C++ stuff is done by
value.
Strings too?
Two string types are used.
-std::string type: by value, has smaller buffer optimization,
used at startup/logging, and for any dynamic strings with
unbounded possible values
-immutable string handles: by value.
Basically the usual points how real enterprise C++ looks like,
where no
one cares about Effective C++ and similar practices.
Why they were using C++ for that type of software is beyond me,
I'd rather use Haskell if latency throughput aren't my main
concerns.
The paper he referenced in
Are you sure? From basic_string.h:
_CharT*
_M_refcopy() throw()
{
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__builtin_expect(this != _S_empty_rep(), false))
#endif
__gnu_cxx::__atomic_add_dispatch(this-_M_refcount, 1);
return
Heh, I like how he says static if was proposed by Walter
Brown. ;)
Is it just me or did it seem like most of the stuff in those
slides is already in D? I don't follow C++.
Walter Brown is a real person;)
The C++ dynarray stuff was appealing to me, but it got delayed,
and who knows if
programmers who really have this stuff down... how much of your
code and your mental energy with C++ is spent on memory
ownership rules? Is it really a productive use of your time?
Does the program materially benefit from the design required to
make it safe, correct, and self-documenting
The first link says that Chrome is a *90* meg binary! Gawd
damn. Either they write some really bloated code, or modern
browsers require way too much shit to function.
On Tuesday, 2 September 2014 at 09:27:29 UTC, Joakim wrote:
I was googling around for information on ninja, the build
system
Might be pretty hard, C++ has some features D doesn't, not sure
how you would emulate them.
C++ has these, I don't think D does:
move only types
r-value references
SFINAE
ADL
Multiple inheritance
28 matches
Mail list logo
