http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Standard C++ way to generate a Jump Table ??? - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
* Does anyone else wish the C++ standards committee would give us parity with
other programming languages? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
* Corrected: Using type suffixes with floating point constants - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
* passing arrays from C to fortran - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/01c625d642dd2350?hl=en
* A question about a section in "Inside the C++ Object Model" - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
* Open source my OIOIC, a completely new object-oriented mechanism for the C. -
2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/a0d8b0af96cf35bb?hl=en
* Do vector iterators remain valid after resize() if base pointer of elements
remains unchanged? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a2112c3799287ef5?hl=en
* Help understanding this function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/69b739b156823692?hl=en
* disadvantages of using STL - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
* how to send an e-Mail with attachment? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/aba76f403a10120c?hl=en
==============================================================================
TOPIC: Standard C++ way to generate a Jump Table ???
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Mar 27 2009 3:45 pm
From: "Peter Olcott"
"Paavo Helde" <paavo@nospam.please.ee> wrote in message
news:Xns9BDBEB6DC413Enobodyebiee@216.196.109.131...
> PeteOlcott <PeteOlcott@gmail.com> kirjutas:
>>
>> When I attempt to optimize my code, I do not take the
>> term "optimize"
>> figuratively like compiler optimizers do. When I optimize
>> my code I
>> make every attempt to make the code as fast as possible
>> within the
>> binding constraint of the semantic requirements. Also I
>> carefully
>> select the set of semantic requirements from a
>> categorically
>> exhaustive set of every combination that provides the
>> desired end-
>> result. This process works exceptionally well for all
>> development
>> where the desired end-result can be specified in a
>> mathematically
>> rigorous way.
>
> Sounds like you should really program in assembler, then.
> However, even
> this can't guarantee full control nowadays, with
> microcode, branch
> prediction, virtual machines, multi-core cache syncing,
> etc. I believe
> there is no need to mention a well-known cite from a
> well-known 70-era
> computer scientist.
>
> Best regards
> Paavo
>
>
Donald Knuth made the following statement on optimization:
"We should forget about small efficiencies, say about 97% of
the time: premature optimization is the root of all evil."
Although he may have been right for most of software
development (application programming) I would go so far as
to say that he was flat out wrong for systems programming.
With the process that I have created, the ballpark of the
best possible system** can be created for about the same
cost as mediocrity, because the cost break down is 70%
design 20% coding and 10% debugging and testing. ** Maximum
speed, ease of use, maintainability and reliability.
No, actually with your great suggestion that eliminated the
extra code in the C++ switch statement I can finally produce
the quality of code that I have been striving for all along.
I can tell from the quality of the generated assembly
language that there is no possible further improvement of
this fundamental control flow construct. (Within the binding
constraint of the machine architecture).
== 2 of 5 ==
Date: Fri, Mar 27 2009 3:56 pm
From: Paavo Helde
"Peter Olcott" <NoSpam@SeeScreen.com> kirjutas:
> No, actually with your great suggestion that eliminated the
> extra code in the C++ switch statement I can finally produce
> the quality of code that I have been striving for all along.
Out of interest, which suggestion do you refer to? unsigned char, __assume
or enum N^2? And how many percents of speed increase in typical usage?
Don't get me wrong, I'm a big fan of (program) performance myself. But I
usually stop much earlier. I would just like to know what I'm losing.
Best regards
Paavo
== 3 of 5 ==
Date: Fri, Mar 27 2009 5:08 pm
From: "Peter Olcott"
"Paavo Helde" <paavo@nospam.please.ee> wrote in message
news:Xns9BDC999020EFnobodyebiee@216.196.109.131...
> "Peter Olcott" <NoSpam@SeeScreen.com> kirjutas:
>
>> No, actually with your great suggestion that eliminated
>> the
>> extra code in the C++ switch statement I can finally
>> produce
>> the quality of code that I have been striving for all
>> along.
>
> Out of interest, which suggestion do you refer to?
> unsigned char, __assume
> or enum N^2? And how many percents of speed increase in
> typical usage?
I missed the last one. The first one was enlightening, and I
used the second one. I estimate that the speed of the
critical loop will be between 20% to 30% faster.
Your suggestion can be applied to four different places in
this tight loop.
The reason that I am optimizing by this degree is that it
only takes me a few extra days for a year long project, and
it is good to know in advance that no one will be able to
beat my system's performance. I estimate that it will be at
least 100-fold faster than the next best alternative system.
>
> Don't get me wrong, I'm a big fan of (program) performance
> myself. But I
> usually stop much earlier. I would just like to know what
> I'm losing.
When one very tiny portion of the system represents 98% of
the CPU cycles it is probably always worth extreme levels of
optimization. My heuristic was to stop just short of actual
assembly language programming. The rest of the system might
take about twice as long as the fastest possible code.
I may eventually optimize this code too. My goal is to make
a product of the same quality as Turbo Pascal 3.0. In my
opinion this product was an example of the epitome of the
best possible quality.
>
> Best regards
> Paavo
== 4 of 5 ==
Date: Fri, Mar 27 2009 5:26 pm
From: blargg.ei3@gishpuppy.com (blargg)
Peter Olcott wrote:
[...]
> No, actually with your great suggestion that eliminated the
> extra code in the C++ switch statement I can finally produce
> the quality of code that I have been striving for all along.
> I can tell from the quality of the generated assembly
> language that there is no possible further improvement of
> this fundamental control flow construct. (Within the binding
> constraint of the machine architecture).
I doubt it. What about eliminating the jump table and calculating the
destination as PC+(N<<shift), so that each case statement is some power of
2 from the previous? There's always room for improvement, and the
micro-improvements are generally beyond a compiler.
== 5 of 5 ==
Date: Fri, Mar 27 2009 6:28 pm
From: "Peter Olcott"
"blargg" <blargg.ei3@gishpuppy.com> wrote in message
news:blargg.ei3-2703091926550001@192.168.1.4...
> Peter Olcott wrote:
> [...]
>> No, actually with your great suggestion that eliminated
>> the
>> extra code in the C++ switch statement I can finally
>> produce
>> the quality of code that I have been striving for all
>> along.
>> I can tell from the quality of the generated assembly
>> language that there is no possible further improvement of
>> this fundamental control flow construct. (Within the
>> binding
>> constraint of the machine architecture).
>
> I doubt it. What about eliminating the jump table and
> calculating the
> destination as PC+(N<<shift), so that each case statement
> is some power of
> 2 from the previous? There's always room for improvement,
> and the
> micro-improvements are generally beyond a compiler.
Infeasible, more cases than bits, and memory use would grow
absurdly fast.
There is no feasible improvement within the binding
constraints.
==============================================================================
TOPIC: Does anyone else wish the C++ standards committee would give us parity
with other programming languages?
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Mar 27 2009 3:53 pm
From: "Thomas J. Gritzan"
Anonymous Infidel... wrote:
> Or better yet, force them(C#, Java, etc) to do the catch up game....
Why should we force the C# guys or the Java guys to catch up with C++?
Well, it would be nice if those languages had support for RAII, or even
templates, but why force them? ;-)
--
Thomas
== 2 of 2 ==
Date: Fri, Mar 27 2009 10:34 pm
From: sebastian
>> Or better yet, force them(C#, Java, etc) to do the catch up game....
What are you talking about? Catch up *how*? You can do just about
anything with C++. You might have to write it from scratch, of
course...
==============================================================================
TOPIC: Corrected: Using type suffixes with floating point constants
http://groups.google.com/group/comp.lang.c++/t/e4b6beec5748ef9f?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 4:11 pm
From: Victor Bazarov
Ioannis Vranos wrote:
> Victor Bazarov wrote:
>> Ioannis Vranos wrote:
>>> ISO/IEC 9899:1990/1995 says (from K&R2):
>>>
>>> "A6.4
>>>
>>> When a less precise floating value is converted to an equally or more
>>> precise floating type, the value is unchanged.
>>>
>>> ==> When a more precise floating value is converted to a less precise
>>> floating type, and the value is within representable range, the
>>> result may be either the next higher or the next lower representable
>>> value.
>>>
>>> If the result is out of range, the behavior is undefined".
>>>
>>>
>>> Question: Does the above mean that it is a good practice or *always*
>>> needed to use the appropriate type suffixes with floating point
>>> constants?
>>
>> No, the above does not mean that. You need to look at the definition
>> of the FP literals. The suffix only says what type the literal has.
>> The suffix does not control potential precision. IOW
>>
>> float Pi = 3.1415926;
>> float Pi_ = 3.1415926f;
>>
>> will *likely* have the same value since the number of digits (8) in
>> the literals is greater than 'float' can represent (7), and both
>> numbers will be "fixed", only at different times, so to speak. The
>> former will be squeezed into a 'float' at the time of initialising of
>> 'Pi' (formally by your program), the other will be squeezed into a
>> 'float' by the compiler upon creating the literal. It is conceivable
>> that the numbers will be different *if* your compiler uses a different
>> way of "fixing" of the value to fit into a 'float' than your program
>> (which can actually be controlled in some cases by a flag in the
>> CPU/FPU, IIRC).
>
>
> The sizes differ in my system:
>
>
> #include <iostream>
>
>
> int main(void)
> {
> using namespace std;
>
> cout<<"sizeof(0.33439F)= "<< sizeof(0.33439F)<< ", sizeof(0.33439)= "
> <<sizeof(0.33439)<<endl<< endl;
>
>
> return 0;
> }
>
>
> john@ubuntu:~/Projects/anjuta/cpp/src$ ./foobar
> sizeof(0.33439F)= 4, sizeof(0.33439)= 8
>
> john@ubuntu:~/Projects/anjuta/cpp/src$
Ahem... If there weren't different, why would we have this
conversation, right? Of course they are different. But what does this
have to do with the issue at hand? You're asking about initialising a
'float' with either an explicit 'float' literal or with a 'double'
literal. I am saying that there would be most likely no difference *for
the resulting 'float'*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
==============================================================================
TOPIC: passing arrays from C to fortran
http://groups.google.com/group/comp.lang.c++/t/01c625d642dd2350?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 4:23 pm
From: "Default User"
Shiv wrote:
> Hi,
>
> I am using a single C program and 25 fortran modules for my project.
> The fortran module depend on the C program. I need to pass certrain
> arrays from the C program to the Fortran module.
I have no particular experience with this. A quick search turned up
some sites:
<http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortranAndC.html>
<http://www.physiology.wisc.edu/comp/docs/notes/not017.html>
<http://astro.berkeley.edu/~wright/f2c.html>
<http://www-mipl.jpl.nasa.gov/RTL/RTL_Manual-2_6.html>
I don't know if those would be of benefit or not.
Brian
==============================================================================
TOPIC: A question about a section in "Inside the C++ Object Model"
http://groups.google.com/group/comp.lang.c++/t/f0c8344a7742e492?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 5:04 pm
From: "Alf P. Steinbach"
* goodbyeera@gmail.com:
> [Multi-posting]
Don't.
Please read the group's FAQ and some general info on multiposting etc.
Cheers,
- Alf
==============================================================================
TOPIC: Open source my OIOIC, a completely new object-oriented mechanism for
the C.
http://groups.google.com/group/comp.lang.c++/t/a0d8b0af96cf35bb?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Mar 27 2009 6:16 pm
From: pervise.zhao@gmail.com
Attention,please! OIOIC starts from philosophy (the Philosophy of
Dialectical Materialism), not language, and is designed all through on
the high level of the philosophy, not merely on the level of language.
Welcome everyone to continue the discussion, express your views on
OIOIC.
== 2 of 2 ==
Date: Fri, Mar 27 2009 10:28 pm
From: sebastian
Your library looks very sophisticated, and certainly appears to be
well thought out. But the design is heavy handed, and way too
complicated to be very useful. Languages such as C++ are much more
straightforward, by comparison, and have already solved these sorts of
problems, anyway (I should probably point out that this is a C++
forum, by the way!). But good luck to you. Cheers.
- Sebastian
==============================================================================
TOPIC: Do vector iterators remain valid after resize() if base pointer of
elements remains unchanged?
http://groups.google.com/group/comp.lang.c++/t/a2112c3799287ef5?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 6:35 pm
From: "Balog Pal"
"rep_movsd" <rep.movsd@gmail.com>
>> Obviously, you aren't familiar with the Intel architecture.
>All Right, I heard of them now...
Guess Intel's architecture manuals and data sheets are available for DL to
anyone actually interested to learn how stuff works.
>Well, considering that a 32 bit CPU can never address more than that
anyway ( forget the 36 bit PAE shenanigans ),
Says who? Normally the X-bit means the width of the processor's data bus.
Some other times the general-purpose registers. It has absolutely nothing to
do with the address bus width (-> accessible phisical memory) or the
internal address space.
> I don't get how 48 bit addresses would be beneficial. Could you elaborate
> ( since you
actually used them ) ?
For the discussed architecture the 48 bit refers to the pointer not the
address. The pointer has a 16 bit selector and a 32 bit offset. The
selector has a few control bits, the rest is used to select a *descriptor*
(from the descriptor table), that defines a memory segment in the virtual
address space with its base, length, access rights, etc.
>> It does on an Intel 80x86. I've actually seen it happen.
>Which instruction(s) specifically?
anything that loads the segment
Windows 3.1 used the segmented 16 bit model, with 32 bit pointers having
selector+16 bit offset. To pass a pointer value to a function sometimes it
used
void foo(void * vp);
void * p; // not inited
foo(p);
--> assy as
LES bx, [_p]
push bx
push es
call _foo
that even made sense if opt for space was asked for, it takes 1 byte less of
opcode...
Certainly if the loaded value was not a valid selector, it causes a trap,
and the famous 'unrecoverable application error'.
==============================================================================
TOPIC: Help understanding this function
http://groups.google.com/group/comp.lang.c++/t/69b739b156823692?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 7:18 pm
From: "Chris Saunders"
"Sherm Pendley" <spamtrap@dot-app.org> wrote in message
news:m1zlf7ijmy.fsf@dot-app.org...
> "Chris Saunders" <evas@mountaincable.net> writes:
>
>> I personally would never withhold assistance to someone who posts in a
>> style that I dislike
>
> Nor would I.
>
> But I would, and do, choose to ignore those who think that the rules for
> etiquette and manners are mere "style," and don't apply to them.
>
> *plonk*
>
> sherm--
>
> --
> My blog: http://shermspace.blogspot.com
> Cocoa programming in Perl: http://camelbones.sourceforge.net
I am bottom posting this message because, although I am not convinced, the
argument given is somewhat convincing to me. I do not know the meaning of
"*plonk*" but it seems to me that it has a negative connotation. I would
not have continued posting on this subject had I not received what I
considered to be an insulting comment regarding the fact that I suffer from
sugar diabetes. Your argument deserves further thought and I will give it
some. Please note that I have attempted to remain polite even I considered
myself to have been offended.
Regards
Chris Saunders
==============================================================================
TOPIC: disadvantages of using STL
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 7:28 pm
From: Bo Schwarzstein
On Mar 18, 4:31 am, Pallav singh <singh.pal...@gmail.com> wrote:
> Q What are the disadvantages of using STL ?
>
> Thanks in advance
> Pallav Singh
In fact, the only disadvantage of STL is that I need DMA, get out the
data directly to feed the OpenGL. But in most times I have to allocate
another memory then "copy".
==============================================================================
TOPIC: how to send an e-Mail with attachment?
http://groups.google.com/group/comp.lang.c++/t/aba76f403a10120c?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Mar 27 2009 7:30 pm
From: Bo Schwarzstein
On Mar 27, 3:24 am, Cristiano <crixti...@gmail.com> wrote:
> Please,
>
> I'm writing a program in C++ who needs to send a file using e-Mail
> (SMTP). In another words, I need a code, in C++ to send a email with
> attachment.
>
> I'm programming for Win32 with DevC++. I had search in web but I can't
> find something realy good.
>
> Please, where can I find an OpenSource solution to help me?
>
> Thank you.
>
> Cristiano
Look at here, http://www.codeproject.com/KB/IP/CSmtp.aspx
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment