Generally, are the programs written by C++ slower than written by C10% ?

[Ian Collins]

Hi Paavo



Well then I better ask how You get the console window to stay open
long enough to read the result, when doing a build and run.?
if You dont use something like getch();

Don't use windows!

 

[none]

I test the code in a virtual machine, Fedora 15 witch in the Virtual
Box.
756M memory, 2G HZ.

And what compiler did you use and what compilation options did you
use?

We see that so often here, peoples that come up with an artificial
micro-benchmark to prove that their complex manual optimisation is
worthwhile but do not let the compiler do its job of optimising.

It is slower than malloc, it's true. Unless reuse it.

Logically, std::string allocating a buffer is unlikely to be faster
than malloc for allocating memory. However, micro-benchmark tend to
by pretty irrelevant in real programs. They typically concentrate on
one single area while ignoring other potentially much more important
areas.

 

[Ian Collins]

Logically, std::string allocating a buffer is unlikely to be faster
than malloc for allocating memory. However, micro-benchmark tend to
by pretty irrelevant in real programs. They typically concentrate on
one single area while ignoring other potentially much more important
areas.

Very true. I have a conversion application that spends nearly all of
its run time searching and modifying tens of thousands of strings.
Allocation times are way way down the profiler's output.

 

[Nick Keighley]

you appear to be trying to justify copy-paste


this is a reason for writing stuff yourself. it is /not/ a reason for
copy-paste. If you've written the code yourself why not package it in
reusable form?

I possibly misunderstood what you were saying.

now, extend this generally, and note that most freely-available code is
either proprietary (can't be reused safely at all) or GPL,

but not the standard libraries of either C or C++. There's also quite
a bit of BSD licensed code about.

and hence one
starts to see the problem, namely: why it is necessary for people to
write their own code to keep everything legal.

yes, there are MIT / BSD / ... projects, which allow more freely reusing
code without overbearing legal issues, but these projects are a relative
minority in FOSS land.

we seem to be confusing different things (you seem to move the goal-
posts)

1. I asked why you would write your own sort rather than use qsort()
as a first pass.

2. you recomended copy-paste as a devlopment methodolgy. I think
it's hardly ever a reasonable thing to do. And is responsible for much
"software rot".

3. you (reasonably) use license problems as a reason to reinvent the
wheel.

3 is not a justification for either 1 or 2

 

[Nobody]

Well then I better ask how You get the console window to stay open
long enough to read the result, when doing a build and run.?
if You dont use something like getch();

Use something standard like cin.get();

 

[Juha Nieminen]

Use something standard like cin.get();

Visual Studio can be configured so that the command prompt window will
not close when the program terminates.

 

[Rui Maciel]

Well then I better ask how You get the console window to stay open
long enough to read the result, when doing a build and run.?
if You dont use something like getch();

Doesn't windows provide a command line? It it doesn't then you can always
run your command line program through some script which, after running the
program, calls pause. At least this was possible in the Windows 9[58] days.
Do the recent incantations of windows still support batch files?


Rui Maciel

 

[Asger-P]

Hi Rui

Doesn't windows provide a command line?

Ooh, yes and it also handles batch files.
I have posted a question in embarcadero.public.cppbuilder.ide
to see if there is a setting that will do, if not I think I'll
stick with std::cin.get();

Thanks anyway
Best regards
Asger-P

 

[BGB]

Those are true (I know this because I have done a lot of C++ compiler
work), but frankly, people writing C++ parsers / compilers / etc, are
a miniscule fraction of the people using C++ for other tasks.

So what you have, basically, is harder work for a few, to make things
easier/better/safer for many.

Again, a pretty decent tradeoff.

fair enough.
the problem is that I don't really have enough time/energy/... to
personally justify going through the work (all at once), though I may
eventually have it in a "one piece at a time" sense.


for interfacing between a script language and C++ at the C++ level, one
would probably need (in a basic sense):
ability to share classes (at least import them, to use C++ APIs directly
from the HLL, much harder is exporting classes to C++, and harder still
would be to allow mutual inheritance/overloading);
....


or, say for example, transparently interfacing C++ and an ECMAScript
variant (similar to JavaScript or ActionScript), ideally without making
awkward/arbitrary restrictions for one or the other (including semantic
mismatches).


as-is, C structs can be shared, but my scripting VM has several notable
restrictions WRT shared structs (ones shared between C code and the
scripting VM):
minor "construction" issues ("new structname();" will create a struct,
but not necessarily in the "correct" way for a given use-case);
currently, the struct needs to be a type known to the GC/... (needs to
be allocated in "managed" memory, or the memory-region needs to be
registered with the GC with the appropriate handlers set up, also the
declaration needs to be visible-to/processed-by the metadata tool);
currently, structs may not be directly/physically nested (except in
certain special cases, but may be linked freely via pointers);
arrays-of-structs don't currently work (one needs arrays of pointers to
structs instead);
shared function pointers are very much a "use with caution" feature
(function pointers work both-ways, but have not been well tested
extensively, and I don't much "trust" the feature, as well as it
introducing additional restrictions);
....


