http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* (www.topsellingnow.com) sell ed hardy t-shirts hoodies,sell Newest authentic
NFL,NBA,MLB jerseys with tags - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/caf1f297aa2c6120?hl=en
* (www.topsellingnow.com) cheap wholesale Jordan Sneakers : nike air jordan 1
nike air jordan 2 sneakers nike air jordan mens sneakers air jorda 2 womens
sneakers nike air jordan 3 nike air jordan 4 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/32197b772be68c86?hl=en
* Creative Recreation shoes www.topsellingnow.com cheap sell Designer Shoes,
sneakers,boots,Sandals,slipper. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6c6f91b5f15f329b?hl=en
* fork in C++ - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/330f3d08b477ed33?hl=en
* How can I send a file through socket? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/27ac5829b78bc4d5?hl=en
* static array declaration in flyweight pattern - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/b4df4db8ab107e11?hl=en
* C++ Gurus - Is C++ a good choice for public API(s)??? Are there clean ways
to solve known problems there? - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/faaac8999a2ece5e?hl=en
* The best way to retrieve a returned value... by const reference? - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0f3ad790abe791fc?hl=en
* C++ stuff I can't talk about here - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5017e5dbab2a63a3?hl=en
* High Cohesion and Low Coupling in C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d8ed656848516be4?hl=en
==============================================================================
TOPIC: (www.topsellingnow.com) sell ed hardy t-shirts hoodies,sell Newest
authentic NFL,NBA,MLB jerseys with tags
http://groups.google.com/group/comp.lang.c++/t/caf1f297aa2c6120?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 11:36 am
From: topsellingnow@gmail.com
(www.topsellingnow.com) cheap discount price,wholesale cheap rich yung
t-shirts,
hoodies pures leather belt and discount jeans price
(www.topsellingnow.com) sell Artful dodger t-shirts
(www.topsellingnow.com) sell clh hoodies
(www.topsellingnow.com) wholesale juicy couture and boss t-shirts
(www.topsellingnow.com) sell ed hardy t-shirts hoodies
(www.topsellingnow.com) china cheap Ed hardy outlet,
(www.topsellingnow.com) Ed Hardy Shop Online at topsellingnow.com
below is some of our procuts:
1.sell Newest authentic NFL,NBA,MLB jerseys with tags
2.sell Jeans: bape,bbc,evisu,ed-hard,seven,m iss-sixty
3.sell T-SHIRTS :Lacoste,bape,bbc,evisu,ed-har d,polo
4.sell Hoody: bape,ed-hard,bbc,evisu,
5.sell air jordan, bape shoes, air max
Our web-page: www.topsellingnow.com
E-mail: topsellingnow@yahoo.com.cn
Msn: topsellingnow@hotmail.com
==============================================================================
TOPIC: (www.topsellingnow.com) cheap wholesale Jordan Sneakers : nike air
jordan 1 nike air jordan 2 sneakers nike air jordan mens sneakers air jorda 2
womens sneakers nike air jordan 3 nike air jordan 4
http://groups.google.com/group/comp.lang.c++/t/32197b772be68c86?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 11:38 am
From: topsellingnow@gmail.com
(www.topsellingnow.com) cheap wholesale Jordan Sneakers : nike air
jordan 1 nike air jordan 2 sneakers nike air jordan mens sneakers air
jorda 2 womens sneakers nike air jordan 3 nike air jordan 4 nike
air jordan 5 nike air jordan 6 nike air jordan 7 nike air jordan 8
nike air jordan 9 nike air jordan 10 nike air jordan 11 nike air
jordan 12 nike air jordan 13 nike air jordan 14 nike air jordan 15
nike air jordan 16 nike air jordan 17 nike air jordan 18 nike air
jordan 19 nike air jordan 20 nike air jordan 21 nike air jordan 22
nike air jordan 23 Air Jordan Fusion nike air jordan 5 X air force
one fusion nike air jordan 12 x nike air force one fusion Air Jordan
Dub Zero Air jordan DMP Air Jordan BMP Air Jordan Ol'School Air
Jordan Spik'Ike Air Jordan Big size
(www.topsellingnow.com) cheap wholesale Nike Air Max Trainers : Nike
air max LTD Nike air max Tn Nike air max 87 Nike air max 90 Nike
air max 90 360 Nike air max 91 Nike air max 95 Nike air max 95 360
Nike air max 97 Nike air max 97 360 Nike air max 180 nike air max
360 Nike air max 2003 Nike air max 2004 Nike air max 2005 Nike air
max 2006 Nike air max 2007
(www.topsellingnow.com) cheap wholesale Nike Shox trainers Nike Shox
Nz Nike Shox Oz Nike Shox R2 Nike Shox R3 mens nike shox R3 women
Nike Shox R4 mens nike shox R4 women Nike Shox R5 Nike Shox TL 1
Nike Shox TL 2 Nike Shox TL 3 Nike Shox TL 4 Nike Shox TL 5 Nike
Shox Monster Nike Shox Turob
(www.topsellingnow.com) cheap wholesale Nike Air Force Ones :
wholesale 25th anniversary nike air force ones mens sneakers
wholesale 25th anniversary nike air force ones womens shoes wholesale
Mid Cut nike air force ones wholesale light up nike air force ones
cheap wholesal Low Cut nike air force ones nike air force ones womens
boots nike air force ones kids shoes
25th anniversary Nike Air Force One High-cut shoes
==============================================================================
TOPIC: Creative Recreation shoes www.topsellingnow.com cheap sell Designer
Shoes,sneakers,boots,Sandals,slipper.
http://groups.google.com/group/comp.lang.c++/t/6c6f91b5f15f329b?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 11:39 am
From: topsellingnow@gmail.com
www.topsellingnow.com cheap sell Designer
Shoes,sneakers,boots,Sandals,slipper.
pls Connection : http://www.topsellingnow.com/big.asp?big_id=13
Creative Recreation shoes
Ugg shoes
Prada shoes
Timberland shoes
Louis Vuitton shoes
Gucci shoes
Lacoste shoes
Chanel shoes
D&G shoes
Puma shoes
DSQUARED shoes
Christian Dior shoes
Hogan shoes
Versace shoes
Mauri shoes
Burberry shoes
Armani shoes
Evisu shoes
Levi's shoes
Fendi shoes
Diesel shoes
Ed hardy shoes
Bape Sta shoes
Christian Audigier shoes
Coach shoes
ATO Matsumoto shoes
Supra shoes
True Religion shoes
AMERICAN EAGLE shoes
New Balance shoes
Li ning shoes
Creative Recreation shoes
==============================================================================
TOPIC: fork in C++
http://groups.google.com/group/comp.lang.c++/t/330f3d08b477ed33?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, May 31 2009 12:32 pm
From: Ramesh
Hi All!
I have written a progarm which will create 10 child processes ( by
fork) to execure a method simuleneously; But the the child will do
database updates. In the parent I need database success/failure update
counts done by each child. For that I declared global two arrays to
assign in the child processes; But once the child process exists then
global variables coming to original values, the child updated values
are not reflecting once child existed; I tried even with static
member variables also;
two static member variable are declared:
static int fList[10] ;
static int sList[10] ;
Static def:
int C_SMSSvcRetroExpireProcess::sList[] = { 0 };
int C_SMSSvcRetroExpireProcess::fList[] = { 0 };
Fork:
for ( index = 0; index < MAX_PROCESSES && (pid = fork()) !
= 0 ; index++ )
{
// Spawned a number of child processes to be executed
// simultaneously.
........
}
// child process
if ( pid == 0 )
{
// this is the method to be called, which will update
database inturn
smsRetroExprEligibleSvcSuccessCount[index] =
processRetroRecs ( smsSvcDeactvVCltn,
startRecCount,
endRecCount,
fileSeqNbr++,
retroActiveAutoExprDays,
_smsRetroProcessDir,
recsEligibleForUpdate,
index,
childRetCode);
TRACE_BEGIN( APPLICATION ) << "After sList[" << index
<< "]="<< sList[index] << TRACE_END;
TRACE_BEGIN( APPLICATION ) << "After fList[" << index
<< "]="<< fList[index] << TRACE_END;
// exit the child
_exit(childRetCode); // Up to here I am able to print
the above two statement correctly
}
In the child process code I am able print the sList, fList correctly
but once _exit(childRetCode); is executed I lost the child update
values; I tried to declare the sList, fList as global and also
static;But still I am not able track the child update values;
How to retain the fList, sList in parent above even if the childs
exited? Please give me clue... Thank a lot
== 2 of 2 ==
Date: Sun, May 31 2009 1:20 pm
From: Andy Champ
Ramesh wrote:
> Hi All!
>
> I have written a progarm which will create 10 child processes ( by
> fork) to execure a method simuleneously; But the the child will do
> database updates. In the parent I need database success/failure update
> counts done by each child. For that I declared global two arrays to
> assign in the child processes; But once the child process exists then
> global variables coming to original values, the child updated values
> are not reflecting once child existed; I tried even with static
> member variables also;
>
<snip>
Global data is within one process only (and possibly even smaller areas
than that!). For interprocess communication you will have to use
operating-specific methods.
As you said "Fork" I'd assume you have some kind of Unix; if you post
up which flavour someone will probably be able to suggest a suitable
newsgroup. Your query is off-topic for this one.
Andy
==============================================================================
TOPIC: How can I send a file through socket?
http://groups.google.com/group/comp.lang.c++/t/27ac5829b78bc4d5?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 12:36 pm
From: Marcel Müller
James Kanze wrote:
> If you have a big enough buffer. The usual solution is to read
> fixed sized blocks, processing each block before reading the
> next. (A professional program will usually use a pool of
> buffers and non-blocking reads, but that requires some system
> dependent code.)
With a look to C++0x this should change, since a second thread may do
the job without the need for an asynchronous I/O API.
Marcel
==============================================================================
TOPIC: static array declaration in flyweight pattern
http://groups.google.com/group/comp.lang.c++/t/b4df4db8ab107e11?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, May 31 2009 12:36 pm
From: Marcel Müller
pauldepstein@att.net wrote:
> The line Icon *FlyweightFactory::_icons[]; seems a strange definition
> of an array. In the class Icon, this array is declared as having
> dimension 5 but the definition doesn't specify the size.
This is allowed, since the compiler already knows the size.
> The definition of the array also appears to be uninitialized.
Exactly.
> In
> particular, I would be interested to know if the static array
> declaration ensures that all the int-pointer members of the array are
> null pointers. They are either null pointers or uninitialized
> pointers but which?
>
> I would probably have written Icon *FlyweightFactory::_icons[] = {0,
> 0, 0, 0, 0};
While this is possible it introduces an implicit dependency on
MAX_ICONS. If MAX_ICONS is less than 5 you will get a compilation error.
Since POD types are automatically initialized to zero in case of an
incomplete initializer list
Icon *FlyweightFactory::_icons[] = {0};
would do the job as well.
> but it's possible that the code does this anyway.
Not that I have noticed.
> Do the int-pointers
> initialize to 0 anyway even if this is not made explicit as I did?
No, their values are undefined. But since there is another variable
_numIcons which seems to store the valid part of _icons, this does not
result in undefined behavior.
Marcel
== 2 of 4 ==
Date: Sun, May 31 2009 2:28 pm
From: pauldepstein@att.net
On May 31, 9:36 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
> pauldepst...@att.net wrote:
> > The line Icon *FlyweightFactory::_icons[]; seems a strange definition
> > of an array. In the class Icon, this array is declared as having
> > dimension 5 but the definition doesn't specify the size.
>
> This is allowed, since the compiler already knows the size.
>
> > The definition of the array also appears to be uninitialized.
>
> Exactly.
>
> > In
> > particular, I would be interested to know if the static array
> > declaration ensures that all the int-pointer members of the array are
> > null pointers. They are either null pointers or uninitialized
> > pointers but which?
>
> > I would probably have written Icon *FlyweightFactory::_icons[] = {0,
> > 0, 0, 0, 0};
>
> While this is possible it introduces an implicit dependency on
> MAX_ICONS. If MAX_ICONS is less than 5 you will get a compilation error.
> Since POD types are automatically initialized to zero in case of an
> incomplete initializer list
> Icon *FlyweightFactory::_icons[] = {0};
> would do the job as well.
>
> > but it's possible that the code does this anyway.
>
> Not that I have noticed.
>
> > Do the int-pointers
> > initialize to 0 anyway even if this is not made explicit as I did?
>
> No, their values are undefined. But since there is another variable
> _numIcons which seems to store the valid part of _icons, this does not
> result in undefined behavior.
>
> Marcel
Thanks, Marcel.
I have two questions. I realise that POD types are automatically
initialized to 0 in the case of an uninitialized list but does this
apply here? I incorrectly said that the array holds members of type
int*. Is this a POD type? I didn't think so.
However, the array actually holds members of type Icon* where Icon is
another class. So I don't think the initialization trick you mention
holds, or does it?
I suppose my questions are:
1) Does the initialization trick Type LargeArray[] = {0}; work
when Type is the int* type?
2) Does the same initialization trick work when Type is the
FairlyComplexClass* type?
Many thanks again for your help?
Paul Epstein
== 3 of 4 ==
Date: Sun, May 31 2009 11:31 pm
From: Bart van Ingen Schenau
pauldepstein@att.net wrote:
> On May 31, 9:36 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
> wrote:
>> pauldepst...@att.net wrote:
>> > The line Icon *FlyweightFactory::_icons[]; seems a strange
>> > definition of an array. In the class Icon, this array is declared
>> > as having dimension 5 but the definition doesn't specify the size.
>>
>> This is allowed, since the compiler already knows the size.
>>
>> > The definition of the array also appears to be uninitialized.
>>
>> Exactly.
>>
>> > In
>> > particular, I would be interested to know if the static array
>> > declaration ensures that all the int-pointer members of the array
>> > are null pointers. They are either null pointers or uninitialized
>> > pointers but which?
>>
>> > I would probably have written Icon *FlyweightFactory::_icons[] =
>> > {0, 0, 0, 0, 0};
>>
>> While this is possible it introduces an implicit dependency on
>> MAX_ICONS. If MAX_ICONS is less than 5 you will get a compilation
>> error. Since POD types are automatically initialized to zero in case
>> of an incomplete initializer list
>> Icon *FlyweightFactory::_icons[] = {0};
>> would do the job as well.
>>
>> > but it's possible that the code does this anyway.
>>
>> Not that I have noticed.
>>
>> > Do the int-pointers
>> > initialize to 0 anyway even if this is not made explicit as I did?
>>
>> No, their values are undefined. But since there is another variable
>> _numIcons which seems to store the valid part of _icons, this does
>> not result in undefined behavior.
As the array has static storage duration, the array is guaranteed to be
zero-initialised. This means that all array elements will be initialised
to a null-pointer.
>>
>> Marcel
>
> Thanks, Marcel.
>
> I have two questions. I realise that POD types are automatically
> initialized to 0 in the case of an uninitialized list but does this
> apply here?
Yes, it does apply.
> I incorrectly said that the array holds members of type
> int*. Is this a POD type? I didn't think so.
> However, the array actually holds members of type Icon* where Icon is
> another class. So I don't think the initialization trick you mention
> holds, or does it?
As int* and Icon* are both plain pointers, the certainly are POD types.
And the trick with specifying ferwer initialisers than there are array
elements works regardless of the element type of the array.
> I suppose my questions are:
> 1) Does the initialization trick Type LargeArray[] = {0}; work
> when Type is the int* type?
> 2) Does the same initialization trick work when Type is the
> FairlyComplexClass* type?
Yes to both.
>
> Many thanks again for your help?
>
> Paul Epstein
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
== 4 of 4 ==
Date: Mon, Jun 1 2009 12:12 am
From: Marcel Müller
pauldepstein@att.net wrote:
>>> Do the int-pointers
>>> initialize to 0 anyway even if this is not made explicit as I did?
>> No, their values are undefined. But since there is another variable
>> _numIcons which seems to store the valid part of _icons, this does not
>> result in undefined behavior.
>
> I have two questions. I realise that POD types are automatically
> initialized to 0 in the case of an uninitialized list but does this
> apply here?
No, this is implementation dependent. Most multi-tasking OS return only
memory that is initialized to zero to avoid security issues. But this
does non necessarily propagate through the C runtime. Some runtimes
initialize the memory to a magic value for debugging purposes.
> I incorrectly said that the array holds members of type
> int*. Is this a POD type? I didn't think so.
All pointer types are simple C style data types.
> However, the array actually holds members of type Icon* where Icon is
> another class. So I don't think the initialization trick you mention
> holds, or does it?
This is defined behavior.
> I suppose my questions are:
> 1) Does the initialization trick Type LargeArray[] = {0}; work
> when Type is the int* type?
Yes.
> 2) Does the same initialization trick work when Type is the
> FairlyComplexClass* type?
Yes, that makes no difference.
But the coding that you have posted does not rely on either of that,
because it does not read any of the pointers in the array without
writing it before. But the implementation has undefined behavior and is
likely to crash at another point. If you call FlyweightFactory::getIcon
with more than MAX_ICONS different names, the array _icons is accessed
out of it's bounds. So the code is simply a very bad design. At least it
should throw an exception in this case.
If you do C++ I strongly recommend to avoid to use pointers to access
non constant arrays. Move to std::vector instead and all of these
problems disappear. And if your application needs a dictionary like the
posted code you should have a look at std::map or std::set too. They may
do almost all of the work you need except for the construction of new
instances.
Furthermore, you should check who own the objects that you have created
with new. In the example one would expect that FlyweightFactory owns the
Icon instances. But it doesn't. The instances are never destroyed. This
might not be a problem if the Icon class does not rely on its destructor
call. But it might become a problem if Icon controls unmanaged resources
like Windows COM objects (or things that are similarly awful).
With respect to the cleanup, it is more clean to use a static instances
of FlyweightFactory instead of a class with only static functions. Then
you have a destructor call of FlyweightFactory where you can delete the
cache content. If you want to ensure that there are no two instances of
FlyweightFactory in memory, you should consider a singleton patten
implementation.
Marcel
==============================================================================
TOPIC: C++ Gurus - Is C++ a good choice for public API(s)??? Are there clean
ways to solve known problems there?
http://groups.google.com/group/comp.lang.c++/t/faaac8999a2ece5e?hl=en
==============================================================================
== 1 of 5 ==
Date: Sun, May 31 2009 2:19 pm
From: arijit79@gmail.com
Hi
I needed to build up a public API for an application at hand.
The data I am modelling maps very well to object oriented design, so I
am little inclined towards a C++ public API (i.e. my deliverables
would be a <xyz>.hpp file which will have a bunch of pure virtual
functions forming the interface and a lib<xyz>.so which will basically
contain the implementation for those interfaces).
But, I can think of 2 problems there:
1) How do I guarantee that my shared library will work well with the
version of the C++ library/compiler my customer/user is having?
Issue in detail: I mean, I compile my shared library with version 'X'
of a Std CPP compiler and customer tries to use with version 'Y' of
StdCPP compiler. And then, if 'X' and 'Y' versions of CPP compiler are
not compatible, then we get into trouble. We have hit this several
times with different gcc versions. Just wondering, what is the best/
cleanest way to solve/get-around this problem?
2) Sometimes it happens that you are working on a C++ based product
which already has millions of lines of code and then, one fine day a
requirement comes that a part of that chunk needs to be made accesible
to users through a shared library. Now, which you work towards
building that shared library, you may want to ensure that only symbols
that *should be* exported to users/customers, needs to be exported in
the shared library, all others un-wanted globals should not be
exported in the shared library to ensure we don't un-necessarily
pollute customer's namesapce with whole lot of our internal/global
symbols. (Note: Ideal solution for this issue, probably would be to
ensure that we should never pollute our implementation namespace at
all, in the first place, but as I said, you may not be the one who had
written all these code and it's a million lines code, and you don't
have the option/bugdet for re-arch/re-write!). For such a requriement,
if it was a C library we could typically use 'objcopy' in linux or -M
compiler option in Solaris, to make sure only a given set of symbols
(defined by us) are made global. But if it's a C++ library, I wonder
how to achieve this goal?
Issues: C++ symbols are mangled, so I would probably need to specify
those mangled names as an input to 'objcopy', but mangling varies from
compiler to compiler and platform to platform. With that this can
become a real maintenance headache.
Question: Is there a cleaner/better way to handle this?
Thanks in advance for oyour time and help!
Arijit
== 2 of 5 ==
Date: Sun, May 31 2009 3:04 pm
From: Phlip
arijit79@gmail.com wrote:
> I needed to build up a public API for an application at hand.
You cannot do any of this by guessing or planning. To create a public API, you
must write at least three projects, and port them to three different platforms
(linux, mac & pc) come to mind. Then you must configure your unit tests to run
simultaneously on each of the three platforms, each time you save your code. (I
have done this before, between Linux & PC, using Samba. Both platforms compiled
simultaneously into the same folders.)
Your nine projects should run all their tests each time you edit any of their
sources - both inside and outside the API boundary. And you write three
different projects to prove that your API actually solves problems for them,
flexibly.
> The data I am modelling maps very well to object oriented design, so I
> am little inclined towards a C++ public API (i.e. my deliverables
> would be a <xyz>.hpp file which will have a bunch of pure virtual
> functions forming the interface and a lib<xyz>.so which will basically
> contain the implementation for those interfaces).
That's not what "pure virtual" means. It means the methods _don't_ have
implementations. If you go this route, you will simply need virtual methods.
However...
Why do you think the project will need an OO design? The point of OO is to
abstract and vary virtual methods behind common interfaces. Have you written any
sample code showing the best places for the virtual methods? They might not be
what you expect.
You might be safer - if your client actually _needs_ all these platforms - by
writing a C-style API. The C++ communities widely support this technique,
because most platforms enforce compatibility standards among simple functions.
By contrast, because C++ virtual methods must be very optimal, they enjoy fewer
standards. You might not be able to ship binaries, for example, and you might
have to ship live source code for your clients to compile.
> But, I can think of 2 problems there:
> 1) How do I guarantee that my shared library will work well with the
> version of the C++ library/compiler my customer/user is having?
By actually getting all the versions, like I said, and constantly testing them
as you change the code. If you make a change that you think is innocent, and if
one platform throws up a red flag, you can back out the change long before you
commit to it and invest more code around it.
> Issue in detail: I mean, I compile my shared library with version 'X'
> of a Std CPP compiler and customer tries to use with version 'Y' of
> StdCPP compiler. And then, if 'X' and 'Y' versions of CPP compiler are
> not compatible, then we get into trouble. We have hit this several
> times with different gcc versions. Just wondering, what is the best/
> cleanest way to solve/get-around this problem?
Have you surveyed your user population? Can you set up virtual Linuces with each
of these versions?
== 3 of 5 ==
Date: Sun, May 31 2009 5:28 pm
From: rabbits77
arijit79@gmail.com wrote:
> Hi
>
> I needed to build up a public API for an application at hand.
>
> The data I am modelling maps very well to object oriented design, so I
> am little inclined towards a C++ public API (i.e. my deliverables
> would be a <xyz>.hpp file which will have a bunch of pure virtual
> functions forming the interface and a lib<xyz>.so which will basically
> contain the implementation for those interfaces).
Can you write your public API in the most general
standards conforming way(no platform specific
calls)? If so, great! Do so!
You can be pretty much assured that it will work no
matter whether users try it with Visual C++ or g++
or whatever.
Then as an added bonus add on other language APIs on
top with SWIG. :)
== 4 of 5 ==
Date: Sun, May 31 2009 9:30 pm
From: Phlip
rabbits77 wrote:
> Can you write your public API in the most general standards conforming
> way(no platform specific calls)? If so, great! Do so!
That answers the wrong question. The API has two interfaces, one
programmer-facing and the other hardware-facing. The question was about keeping
the upper layer clean and portable.
Almost no program can do anything without platform specific calls - even tasks
as mundane as file reconnaissance are platform-specific. The OP is advised to
get into some full-featured portable platform, such as Qt or wxWindows, to get a
kit of all of those functions, readily ported and supported to a wide variety of
platforms. (Those platforms also come with nice GUI layers, which one can
exploit or ignore.)
== 5 of 5 ==
Date: Sun, May 31 2009 9:55 pm
From: "Tony"
Without even reading the body or you post, I suggest you consider "C++ Guru"
and expand your question to include the out of the box thinkers, for your
question is a design one rather than a language-specific one, at least to
some large degree, I think. When I think of "C++ Guru", I think of those
heavily knowledgeable of the C++ standard, who indeed are valuable (if not
temporary) walking/talking encyclonairies. Heavy knowledge in the C++
monstrosity leaves less "ROM" (subjective to some degree, but not mostly to
a high degree) for stuff outside of that narrow box (Ref, definition of
specialization: one learns more and more about less and less until they know
everything about nothing). Add that politics are more likely to be given
(knowingly or unknowingly via paradigmical thought), rather than unbiased
thought, and you have an answer that seemingly is good, but is just BS (at
worst).
==============================================================================
TOPIC: The best way to retrieve a returned value... by const reference?
http://groups.google.com/group/comp.lang.c++/t/0f3ad790abe791fc?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 2:43 pm
From: Howard Hinnant
On May 27, 12:37 pm, "Niels Dekker - no reply address"
<nore...@this.is.invalid> wrote:
> Suppose you're calling a function that returns an object "by value".
> When const access to the returned value is sufficient, you have the
> choice between binding the returned object to a const-reference, and
> copying the object to a local (const) variable, using
> copy-initialization:
>
> class Foo { /* ... */ };
> Foo GetFoo(void);
>
> const Foo& constReference = GetFoo(); // Choice #1
> const Foo constValue = GetFoo(); // Choice #2
>
> Personally, I have the habbit to bind such an object to a
> const-reference (choice #1). Thereby I hope to avoid an expensive
> copy-construction, which /might/ take place when you use
> copy-initialization (choice #2). Is it a common practice to do so?
A minor addition to the rest of this thread:
One danger of this habit is accidently not realizing that GetFoo()
returns a const Foo&. For example it can be a bad idea to use this
style with std::max which returns a const&.
const Foo& cr = std::max(GetFoo(x), GetFoo(y));
Personally I consider this a design defect of std::max, and not a
reason to not use your style. I mention it only because there is
defectively designed code out there (like std::max) that you need to
watch out for.
-Howard
==============================================================================
TOPIC: C++ stuff I can't talk about here
http://groups.google.com/group/comp.lang.c++/t/5017e5dbab2a63a3?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, May 31 2009 9:12 pm
From: "Tony"
SG wrote:
> On 30 Mai, 06:31, "Tony" <t...@my.net> wrote:
>> Well there's the object model: "C++ers" (circa 2009, not language
>> invention time (I'm letting the mentioned latterS off the hook))
>> don't get it. They blindly accept the C++ object model (read,
>> thery're "virtually blindsided"), as it lacks practical substance.
>> Theory is nice, and everyone has one (did I say that?), but the C++
>> object model theory is a pile.
>>
>> I'm gonna stop with that cuz it's such a BIGGIE. I could have made
>> the subject: "The C++ object model sucks!".
>>
>> All comments welcomed.
>
> From what I know you're only considering different "object models" for
> your own programming language design. You should add a little more
> content that qualifies as a good basis for a discussion and move the
> thread to comp.lang.misc or something.
Well you're partly correct: while the discussion is one of language design
and the fact that C++ is already set in stone, make any such "betterment"
discussion more appropriate in a language design group. OTOH, what C++ is,
is C++ and is apparently on-topic. This NG is named c.l.c++.usage. At least
_I_ see it as a catchall for all things C++ (motivation for subgroups, but
kinda late for the ailing C++, and perhaps then just a good idea for any
modern language group).
That said, I think my primary motivation for pursuing a new language (over
C++) is the object model. I think that in the language's maturity.. blah,
blah...
That "said", I totally agree that C++ is "multi-PARADIGMICAL" (note the
emphasis).
Paradigm: to "know" or "believe" something so much that it blinds one to
other possibilities including the correct solution to the problem at hand
and/or to the INcorrectness of the current (even highly regarded) practice
(historic ref: bloodletting).
== 2 of 4 ==
Date: Sun, May 31 2009 9:38 pm
From: "Tony"
Tony wrote:
> SG wrote:
>> On 30 Mai, 06:31, "Tony" <t...@my.net> wrote:
>>> Well there's the object model: "C++ers" (circa 2009, not language
>>> invention time (I'm letting the mentioned latterS off the hook))
>>> don't get it. They blindly accept the C++ object model (read,
>>> thery're "virtually blindsided"), as it lacks practical substance.
>>> Theory is nice, and everyone has one (did I say that?), but the C++
>>> object model theory is a pile.
>>>
>>> I'm gonna stop with that cuz it's such a BIGGIE. I could have made
>>> the subject: "The C++ object model sucks!".
>>>
>>> All comments welcomed.
>>
>> From what I know you're only considering different "object models"
>> for your own programming language design. You should add a little
>> more content that qualifies as a good basis for a discussion and
>> move the thread to comp.lang.misc or something.
>
> Well you're partly correct: while the discussion is one of language
> design and the fact that C++ is already set in stone, make any such
> "betterment" discussion more appropriate in a language design group.
> OTOH, what C++ is, is C++ and is apparently on-topic.
>This NG is
> named c.l.c++.usage.
An obvious wireless keyboard hiccup: should have included the word 'not'.
(That's one reason why wireless sucks: it doesn't work!). My wireless
keyboard makes me seem stupid sometimes.
Tony
== 3 of 4 ==
Date: Sun, May 31 2009 10:49 pm
From: coal@mailvault.com
On May 31, 11:12 pm, "Tony" <t...@my.net> wrote:
> SG wrote:
> > On 30 Mai, 06:31, "Tony" <t...@my.net> wrote:
> >> Well there's the object model: "C++ers" (circa 2009, not language
> >> invention time (I'm letting the mentioned latterS off the hook))
> >> don't get it. They blindly accept the C++ object model (read,
> >> thery're "virtually blindsided"), as it lacks practical substance.
> >> Theory is nice, and everyone has one (did I say that?), but the C++
> >> object model theory is a pile.
>
> >> I'm gonna stop with that cuz it's such a BIGGIE. I could have made
> >> the subject: "The C++ object model sucks!".
>
> >> All comments welcomed.
>
> > From what I know you're only considering different "object models" for
> > your own programming language design. You should add a little more
> > content that qualifies as a good basis for a discussion and move the
> > thread to comp.lang.misc or something.
>
> Well you're partly correct: while the discussion is one of language design
> and the fact that C++ is already set in stone, make any such "betterment"
> discussion more appropriate in a language design group. OTOH, what C++ is,
> is C++ and is apparently on-topic. This NG is named c.l.c++.usage. At least
> _I_ see it as a catchall for all things C++ (motivation for subgroups, but
> kinda late for the ailing C++, and perhaps then just a good idea for any
> modern language group).
>
> That said, I think my primary motivation for pursuing a new language (over
> C++) is the object model. I think that in the language's maturity.. blah,
> blah...
>
> That "said", I totally agree that C++ is "multi-PARADIGMICAL" (note the
> emphasis).
>
> Paradigm: to "know" or "believe" something so much that it blinds one to
> other possibilities including the correct solution to the problem at hand
> and/or to the INcorrectness of the current (even highly regarded) practice
> (historic ref: bloodletting).- Hide quoted text -
>
> - Show quoted text -
As others have said, there's not a lot here to discuss. You make
a few generalizations, but that's about it. A lot of people here
agree C++ is flawed. I expect to see a language developed that
corrects the known problems -- not sure how soon. Anyway, I've
complained here before about your not offering details.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
== 4 of 4 ==
Date: Sun, May 31 2009 11:13 pm
From: "Tony"
coal@mailvault.com wrote:
> On May 31, 11:12 pm, "Tony" <t...@my.net> wrote:
>> SG wrote:
>>> On 30 Mai, 06:31, "Tony" <t...@my.net> wrote:
>>>> Well there's the object model: "C++ers" (circa 2009, not language
>>>> invention time (I'm letting the mentioned latterS off the hook))
>>>> don't get it. They blindly accept the C++ object model (read,
>>>> thery're "virtually blindsided"), as it lacks practical substance.
>>>> Theory is nice, and everyone has one (did I say that?), but the C++
>>>> object model theory is a pile.
>>
>>>> I'm gonna stop with that cuz it's such a BIGGIE. I could have made
>>>> the subject: "The C++ object model sucks!".
>>
>>>> All comments welcomed.
>>
>>> From what I know you're only considering different "object models"
>>> for your own programming language design. You should add a little
>>> more content that qualifies as a good basis for a discussion and
>>> move the thread to comp.lang.misc or something.
>>
>> Well you're partly correct: while the discussion is one of language
>> design and the fact that C++ is already set in stone, make any such
>> "betterment" discussion more appropriate in a language design group.
>> OTOH, what C++ is, is C++ and is apparently on-topic. This NG is
>> named c.l.c++.usage. At least _I_ see it as a catchall for all
>> things C++ (motivation for subgroups, but kinda late for the ailing
>> C++, and perhaps then just a good idea for any modern language
>> group).
>>
>> That said, I think my primary motivation for pursuing a new language
>> (over C++) is the object model. I think that in the language's
>> maturity.. blah, blah...
>>
>> That "said", I totally agree that C++ is "multi-PARADIGMICAL" (note
>> the emphasis).
>>
>> Paradigm: to "know" or "believe" something so much that it blinds
>> one to other possibilities including the correct solution to the
>> problem at hand and/or to the INcorrectness of the current (even
>> highly regarded) practice (historic ref: bloodletting).- Hide quoted
>> text -
>>
>> - Show quoted text -
>
>
> As others have said, there's not a lot here to discuss.
Oh how conveniently you bring the vote idea to trial. I totally agree: null
and void: "the vote".
> You make
> a few generalizations,
Is that an accusation? Prove it. (Read: because you don't understand does
not make it "a generalization").
> but that's about it.
Sounds like lynching.
> A lot of people here
Here? So you think there is a "here"? (Quite bizarre).
> agree C++ is flawed. I expect to see a language developed that
> corrects the known problems -- not sure how soon. Anyway, I've
> complained here before about your not offering details.
And who are you, wanting "details"? Hmm?
==============================================================================
TOPIC: High Cohesion and Low Coupling in C++
http://groups.google.com/group/comp.lang.c++/t/d8ed656848516be4?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, May 31 2009 10:25 pm
From: Pallav singh
Q How to get High Cohesion and Low Coupling, while designing in C++ ?
==============================================================================
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