a lot of the reason for these issues is that the VM/language is
internally "soft typed" (sort of a mix of static and dynamic typing).
WRT handling complex data types, it currently uses dynamic
type-checking, and if the VM can't determine the type of the object a
pointer refers to, it will simply treat it as a no-op opaque value
(often happens, say, will malloc'ed memory, ...).

in a few cases, the VM uses "boxed pointer values" (basically where the
pointer is boxed in a heap-based object which also tracks its type,
usually done if the static type is known but a dynamic type is not
visible with the pointer), but this is expensive (when loading a
pointer, the VM may examine it and determine if it needs to box it,
avoiding doing so if possible).

as can be noted, "new structname();" will generally create the struct as
a "pass-by-value" boxed type (rather than currently as its assigned
dynamic type name, note example below). however, semantics/... get hairy
here (and, typically, explicit constructor functions are used for most
cases where this would matter).


so, as-is, not even C is perfectly handled at its own level (but, the
subset is "generally good enough" for most tasks).


so, in a basic sense, C++ struct-based objects could be shared in a
limited sense:

typdef struct Foo_s Foo;
struct Foo_s dytname("myapp_foo_t") //dytname==dynamic type name
{
fields...

#ifdef __cplusplus
.... non-virtual methods ...
#endif
};


the trivial extension would be to have the metadata tool be able to
accept the class keyword, and be able to parse non-virtual methods.


the biggie issue though:
about as soon as one defines "__cplusplus" in the preprocessor, then
usually one also gets a mountain of template definitions and other
things (even from otherwise theoretically plain C headers), meaning that
the parser/tools/... have to be prepared to deal with all this.

there is no real option for a tool to be like (to the system headers)
"only give me those pieces of code I can deal with". actually... one
often even has to emulate certain compilers just to make the headers
happy, as many headers will themselves refuse to work correctly if one
doesn't define, say:
__GNUC__
__GCC_VERSION__
....

which means that my tools have ended up supporting many GCC and MSVC
extensions (and partial compiler emulation) simply trying to get the
headers parsed.

as-is, I am partly left scared of the C++ case.

otherwise, one would need a lot of special case stuff, essentially
making the "tools" case separate from either the C or C++ cases.

#if defined(__cplusplus) || defined(_BGBMETA)
....
#endif

or, creating a new PP define to reflect a common sub-case (a C++ subset
understandable to the tools).


my preference thus far had been for types/magic-modifiers/... which
could be made special for the tool, but otherwise invisible to plain C
or C++ compilers (or will expand to something more generic).

"dytname()" is such an example, where in the tool it will expand to a
special attribute, and in plain C or C++ (native compiler) it will
expand to nothing.


technically, the main metadata tool should be able to at least parse
basic C++ style syntax (class definitions, ...), but lacks many other
less trivial matters.

namespaces may pose additional difficulties (they are partially
supported, but very hackish, and concepts like scoped-typedefs, ... are
not currently handled).

IMO, templates also look like a big ugly issue.


currently, there is no support for the C++ ABI (and my own object system
works a bit differently, meaning a 1:1 mapping with C++ ABI classes
could be itself difficult).

also, classes would either need to overload "new" to use the GC for
allocation, or the VM/GC will have to be aware of and able to deal with
RTTI (has its own sets of worries).

....


I guess one can ask though how easy it can really be to interface
several not-exactly-similar languages (such as C and ECMAScript), and
avoid creating any ugly seams in the process.

it is also a question of how much can be readily done in a single person
project as well.

[and given that I'm part of "the few", as well as part of the "many"
(I use C++ for many tasks), I think I have a pretty reasonable view of
this tradeoff. Indeed, for compiler writers, the additional
complexity isn't some sort of pure annoyance -- it's also in many ways
more interesting to work on (and for those writing their compiler in
C++, of course, a benefit)... :]

fair enough...

actually, my compiler and VM stuff is itself mostly written in C, mostly
because I figure it would be useful for the VM to be able to access its
own functionality.

similarly, most VM functionality is also exposed to C and C++ code,
albeit with the existing restrictions (typically, a minimally-adorned
C-like interface is provided, as going and writing a mountain of
cosmetic wrappers would be much added effort).


a few parts of my 3D engine, however, are C++, but admittedly it is
typically a fairly minimalist form (C-like with a few classes, and
generally no real use of templates or namespaces).

a partial reason for lack of namespaces:
because I am lazy and generate many of my headers with tools, and this
particular tool is fairly naive/simplistic (also under 1 kloc), neither
understanding namespaces nor preprocessor directives, and has some of
its own special command-language embedded in comments (or occasionally
in special preprocessor directives, which are treated as literal tokens).

this tool doesn't care about "using" and namespaces, or "::", but does
care about declaring code in namespaces, which it will screw up with,
and would have to be told to ignore the whole region.

 

[Noah Roberts]

fair enough.
the problem is that I don't really have enough time/energy/... to
personally justify going through the work (all at once), though I may
eventually have it in a "one piece at a time" sense.

for interfacing between a script language and C++ at the C++ level, one
would probably need (in a basic sense):
ability to share classes (at least import them, to use C++ APIs directly
from the HLL, much harder is exporting classes to C++, and harder still
would be to allow mutual inheritance/overloading);
...

or, say for example, transparently interfacing C++ and an ECMAScript
variant (similar to JavaScript or ActionScript), ideally without making
awkward/arbitrary restrictions for one or the other (including semantic
mismatches).

http://www.boost.org/doc/libs/1_47_0/libs/python/doc/

 

[KaiWen]

And what compiler did you use and what compilation options did you
use?

gcc version 4.6.0 20110428 (Red Hat 4.6.0-6) (GCC)

 

[none]

gcc version 4.6.0 20110428 (Red Hat 4.6.0-6) (GCC)

compilation options? These are the key. Huge difference of behaviour
between -O0 and -O3.

 

[KaiWen]

compilation options?  These are the key.  Huge difference of behaviour
between -O0 and -O3.

Oh, Sorry.
-Wall -O2

 

[BGB]

http://www.boost.org/doc/libs/1_47_0/libs/python/doc/

fair enough, will have to look at it...
(not at the moment though, as I don't have a lot of time at the moment...).


granted, I am not likely to switch to Python either, as:
this would be too much effort;
Python does not rank very highly on my list of "languages I am likely to
willingly use" (bleh, seems crufty and with a funky syntax...).


nevermind the drawbacks in my system, for the most part, its interface
(with C) is reasonably transparent and not too painful to use (it allows
bidirectional calls, automatic type conversion in most cases, and
generally allows cross-language sharing of data structures, ...).


most of the cross-language semantic limitations follow fairly directly
from the semantics of either one language or the other:
one language allows adding fields per-instance for any object;
for obvious enough reasons, this wont work with C.

also, my languages' struct semantics were mostly derived from C#, hence
why it has funky interpretation of "new struct()", because it
handles/understands structs it in a C#-like way (I may later either make
a special exception for C-structs, or use a declaration modifier).

say:
struct Foo_s dytname("mylib_foo_t") dytnewref
{
};

with "dytnewref" meaning to create a new instance as a reference type.


or such...

 

[BGB]

you appear to be trying to justify copy-paste

of ones' own code...

copy/paste may well be justified in some cases, such as to avoid
creating a physical dependency between unrelated components, whereas
traditional code-reuse creates dependencies by extension.

however, copy-paste from others' code is plagiarism and may also be illegal.

this is a reason for writing stuff yourself. it is /not/ a reason for
copy-paste. If you've written the code yourself why not package it in
reusable form?

typically because this creates dependencies between ones' components.

factoring things out to eliminate dependencies while still having
code-reuse may often introduce a fair amount of additional architectural
complexity (reuse via "mutual 3rd parties", ...).

copy-paste allows physical decoupling without the need to create "3rd
parties".


a problem though is when copy-paste introduces "synchronization issues",
which yes, can be a nasty problem. ideally code should not be
copy-pasted in this case, or any such synchronization should be defined
as part of the "formal model" of whatever code or data is in question
(an example is things like codecs, where it is assumed that whatever
comes back out is whatever the encoder intended to come out, ...).

I possibly misunderstood what you were saying.



but not the standard libraries of either C or C++. There's also quite
a bit of BSD licensed code about.

actually, several major implementations (glib, newlib, ...), are "GPL
with linking exception" and similar.

others, such as MSVCRT, are closed-source AFAIK.


if one were to copy-paste from glib or similar, they would still likely
be stuck with GPL, but the library itself can be linked to without issue.

we seem to be confusing different things (you seem to move the goal-
posts)

1. I asked why you would write your own sort rather than use qsort()
as a first pass.

2. you recomended copy-paste as a devlopment methodolgy. I think
it's hardly ever a reasonable thing to do. And is responsible for much
"software rot".

3. you (reasonably) use license problems as a reason to reinvent the
wheel.

3 is not a justification for either 1 or 2

hell, who knows, I go wherever the topic takes me, and have never really
been so good with keeping on-topic anyways...


or such...

 

[Ian Collins]

of ones' own code...

copy/paste may well be justified in some cases, such as to avoid
creating a physical dependency between unrelated components, whereas
traditional code-reuse creates dependencies by extension.

What? By that logic, all libraries should be removed and their source
code copied instead. Lunacy.

If you are that paranoid about dependencies, put each function in a
header and include that...

 

[BGB]

What? By that logic, all libraries should be removed and their source
code copied instead. Lunacy.

it is a tradeoff:
going this route (entirely) would tend to make many projects overly large.

If you are that paranoid about dependencies, put each function in a
header and include that...

but one still depends on the header, and depending on a header isn't
necessarily all that much better (however, I have done similar for a few
things, as the compiler tends to omit any static functions which are
never called, ...).

a partial advantage of headers is that they themselves can be more
readily copy-pasted and need not create additional dependencies, however
a partial disadvantage is that headers like this can potentially cause
horrible compile-time performance and a lot of unnecessary bloat, so it
is a tradeoff (it is bad enough when one already ends up with several MB
of included code just including many basic OS headers).


but, typically, one will copy/paste code, and use find/replace or sed to
re-scope it (replacing library/component prefixes or similar), and then
edit the code into the desired form for its use in a given component.

but, otherwise, one ends up with lots of centralized code that ends up
being depended on by lots of potentially unrelated things.


however, code may be centralized if it makes sense, say if there is
already a conceptually and mutually depended-on component, one may
consider migrating shared code to this location, provided it can be
sufficiently decoupled from its respective use-cases (does not have any
dependencies on the code which uses it, ...).


for example, memory management can be largely centralized (because most
code does roughly the same sorts of things with a memory manager).
likewise for things like filesystem interfacing, ...

things like parser logic are typically copy-pasted all over and
specialized for each use case, since it is far more difficult to
separate a parser from its use-cases (a parser for XML, one for C, and
one for ASM, and another for id/Valve/... style map files, ..., are each
sufficiently different to make having common code problematic, but are
sufficiently similar that it would be pointless to write the code
entirely from-scratch each time).

as well, things like variations in token rules and AST structure would
likely be difficult to generalize without introducing a heavy overhead
(such as doing tokenization via a regex-like system, ...).


a partial edge case is something like a 3D renderer, which although
having much variation between renderable objects, ... one gets a larger
payoff by having a unified scene-graph and rendering architecture (for
example, tasks like lighting and shadows can be kept more consistent, vs
having each and every scene object try to implement its own lighting and
shadowing algorithms).

another reason for unifying a 3D renderer, and also things like a
camera-control interface, ... is because a single user can only validly
interact with a single renderer at a time, and so one may benefit some
from scene-consolidation in this case (say, being able to have anything
which may be rendered, be potentially usable in the same scene at the
same time).


granted, this says little regarding the need for several separate apps
to have a shared 3D renderer, or potentially for a single 3D app to have
only a single renderer (an example would be an app providing separate
renderer implementations for OpenGL, DirectX, real-time software
rendering, and high-quality offline batch rendering).

in the above case, each may have sufficient differences between how they
work, that addressing all of these cases via a single rendering backend
may be unworkable (hence leading to separate implementations).


similar may also apply to code which needs to be somewhat specialized
for each OS, CPU architecture, ...


or such...

 

[BGB]

Hi Paavo



Well then I better ask how You get the console window to stay open
long enough to read the result, when doing a build and run.?
if You dont use something like getch();

FWIW, there are also "getc();" and "fgetc(stdin);" which are at least
more standard, but are also C-style, unlike "cin.get();" which is more
properly C++ (by whatever logic this makes sense, I don't get people
sometimes, as everything works either way, but whatever...).


but, stdio vs iostreams is another long and eventually pointless debate...

 

[Miles Bader]

FWIW, there are also "getc();" and "fgetc(stdin);" which are at least
more standard, but are also C-style, unlike "cin.get();" which is more
properly C++ (by whatever logic this makes sense, I don't get people
sometimes, as everything works either way, but whatever...).

but, stdio vs iostreams is another long and eventually pointless debate...

No doubt, but it does make sense in many cases to at least prefer one
or another, because _mixing_ them can be problematic and/or
inefficient.

-Miles

 

[Ian Collins]

it is a tradeoff:
going this route (entirely) would tend to make many projects overly large.

It also makes them exceedingly difficult to maintain.

but one still depends on the header, and depending on a header isn't
necessarily all that much better (however, I have done similar for a few
things, as the compiler tends to omit any static functions which are
never called, ...).

a partial advantage of headers is that they themselves can be more
readily copy-pasted and need not create additional dependencies, however
a partial disadvantage is that headers like this can potentially cause
horrible compile-time performance and a lot of unnecessary bloat, so it
is a tradeoff (it is bad enough when one already ends up with several MB
of included code just including many basic OS headers).

Bollocks. If the code has to change, in my world the header changes and
N source files that use it rebuild. In yours, you edit all N places you
copied and pasted and N source files rebuild. I do 1/N times as much
work and the compiler does the same in both cases.

Now as for bloat, please explain how N function calls cause more bloat
than N copy and pastes.

but, typically, one will copy/paste code, and use find/replace or sed to
re-scope it (replacing library/component prefixes or similar), and then
edit the code into the desired form for its use in a given component.

Boy you sure like making work for your self, don't you?

but, otherwise, one ends up with lots of centralized code that ends up
being depended on by lots of potentially unrelated things.

Just like the standard library!

however, code may be centralized if it makes sense, say if there is
already a conceptually and mutually depended-on component, one may
consider migrating shared code to this location, provided it can be
sufficiently decoupled from its respective use-cases (does not have any
dependencies on the code which uses it, ...).

That's called a function template...

for example, memory management can be largely centralized (because most
code does roughly the same sorts of things with a memory manager).
likewise for things like filesystem interfacing, ...

things like parser logic are typically copy-pasted all over and
specialized for each use case, since it is far more difficult to
separate a parser from its use-cases (a parser for XML, one for C, and
one for ASM, and another for id/Valve/... style map files, ..., are each
sufficiently different to make having common code problematic, but are
sufficiently similar that it would be pointless to write the code
entirely from-scratch each time).

Those documents are all structured differently, so forcing the same
parser logic on each would be folly.